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
5989 lines
260 KiB
HTML
5989 lines
260 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 Active Issues List</title></head>
|
|
<body bgcolor="#ffffff" text="#000000">
|
|
<table>
|
|
<tr>
|
|
<td align="left">Doc. no.</td>
|
|
<td align="left">J16/02-0048 = WG21 N1390</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 Active Issues 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-defects.html">Library Defect Reports List</a></li>
|
|
<li><a href="lwg-closed.html">Library Closed Issues List</a></li>
|
|
</ul>
|
|
<p>The purpose of this document is to record the status of issues
|
|
which have come before the Library Working Group (LWG) of the ANSI
|
|
(J16) and ISO (WG21) C++ Standards Committee. Issues represent
|
|
potential defects in the ISO/IEC IS 14882:1998(E) document. Issues
|
|
are not to be used to request new features or other extensions. </p>
|
|
|
|
<p>This document contains only library issues which are actively being
|
|
considered by the Library Working Group. That is, issues which have a
|
|
status of <a href="lwg-active.html#New">New</a>, <a href="lwg-active.html#Open">Open</a>,
|
|
<a href="lwg-active.html#Ready">Ready</a>, and <a href="lwg-active.html#Review">Review</a>. See
|
|
<a href="lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
|
|
<a href="lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
|
|
|
|
<p>The issues in these lists are not necessarily formal ISO Defect
|
|
Reports (DR's). While some issues will eventually be elevated to
|
|
official Defect Report status, other issues will be disposed of in
|
|
other ways. See <a href="#Status">Issue Status</a>.</p>
|
|
|
|
<p>This document is in an experimental format designed for both
|
|
viewing via a world-wide web browser and hard-copy printing. It
|
|
is available as an HTML file for browsing or PDF file for
|
|
printing.</p>
|
|
|
|
<p>Prior to Revision 14, library issues lists existed in two slightly
|
|
different versions; a Committee Version and a Public
|
|
Version. Beginning with Revision 14 the two versions were combined
|
|
into a single version.</p>
|
|
|
|
<p>This document includes <i>[bracketed italicized notes]</i> as a
|
|
reminder to the LWG of current progress on issues. Such notes are
|
|
strictly unofficial and should be read with caution as they may be
|
|
incomplete or incorrect. Be aware that LWG support for a particular
|
|
resolution can quickly change if new viewpoints or killer examples are
|
|
presented in subsequent discussions.</p>
|
|
|
|
<p>For the most current official version of this document see
|
|
<a href="http://www.dkuug.dk/jtc1/sc22/wg21">http://www.dkuug.dk/jtc1/sc22/wg21</a>.
|
|
Requests for further information about this document should include
|
|
the document number above, reference ISO/IEC 14882:1998(E), and be
|
|
submitted to Information Technology Industry Council (ITI), 1250 Eye
|
|
Street NW, Washington, DC 20005.</p>
|
|
|
|
<p>Public information as to how to obtain a copy of the C++ Standard,
|
|
join the standards committee, submit an issue, or comment on an issue
|
|
can be found in the C++ FAQ at <a href="http://www.research.att.com/~austern/csc/faq.html">http://www.research.att.com/~austern/csc/faq.html</a>.
|
|
Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c%2B%2B">news:comp.std.c++</a>.
|
|
</p>
|
|
|
|
<p>For committee members, files available on the committee's private
|
|
web site include the HTML version of the Standard itself. HTML
|
|
hyperlinks from this issues list to those files will only work for
|
|
committee members who have downloaded them into the same disk
|
|
directory as the issues list files. </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>
|
|
<a name="Status"></a>Issue Status</h2>
|
|
<p>
|
|
<b><a name="New">New</a></b> - The issue has not yet been
|
|
reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
|
|
suggestion from the issue submitter, and should not be construed as
|
|
the view of LWG.</p>
|
|
|
|
<p>
|
|
<b><a name="Open">Open</a></b> - The LWG has discussed the issue
|
|
but is not yet ready to move the issue forward. There are several
|
|
possible reasons for open status:</p>
|
|
<ul>
|
|
<li>Consensus may have not yet have been reached as to how to deal
|
|
with the issue.</li>
|
|
<li>Informal consensus may have been reached, but the LWG awaits
|
|
exact <b>Proposed Resolution</b> wording for review.</li>
|
|
<li>The LWG wishes to consult additional technical experts before
|
|
proceeding.</li>
|
|
<li>The issue may require further study.</li>
|
|
</ul>
|
|
|
|
<p>A <b>Proposed Resolution</b> for an open issue is still not be
|
|
construed as the view of LWG. Comments on the current state of
|
|
discussions are often given at the end of open issues in an italic
|
|
font. Such comments are for information only and should not be given
|
|
undue importance.</p>
|
|
|
|
<p>
|
|
<b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
|
|
the issue is a duplicate of another issue, and will not be further
|
|
dealt with. A <b>Rationale</b> identifies the duplicated issue's
|
|
issue number. </p>
|
|
|
|
<p>
|
|
<b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
|
|
the issue is not a defect in the Standard, and the issue is ready to
|
|
forward to the full committee as a proposed record of response. A
|
|
<b>Rationale</b> discusses the LWG's reasoning.</p>
|
|
|
|
<p>
|
|
<b><a name="Review">Review</a></b> - Exact wording of a
|
|
<b>Proposed Resolution</b> is now available for review on an issue
|
|
for which the LWG previously reached informal consensus.</p>
|
|
|
|
<p>
|
|
<b><a name="Ready">Ready</a></b> - The LWG has reached consensus
|
|
that the issue is a defect in the Standard, the <b>Proposed
|
|
Resolution</b> is correct, and the issue is ready to forward to the
|
|
full committee for further action as a Defect Report (DR).</p>
|
|
|
|
<p>
|
|
<b><a name="DR">DR</a></b> - (Defect Report) - The full J16
|
|
committee has voted to forward the issue to the Project Editor to be
|
|
processed as a Potential Defect Report. The Project Editor reviews
|
|
the issue, and then forwards it to the WG21 Convenor, who returns it
|
|
to the full committee for final disposition. This issues list
|
|
accords the status of DR to all these Defect Reports regardless of
|
|
where they are in that process.</p>
|
|
|
|
<p>
|
|
<b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
|
|
WG21 committee has voted to accept the Defect Report's Proposed
|
|
Resolution as a Technical Corrigenda. Action on this issue is thus
|
|
complete and no further action is possible under ISO rules.</p>
|
|
|
|
<p>
|
|
<b><a name="RR">RR</a></b> - (Record of Response) - The full WG21
|
|
committee has determined that this issue is not a defect in the
|
|
Standard. Action on this issue is thus complete and no further
|
|
action is possible under ISO rules.</p>
|
|
|
|
<p>
|
|
<b><a name="Future">Future</a></b> - In addition to the regular
|
|
status, the LWG believes that this issue should be revisited at the
|
|
next revision of the standard. It is usually paired with NAD.</p>
|
|
|
|
<p>Issues are always given the status of <a href="lwg-active.html#New">New</a> when
|
|
they first appear on the issues list. They may progress to
|
|
<a href="lwg-active.html#Open">Open</a> or <a href="lwg-active.html#Review">Review</a> while the LWG
|
|
is actively working on them. When the LWG has reached consensus on
|
|
the disposition of an issue, the status will then change to
|
|
<a href="lwg-active.html#Dup">Dup</a>, <a href="lwg-active.html#NAD">NAD</a>, or <a href="lwg-active.html#Ready">Ready</a> as appropriate. Once the full J16 committee votes to
|
|
forward Ready issues to the Project Editor, they are given the
|
|
status of Defect Report ( <a href="lwg-active.html#DR">DR</a>). These in turn may
|
|
become the basis for Technical Corrigenda (<a href="lwg-active.html#TC">TC</a>),
|
|
or are closed without action other than a Record of Response
|
|
(<a href="lwg-active.html#RR">RR</a> ). The intent of this LWG process is that
|
|
only issues which are truly defects in the Standard move to the
|
|
formal ISO DR status.
|
|
</p>
|
|
|
|
<h2>Active Issues</h2>
|
|
<hr>
|
|
<a name="23"><h3>23. Num_get overflow result</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#Open">Open</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>The current description of numeric input does not account for the possibility of
|
|
overflow. This is an implicit result of changing the description to rely on the definition
|
|
of scanf() (which fails to report overflow), and conflicts with the documented behavior of
|
|
traditional and current implementations. </p>
|
|
|
|
<p>Users expect, when reading a character sequence that results in a value unrepresentable
|
|
in the specified type, to have an error reported. The standard as written does not permit
|
|
this. </p>
|
|
|
|
<p><b>Further comments from Dietmar:</b></p>
|
|
|
|
<p>
|
|
I don't feel comfortable with the proposed resolution to issue 23: It
|
|
kind of simplifies the issue to much. Here is what is going on:
|
|
</p>
|
|
|
|
<p>
|
|
Currently, the behavior of numeric overflow is rather counter intuitive
|
|
and hard to trace, so I will describe it briefly:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
According to 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>
|
|
paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
|
|
return an input error; otherwise a value is converted to the rules
|
|
of <tt>scanf</tt>.
|
|
</li>
|
|
<li>
|
|
<tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
|
|
</li>
|
|
<li>
|
|
<tt>fscanf()</tt> returns an input failure if during conversion no
|
|
character matching the conversion specification could be extracted
|
|
before reaching EOF. This is the only reason for <tt>fscanf()</tt>
|
|
to fail due to an input error and clearly does not apply to the case
|
|
of overflow.
|
|
</li>
|
|
<li>
|
|
Thus, the conversion is performed according to the rules of
|
|
<tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
|
|
<tt>strtol()</tt>, etc. are to be used for the conversion.
|
|
</li>
|
|
<li>
|
|
The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
|
|
many matching characters as there are and on overflow continue to
|
|
consume matching characters but also return a value identical to
|
|
the maximum (or minimum for signed types if there was a leading minus)
|
|
value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
|
|
</li>
|
|
<li>
|
|
Thus, according to the current wording in the standard, overflows
|
|
can be detected! All what is to be done is to check <tt>errno</tt>
|
|
after reading an element and, of course, clearing <tt>errno</tt>
|
|
before trying a conversion. With the current wording, it can be
|
|
detected whether the overflow was due to a positive or negative
|
|
number for signed types.
|
|
</li>
|
|
</ul>
|
|
|
|
<p><b>Further discussion from Redmond:</b></p>
|
|
|
|
<p>The basic problem is that we've defined our behavior,
|
|
including our error-reporting behavior, in terms of C90. However,
|
|
C90's method of reporting overflow in scanf is not technically an
|
|
"input error". The <tt>strto_*</tt> functions are more precise.</p>
|
|
|
|
<p>There was general consensus that <tt>failbit</tt> should be set
|
|
upon overflow. We considered three options based on this:</p>
|
|
<ol>
|
|
<li>Set failbit upon conversion error (including overflow), and
|
|
don't store any value.</li>
|
|
<li>Set failbit upon conversion error, and also set <tt>errno</tt> to
|
|
indicated the precise nature of the error.</li>
|
|
<li>Set failbit upon conversion error. If the error was due to
|
|
overflow, store +-numeric_limits<T>::max() as an
|
|
overflow indication.</li>
|
|
</ol>
|
|
|
|
<p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
|
|
|
|
<p>PJP will provide wording.</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<hr>
|
|
<a name="44"><h3>44. Iostreams use operator== on int_type values</h3></a><p>
|
|
<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
|
<p>Many of the specifications for iostreams specify that character
|
|
values or their int_type equivalents are compared using operators ==
|
|
or !=, though in other places traits::eq() or traits::eq_int_type is
|
|
specified to be used throughout. This is an inconsistency; we should
|
|
change uses of == and != to use the traits members instead. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p><i>[Kona: Nathan to supply proposed wording]</i></p>
|
|
|
|
<p><i>[
|
|
Tokyo: the LWG reaffirmed that this is a defect, and requires careful
|
|
review of clause 27 as the changes are context sensitive.
|
|
]</i></p>
|
|
|
|
<hr>
|
|
<a name="91"><h3>91. Description of operator>> and getline() for string<> might cause endless loop</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#Ready">Ready</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>Operator >> and getline() for strings read until eof()
|
|
in the input stream is true. However, this might never happen, if the
|
|
stream can't read anymore without reaching EOF. So shouldn't it be
|
|
changed into that it reads until !good() ? </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 1, replace:</p>
|
|
<blockquote>
|
|
Effects: Begins by constructing a sentry object k as if k were
|
|
constructed by typename basic_istream<charT,traits>::sentry k( is). If
|
|
bool( k) is true, it calls str.erase() and then extracts characters
|
|
from is and appends them to str as if by calling str.append(1, c). If
|
|
is.width() is greater than zero, the maximum number n of characters
|
|
appended is is.width(); otherwise n is str.max_size(). Characters are
|
|
extracted and appended until any of the following occurs:
|
|
</blockquote>
|
|
<p>with:</p>
|
|
<blockquote>
|
|
Effects: Behaves as a formatted input function (27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>). After constructing a sentry object, if the
|
|
sentry converts to true, calls str.erase() and then extracts
|
|
characters from is and appends them to str as if by calling
|
|
str.append(1,c). If is.width() is greater than zero, the maximum
|
|
number n of characters appended is is.width(); otherwise n is
|
|
str.max_size(). Characters are extracted and appended until any of the
|
|
following occurs:
|
|
</blockquote>
|
|
|
|
<p>In 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 6, replace</p>
|
|
<blockquote>
|
|
Effects: Begins by constructing a sentry object k as if by typename
|
|
basic_istream<charT,traits>::sentry k( is, true). If bool( k) is true,
|
|
it calls str.erase() and then extracts characters from is and appends
|
|
them to str as if by calling str.append(1, c) until any of the
|
|
following occurs:
|
|
</blockquote>
|
|
<p>with:</p>
|
|
<blockquote>
|
|
Effects: Behaves as an unformatted input function (27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), except that it does not affect the value returned
|
|
by subsequent calls to basic_istream<>::gcount(). After
|
|
constructing a sentry object, if the sentry converts to true, calls
|
|
str.erase() and then extracts characters from is and appends them to
|
|
str as if by calling str.append(1,c) until any of the following
|
|
occurs:
|
|
</blockquote>
|
|
|
|
<p><i>[Redmond: Made changes in proposed resolution. <tt>operator>></tt>
|
|
should be a formatted input function, not an unformatted input function.
|
|
<tt>getline</tt> should not be required to set <tt>gcount</tt>, since
|
|
there is no mechanism for <tt>gcount</tt> to be set except by one of
|
|
<tt>basic_istream</tt>'s member functions.]</i></p>
|
|
|
|
<p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>The real issue here is whether or not these string input functions
|
|
get their characters from a streambuf, rather than by calling an
|
|
istream's member functions, a streambuf signals failure either by
|
|
returning eof or by throwing an exception; there are no other
|
|
possibilities. The proposed resolution makes it clear that these two
|
|
functions do get characters from a streambuf.</p>
|
|
<hr>
|
|
<a name="92"><h3>92. Incomplete Algorithm Requirements</h3></a><p>
|
|
<b>Section:</b> 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
|
<p>The standard does not state, how often a function object is copied,
|
|
called, or the order of calls inside an algorithm. This may lead to
|
|
surprising/buggy behavior. Consider the following example: </p>
|
|
|
|
<pre>class Nth { // function object that returns true for the nth element
|
|
private:
|
|
int nth; // element to return true for
|
|
int count; // element counter
|
|
public:
|
|
Nth (int n) : nth(n), count(0) {
|
|
}
|
|
bool operator() (int) {
|
|
return ++count == nth;
|
|
}
|
|
};
|
|
....
|
|
// remove third element
|
|
list<int>::iterator pos;
|
|
pos = remove_if(coll.begin(),coll.end(), // range
|
|
Nth(3)), // remove criterion
|
|
coll.erase(pos,coll.end()); </pre>
|
|
|
|
<p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
|
|
happens because the usual implementation of the algorithm copies the
|
|
function object internally: </p>
|
|
|
|
<pre>template <class ForwIter, class Predicate>
|
|
ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
|
|
{
|
|
beg = find_if(beg, end, op);
|
|
if (beg == end) {
|
|
return beg;
|
|
}
|
|
else {
|
|
ForwIter next = beg;
|
|
return remove_copy_if(++next, end, beg, op);
|
|
}
|
|
} </pre>
|
|
|
|
<p>The algorithm uses find_if() to find the first element that should
|
|
be removed. However, it then uses a copy of the passed function object
|
|
to process the resulting elements (if any). Here, Nth is used again
|
|
and removes also the sixth element. This behavior compromises the
|
|
advantage of function objects being able to have a state. Without any
|
|
cost it could be avoided (just implement it directly instead of
|
|
calling find_if()). </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p> In [lib.function.objects] 20.3 Function objects add as new
|
|
paragraph 6 (or insert after paragraph 1): </p>
|
|
|
|
<p>Option 1: </p>
|
|
<blockquote>
|
|
Predicates are functions or function objects that fulfill the
|
|
following requirements:<br> - They return a Boolean value (bool
|
|
or a value convertible to bool)<br> - It doesn't matter for the
|
|
behavior of a predicate how often it is copied or assigned and how
|
|
often it is called.
|
|
</blockquote>
|
|
|
|
<p>Option 2: </p>
|
|
<blockquote>
|
|
- if it's a function:<br> - All calls with the same
|
|
argument values yield the same result.<br> - if it's a function
|
|
object:<br> - In any sequence of calls to operator () without
|
|
calling any non-constant member function, all calls with the same
|
|
argument values yield the same result. <br> - After an assignment
|
|
or copy both objects return the same result for the same values.
|
|
</blockquote>
|
|
|
|
<p><i>[Santa Cruz: The LWG believes that there may be more to this than
|
|
meets the eye. It applies to all function objects, particularly
|
|
predicates. Two questions: (1) must a function object be
|
|
copyable? (2) how many times is a function object called? These
|
|
are in effect questions about state. Function objects appear to
|
|
require special copy semantics to make state work, and may fail if
|
|
calling alters state and calling occurs an unexpected number of
|
|
times.]</i></p>
|
|
|
|
<p><i>[Dublin: Pete Becker felt that this may not be a defect,
|
|
but rather something that programmers need to be educated about.
|
|
There was discussion of adding wording to the effect that the number
|
|
and order of calls to function objects, including predicates, not
|
|
affect the behavior of the function object.]</i></p>
|
|
|
|
<p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
|
|
have a clear statement of "predicate" in the
|
|
standard. People including me seemed to think "a function
|
|
returning a Boolean value and being able to be called by an STL
|
|
algorithm or be used as sorting criterion or ... is a
|
|
predicate". But a predicate has more requirements: It should
|
|
never change its behavior due to a call or being copied. IMHO we have
|
|
to state this in the standard. If you like, see section 8.1.4 of my
|
|
library book for a detailed discussion.]</i></p>
|
|
|
|
<p><i>[Kona: Nico will provide wording to the effect that "unless
|
|
otherwise specified, the number of copies of and calls to function
|
|
objects by algorithms is unspecified". Consider placing in
|
|
25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> after paragraph 9.]</i></p>
|
|
|
|
<p><i>[Pre-Tokyo: Angelika Langer comments: if the resolution is
|
|
that algorithms are free to copy and pass around any function objects,
|
|
then it is a valid question whether they are also allowed to change
|
|
the type information from reference type to value type.]</i></p>
|
|
|
|
<p><i>[Tokyo: Nico will discuss this further with Matt as there are
|
|
multiple problems beyond the underlying problem of no definition of
|
|
"Predicate".]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: Nico provided the above proposed
|
|
resolutions.]</i></p>
|
|
|
|
<p><i>[Curaçao: Nico will provide wording to make options clearer: are
|
|
the exclusive, or is one a superset of the other?]</i></p>
|
|
|
|
<hr>
|
|
<a name="96"><h3>96. Vector<bool> is not a container</h3></a><p>
|
|
<b>Section:</b> 23.2.5 <a href="lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
|
<p>
|
|
<tt>vector<bool></tt> is not a container as its reference and
|
|
pointer types are not references and pointers. </p>
|
|
|
|
<p>Also it forces everyone to have a space optimization instead of a
|
|
speed one.</p>
|
|
|
|
<p>
|
|
<b>See also:</b> 99-0008 == N1185 Vector<bool> is
|
|
Nonconforming, Forces Optimization Choice.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
|
|
|
|
<p><i>[In Dublin many present felt that failure to meet Container
|
|
requirements was a defect. There was disagreement as to whether
|
|
or not the optimization requirements constituted a defect.]</i></p>
|
|
|
|
<p><i>[The LWG looked at the following resolutions in some detail:
|
|
<br>
|
|
* Not A Defect.<br>
|
|
* Add a note explaining that vector<bool> does not meet
|
|
Container requirements.<br>
|
|
* Remove vector<bool>.<br>
|
|
* Add a new category of container requirements which
|
|
vector<bool> would meet.<br>
|
|
* Rename vector<bool>.<br>
|
|
<br>
|
|
No alternative had strong, wide-spread, support and every alternative
|
|
had at least one "over my dead body" response.<br>
|
|
<br>
|
|
There was also mention of a transition scheme something like (1) add
|
|
vector_bool and deprecate vector<bool> in the next standard. (2)
|
|
Remove vector<bool> in the following standard.]</i></p>
|
|
|
|
<p><i>[Modifying container requirements to permit returning proxies
|
|
(thus allowing container requirements conforming vector<bool>)
|
|
was also discussed.]</i></p>
|
|
|
|
<p><i>[It was also noted that there is a partial but ugly workaround in
|
|
that vector<bool> may be further specialized with a customer
|
|
allocator.]</i></p>
|
|
|
|
<p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
|
|
vector<bool>: More Problems, Better Solutions. Much discussion
|
|
of a two step approach: a) deprecate, b) provide replacement under a
|
|
new name. LWG straw vote on that: 1-favor, 11-could live with, 2-over
|
|
my dead body. This resolution was mentioned in the LWG report to the
|
|
full committee, where several additional committee members indicated
|
|
over-my-dead-body positions.]</i></p>
|
|
|
|
<p><i>[Tokyo: Not discussed by the full LWG; no one claimed new
|
|
insights and so time was more productively spent on other issues. In
|
|
private discussions it was asserted that requirements for any solution
|
|
include 1) Increasing the full committee's understanding of the
|
|
problem, and 2) providing compiler vendors, authors, teachers, and of
|
|
course users with specific suggestions as to how to apply the eventual
|
|
solution.]</i></p>
|
|
|
|
<hr>
|
|
<a name="98"><h3>98. Input iterator requirements are badly written</h3></a><p>
|
|
<b>Section:</b> 24.1.1 <a href="lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
|
<p>Table 72 in 24.1.1 <a href="lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> specifies semantics for
|
|
<tt>*r++</tt> of:</p>
|
|
|
|
<p> <tt>{ T tmp = *r; ++r; return tmp; }</tt>
|
|
</p>
|
|
|
|
<p>There are two problems with this. First, the return type is
|
|
specified to be "T", as opposed to something like "convertible to T".
|
|
This is too specific: we want to allow *r++ to return an lvalue.</p>
|
|
|
|
<p>Second, writing the semantics in terms of code misleadingly
|
|
suggests that the effects *r++ should precisely replicate the behavior
|
|
of this code, including side effects. (What if it's a user-defined
|
|
type whose copy constructor has observable behavior?) We should
|
|
replace the code with words, or else put some blanket statement in
|
|
clause 17 saying that code samples aren't intended to specify exactly
|
|
how many times a copy constructor is called, even if the copy
|
|
constructor has observable behavior. (See issue <a href="lwg-active.html#334">334</a>
|
|
for a similar problem.)</p>
|
|
|
|
<p><i>[Issue still isn't clear. Matt will try to explain it more
|
|
clearly at the next meeting.]</i></p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<hr>
|
|
<a name="120"><h3>120. Can an implementor add specializations?</h3></a><p>
|
|
<b>Section:</b> 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
|
|
|
<p>The original issue asked whether a library implementor could
|
|
specialize standard library templates for built-in types. (This was
|
|
an issue because users are permitted to explicitly instantiate
|
|
standard library templates.)</p>
|
|
|
|
<p>Specializations are no longer a problem, because of the resolution
|
|
to core issue 259. Under the proposed resolution, it will be legal
|
|
for a translation unit to contain both a specialization and an
|
|
explicit instantiation of the same template, provided that the
|
|
specialization comes first. In such a case, the explicit
|
|
instantiation will be ignored. Further discussion of library issue
|
|
120 assumes that the core 259 resolution will be adopted.</p>
|
|
|
|
<p>However, as noted in lib-7047, one piece of this issue still
|
|
remains: what happens if a standard library implementor explicitly
|
|
instantiates a standard library templates? It's illegal for a program
|
|
to contain two different explicit instantiations of the same template
|
|
for the same type in two different translation units (ODR violation),
|
|
and the core working group doesn't believe it is practical to relax
|
|
that restriction.</p>
|
|
|
|
<p>The issue, then, is: are users allowed to implicitly instantiate
|
|
standard library templates for non-user defined types? The status quo
|
|
answer is 'yes'. Changing it to 'no' would give library implementors
|
|
more freedom.</p>
|
|
|
|
<p>This is an issue because, for performance reasons, library
|
|
implementors often need to explicitly instantiate standard library
|
|
templates. (for example, std::basic_string<char>) Does giving
|
|
users freedom to explicitly instantiate standard library templates for
|
|
non-user defined types make it impossible or painfully difficult for
|
|
library implementors to do this?</p>
|
|
|
|
<p>John Spicer suggests, in lib-8957, that library implementors have a
|
|
mechanism they can use for explicit instantiations that doesn't
|
|
prevent users from performing their own explicit instantiations: put
|
|
each explicit instantiation in its own object file. (Different
|
|
solutions might be necessary for Unix DSOs or MS-Windows DLLs.) On
|
|
some platforms, library implementors might not need to do anything
|
|
special: the "undefined behavior" that results from having two
|
|
different explicit instantiations might be harmless.</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Option 1.</p>
|
|
<blockquote>
|
|
<p>Append to 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1: </p>
|
|
<blockquote>
|
|
A program may explicitly instantiate any templates in the standard
|
|
library only if the declaration depends on a user-defined name of
|
|
external linkage and the instantiation meets the standard library
|
|
requirements for the original template.
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
<p>Option 2.</p>
|
|
<blockquote>
|
|
<p>In light of the resolution to core issue 259, no normative changes
|
|
in the library clauses are necessary. Add the following non-normative
|
|
note to the end of 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1:</p>
|
|
<blockquote>
|
|
[<i>Note:</i> A program may explicitly instantiate standard library
|
|
templates, even when an explicit instantiation does not depend on
|
|
a user-defined name. <i>--end note</i>]
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
<p><i>[Copenhagen: LWG discussed three options. (1) Users may not
|
|
explicitly instantiate standard library templates, except on
|
|
user-defined types. Consequence: library implementors may freely
|
|
specialize or instantiate templates. (2) Users may explicitly
|
|
instantiate any standard library template. Consequence: if
|
|
implementors specialize or instantiate library templates, they may
|
|
need to take special steps to make sure users can do it too. (3) It
|
|
is implementation defined whether users may explicitly instantiate
|
|
standard library templates on non-user-defined types. Consequence:
|
|
library implementors may freely specialize or instantiate templates,
|
|
but may need to document some or all templates that have been
|
|
explicitly instantiated.
|
|
]</i></p>
|
|
|
|
<p><i>[Straw poll (first number is favor, second is strongly oppose): 1
|
|
- 4, 0; 2 - 9, 1; 3 - 0, 9. (Proposed resolution 1 was the original
|
|
proposed resolution.) Because there was no support for option 3, no
|
|
wording is provided.]</i></p>
|
|
|
|
<p><i>[Redmond: discussed again; straw poll had results similar to
|
|
those of Copenhagen (1 - 1, 3; 2 - 8, 4; 3 - 6, 2). Most people said
|
|
they could live with any option. The only objection to option 2 is
|
|
potential implementation difficulty. Steve Clamage volunteered do a
|
|
survey to see if there are any popular platforms where option 2 would
|
|
present a real problem for implementors. See his reflector message,
|
|
c++std-lib-9002.
|
|
]</i></p>
|
|
|
|
<p><i>[Steve and Pete Becker will talk to Jonathan Caves. The
|
|
Microsoft linker might present a problem if there are multiple copies,
|
|
some of which have static data and some of which are in DLLs. There
|
|
may be similar problems with the Apple linker; Matt will clarify
|
|
that.]</i></p>
|
|
|
|
<hr>
|
|
<a name="123"><h3>123. Should valarray helper arrays fill functions be const?</h3></a><p>
|
|
<b>Section:</b> 26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.3.7.4 <a href="lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.3.8.4 <a href="lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.3.9.4 <a href="lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998 </p>
|
|
<p>One of the operator= in the valarray helper arrays is const and one
|
|
is not. For example, look at slice_array. This operator= in Section
|
|
26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> is const: </p>
|
|
|
|
<p> <tt>void operator=(const valarray<T>&) const;</tt> </p>
|
|
|
|
<p>but this one in Section 26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> is not: </p>
|
|
|
|
<p> <tt>void operator=(const T&); </tt>
|
|
</p>
|
|
|
|
<p>The description of the semantics for these two functions is similar. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> Template class slice_array</p>
|
|
<blockquote>
|
|
|
|
<p>In the class template definition for slice_array, replace the member
|
|
function declaration</p>
|
|
<pre>
|
|
void operator=(const T&);
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
void operator=(const T&) const;
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>26.3.5.4 <a href="lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> slice_array fill function</p>
|
|
<blockquote>
|
|
|
|
<p>Change the function declaration</p>
|
|
<pre>
|
|
void operator=(const T&);
|
|
</pre>
|
|
<p>to</p>
|
|
<pre>
|
|
void operator=(const T&) const;
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> Template class gslice_array</p>
|
|
<blockquote>
|
|
|
|
<p>In the class template definition for gslice_array, replace the member
|
|
function declaration</p>
|
|
<pre>
|
|
void operator=(const T&);
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
void operator=(const T&) const;
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>26.3.7.4 <a href="lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a> gslice_array fill function</p>
|
|
<blockquote>
|
|
|
|
<p>Change the function declaration</p>
|
|
<pre>
|
|
void operator=(const T&);
|
|
</pre>
|
|
<p>to</p>
|
|
<pre>
|
|
void operator=(const T&) const;
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> Template class mask_array</p>
|
|
<blockquote>
|
|
|
|
<p>In the class template definition for mask_array, replace the member
|
|
function declaration</p>
|
|
<pre>
|
|
void operator=(const T&);
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
void operator=(const T&) const;
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>26.3.8.4 <a href="lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a> mask_array fill function</p>
|
|
<blockquote>
|
|
|
|
<p>Change the function declaration</p>
|
|
<pre>
|
|
void operator=(const T&);
|
|
</pre>
|
|
<p>to</p>
|
|
<pre>
|
|
void operator=(const T&) const;
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> Template class indirect_array</p>
|
|
<blockquote>
|
|
|
|
<p>In the class template definition for indirect_array, replace the member
|
|
function declaration</p>
|
|
<pre>
|
|
void operator=(const T&);
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
void operator=(const T&) const;
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>26.3.9.4 <a href="lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> indirect_array fill function</p>
|
|
<blockquote>
|
|
|
|
<p>Change the function declaration</p>
|
|
<pre>
|
|
void operator=(const T&);
|
|
</pre>
|
|
<p>to</p>
|
|
<pre>
|
|
void operator=(const T&) const;
|
|
</pre>
|
|
</blockquote>
|
|
|
|
|
|
<p><i>[Redmond: Robert provided wording.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>There's no good reason for one version of operator= being const and
|
|
another one not. Because of issue <a href="lwg-active.html#253">253</a>, this now
|
|
matters: these functions are now callable in more circumstances. In
|
|
many existing implementations, both versions are already const.</p>
|
|
<hr>
|
|
<a name="167"><h3>167. Improper use of <tt>traits_type::length()</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
|
<p>Paragraph 4 states that the length is determined using
|
|
<tt>traits::length(s)</tt>. Unfortunately, this function is not
|
|
defined for example if the character type is <tt>wchar_t</tt> and the
|
|
type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
|
|
the character type is <tt>char</tt> and the type of <tt>s</tt> is
|
|
either <tt>signed char const*</tt> or <tt>unsigned char
|
|
const*</tt>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 27.6.2.5.4 <a href="lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> paragraph 4 from:</p>
|
|
<blockquote>
|
|
<p>Effects: Behaves like an formatted inserter (as described in
|
|
lib.ostream.formatted.reqmts) of out. After a sentry object is
|
|
constructed it inserts characters. The number of characters starting
|
|
at s to be inserted is traits::length(s). Padding is determined as
|
|
described in lib.facet.num.put.virtuals. The traits::length(s)
|
|
characters starting at s are widened using out.widen
|
|
(lib.basic.ios.members). The widened characters and any required
|
|
padding are inserted into out. Calls width(0).</p>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>Effects: Behaves like an formatted inserter (as described in
|
|
lib.ostream.formatted.reqmts) of out. After a sentry object is
|
|
constructed it inserts characters. The number len of characters
|
|
starting at s to be inserted is</p>
|
|
<p>
|
|
- traits::length((const char*)s) if the second argument is of type
|
|
const charT*<br>
|
|
- char_traits<char>::length(s) if the second argument is of
|
|
type const char*, const signed char*, or const unsigned char* and
|
|
and charT is not char.<br>
|
|
</p>
|
|
<p>Padding is determined as described in
|
|
lib.facet.num.put.virtuals. The len characters starting at s are
|
|
widened using out.widen (lib.basic.ios.members). The widened
|
|
characters and any required padding are inserted into out. Calls
|
|
width(0).</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: It is clear to the LWG there is a defect here.
|
|
Dietmar will supply specific wording.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
|
|
|
|
<p><i>[Toronto: The original proposed resolution involved
|
|
char_traits<signed char> and char_traits<unsigned char>.
|
|
There was strong opposition to requiring that library implementors
|
|
provide those specializations of char_traits.]</i></p>
|
|
|
|
<p><i>[Copenhagen: This still isn't quite right: proposed resolution
|
|
text got garbled when the signed char/unsigned char specializations
|
|
were removed. Dietmar will provide revised wording.]</i></p>
|
|
<hr>
|
|
<a name="179"><h3>179. Comparison of const_iterators to iterators doesn't work</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#Ready">Ready</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 2 Jul 1998</p>
|
|
<p>Currently the following will not compile on two well-known standard
|
|
library implementations:</p>
|
|
|
|
<blockquote>
|
|
<pre>#include <set>
|
|
using namespace std;
|
|
|
|
void f(const set<int> &s)
|
|
{
|
|
set<int>::iterator i;
|
|
if (i==s.end()); // s.end() returns a const_iterator
|
|
}</pre>
|
|
</blockquote>
|
|
|
|
<p>
|
|
The reason this doesn't compile is because operator== was implemented
|
|
as a member function of the nested classes set:iterator and
|
|
set::const_iterator, and there is no conversion from const_iterator to
|
|
iterator. Surprisingly, (s.end() == i) does work, though, because of
|
|
the conversion from iterator to const_iterator.
|
|
</p>
|
|
|
|
<p>
|
|
I don't see a requirement anywhere in the standard that this must
|
|
work. Should there be one? If so, I think the requirement would need
|
|
to be added to the tables in section 24.1.1. I'm not sure about the
|
|
wording. If this requirement existed in the standard, I would think
|
|
that implementors would have to make the comparison operators
|
|
non-member functions.</p>
|
|
|
|
<p>This issues was also raised on comp.std.c++ by Darin
|
|
Adler. The example given was:</p>
|
|
|
|
<blockquote>
|
|
<pre>bool check_equal(std::deque<int>::iterator i,
|
|
std::deque<int>::const_iterator ci)
|
|
{
|
|
return i == ci;
|
|
}</pre>
|
|
</blockquote>
|
|
|
|
<p>Comment from John Potter:</p>
|
|
<blockquote>
|
|
<p>
|
|
In case nobody has noticed, accepting it will break reverse_iterator.
|
|
</p>
|
|
|
|
<p>
|
|
The fix is to make the comparison operators templated on two types.
|
|
</p>
|
|
|
|
<pre>
|
|
template <class Iterator1, class Iterator2>
|
|
bool operator== (reverse_iterator<Iterator1> const& x,
|
|
reverse_iterator<Iterator2> const& y);
|
|
</pre>
|
|
|
|
<p>
|
|
Obviously: return x.base() == y.base();
|
|
</p>
|
|
|
|
<p>
|
|
Currently, no reverse_iterator to const_reverse_iterator compares are
|
|
valid.
|
|
</p>
|
|
|
|
<p>
|
|
BTW, I think the issue is in support of bad code. Compares should be
|
|
between two iterators of the same type. All std::algorithms require
|
|
the begin and end iterators to be of the same type.
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Insert this paragraph after 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 7:</p>
|
|
<blockquote>
|
|
<p>In the expressions</p>
|
|
<pre>
|
|
i == j
|
|
i != j
|
|
i < j
|
|
i <= j
|
|
i >= j
|
|
i > j
|
|
i - j
|
|
</pre>
|
|
<p>Where i and j denote objects of a container's iterator type,
|
|
either or both may be replaced by an object of the container's
|
|
const_iterator type referring to the same element with no
|
|
change in semantics.</p>
|
|
</blockquote>
|
|
|
|
<p><i>[post-Toronto: Judy supplied a proposed resolution saying that
|
|
<tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
|
|
iterator comparison and difference operations.]</i></p>
|
|
|
|
<p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
|
|
explicitly listed expressions; there was concern that the previous
|
|
proposed resolution was too informal.]</i></p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
The LWG believes it is clear that the above wording applies only to
|
|
the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
|
|
where <tt>X</tt> is a container. There is no requirement that
|
|
<tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
|
|
can be mixed. If mixing them is considered important, that's a
|
|
separate issue. (Issue <a href="lwg-active.html#280">280</a>.)
|
|
</p>
|
|
<hr>
|
|
<a name="187"><h3>187. iter_swap underspecified</h3></a><p>
|
|
<b>Section:</b> 25.2.2 <a href="lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 14 Aug 1999</p>
|
|
<p>The description of iter_swap in 25.2.2 paragraph 7,says that it ``exchanges the values''
|
|
of the objects to which two iterators refer.<br>
|
|
<br>
|
|
What it doesn't say is whether it does so using swap or using the assignment operator and copy constructor.<br>
|
|
<br>
|
|
This question is an important one to answer, because swap is specialized to work efficiently for standard containers.<br>
|
|
For example:</p>
|
|
<blockquote>
|
|
<pre>vector<int> v1, v2;
|
|
iter_swap(&v1, &v2);</pre>
|
|
</blockquote>
|
|
<p>Is this call to iter_swap equivalent to calling swap(v1, v2)? Or is it equivalent to</p>
|
|
<blockquote>
|
|
<pre>{
|
|
vector<int> temp = v1;
|
|
v1 = v2;
|
|
v2 = temp;
|
|
}</pre>
|
|
</blockquote>
|
|
<p>The first alternative is O(1); the second is O(n).</p>
|
|
<p>A LWG member, Dave Abrahams, comments:</p>
|
|
<blockquote>
|
|
<p>Not an objection necessarily, but I want to point out the cost of that requirement:</p>
|
|
<blockquote>
|
|
<p><tt>iter_swap(list<T>::iterator, list<T>::iterator)</tt></p>
|
|
</blockquote>
|
|
<p>can currently be specialized to be more efficient than iter_swap(T*,T*) for many T (by using splicing). Your proposal would make that optimization
|
|
illegal. </p>
|
|
</blockquote>
|
|
|
|
<p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
|
|
which are no longer permitted.]</i></p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
|
|
<blockquote>
|
|
<p>Exchanges the values pointed to by the two iterators a and b.</p>
|
|
</blockquote>
|
|
<p>to</p>
|
|
<blockquote>
|
|
<p>
|
|
<tt>swap(*a, *b)</tt>.</p>
|
|
</blockquote>
|
|
|
|
<p><i>[post-Toronto: The LWG is concerned about possible
|
|
overspecification: there may be cases, such as Dave Abrahams's example
|
|
above, and such as vector<bool>'s iterators, where it makes more
|
|
sense for iter_swap to do something other than swap. If performance
|
|
is a concern, it may be better to have explicit complexity
|
|
requirements than to say how iter_swap should be implemented.]</i></p>
|
|
|
|
<p><i>[Redmond: Discussed, with no consensus. There was very little
|
|
support for the proposed resolution. Some people favored closing this
|
|
issue as NAD. Others favored a more complicated specification of
|
|
<tt>iter_swap</tt>, which might distinguish between ordinary iterators
|
|
and proxies. A possible new issue: how do we know that the iterators
|
|
passed to <tt>iter_swap</tt> have Assignable value types? (If this
|
|
new issue is real, it extends far beyond just
|
|
<tt>iter_swap</tt>.)]</i></p>
|
|
|
|
<hr>
|
|
<a name="197"><h3>197. max_size() underspecified</h3></a><p>
|
|
<b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 21 Oct 1999</p>
|
|
<p>Must the value returned by max_size() be unchanged from call to call? </p>
|
|
|
|
<p>Must the value returned from max_size() be meaningful? </p>
|
|
|
|
<p>Possible meanings identified in lib-6827: </p>
|
|
|
|
<p>1) The largest container the implementation can support given "best
|
|
case" conditions - i.e. assume the run-time platform is "configured to
|
|
the max", and no overhead from the program itself. This may possibly
|
|
be determined at the point the library is written, but certainly no
|
|
later than compile time.<br>
|
|
<br>
|
|
2) The largest container the program could create, given "best case"
|
|
conditions - i.e. same platform assumptions as (1), but take into
|
|
account any overhead for executing the program itself. (or, roughly
|
|
"storage=storage-sizeof(program)"). This does NOT include any resource
|
|
allocated by the program. This may (or may not) be determinable at
|
|
compile time.<br>
|
|
<br>
|
|
3) The largest container the current execution of the program could
|
|
create, given knowledge of the actual run-time platform, but again,
|
|
not taking into account any currently allocated resource. This is
|
|
probably best determined at program start-up.<br>
|
|
<br>
|
|
4) The largest container the current execution program could create at
|
|
the point max_size() is called (or more correctly at the point
|
|
max_size() returns :-), given it's current environment (i.e. taking
|
|
into account the actual currently available resources). This,
|
|
obviously, has to be determined dynamically each time max_size() is
|
|
called. </p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> table 32 max_size() wording from:<br>
|
|
<br>
|
|
the largest value that can meaningfully be
|
|
passed to X::allocate<br>
|
|
to:<br>
|
|
the value of the largest constant expression
|
|
(5.19 <a href="expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be passed to X::allocate</p>
|
|
|
|
<p>
|
|
Change 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 max_size() wording from:<br>
|
|
<br>
|
|
size() of the largest possible container.<br>
|
|
to:<br>
|
|
the value of the largest constant expression
|
|
(5.19 <a href="expr.html#expr.const"> [expr.const]</a>) that could ever meaningfully be returned by X::size().
|
|
</p>
|
|
|
|
<p><i>[Kona: The LWG informally discussed this and asked Andy Sawyer to submit
|
|
an issue.]</i></p>
|
|
|
|
<p><i>[Tokyo: The LWG believes (1) above is the intended meaning.]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: Beman Dawes supplied the above resolution at the
|
|
request of the LWG. 21.3.3 <a href="lib-strings.html#lib.string.capacity"> [lib.string.capacity]</a> was not changed because it
|
|
references max_size() in 23.1. The term "compile-time" was
|
|
avoided because it is not defined anywhere in the standard (even
|
|
though it is used several places in the library clauses).]</i></p>
|
|
|
|
<p><i>[Copenhagen: Exactly what <tt>max_size</tt> means is still
|
|
unclear. It may have a different meaning as a container member
|
|
function than as an allocator member function. For the latter,
|
|
it is probably best thought of as an architectural limit.
|
|
Nathan will provide new wording.]</i></p>
|
|
<hr>
|
|
<a name="200"><h3>200. Forward iterator requirements don't allow constant iterators</h3></a><p>
|
|
<b>Section:</b> 24.1.3 <a href="lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p>
|
|
<p>
|
|
In table 74, the return type of the expression <tt>*a</tt> is given
|
|
as <tt>T&</tt>, where <tt>T</tt> is the iterator's value type.
|
|
For constant iterators, however, this is wrong. ("Value type"
|
|
is never defined very precisely, but it is clear that the value type
|
|
of, say, <tt>std::list<int>::const_iterator</tt> is supposed to be
|
|
<tt>int</tt>, not <tt>const int</tt>.)
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
|
|
return type from "<tt>T&</tt>" to "<tt>T&</tt>
|
|
if <tt>X</tt> is mutable, otherwise <tt>const T&</tt>".
|
|
In the <tt>a->m</tt> row, change the return type from
|
|
"<tt>U&</tt>" to "<tt>U&</tt> if <tt>X</tt> is mutable,
|
|
otherwise <tt>const U&</tt>".
|
|
</p>
|
|
|
|
<p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
|
|
there are multiple const problems with the STL portion of the library
|
|
and that these should be addressed as a single package. Note
|
|
that issue <a href="lwg-closed.html#180">180</a> has already been declared NAD Future for
|
|
that very reason.]</i></p>
|
|
|
|
<p><i>[Redmond: the LWG thinks this is separable from other constness
|
|
issues. This issue is just cleanup; it clarifies language that was
|
|
written before we had iterator_traits. Proposed resolution was
|
|
modified: the original version only discussed *a. It was pointed out
|
|
that we also need to worry about *r++ and a->m.]</i></p>
|
|
|
|
<hr>
|
|
<a name="201"><h3>201. Numeric limits terminology wrong</h3></a><p>
|
|
<b>Section:</b> 18.2.1 <a href="lib-support.html#lib.limits"> [lib.limits]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 21 Dec 1999</p>
|
|
<p>
|
|
In some places in this section, the terms "fundamental types" and
|
|
"scalar types" are used when the term "arithmetic types" is intended.
|
|
The current usage is incorrect because void is a fundamental type and
|
|
pointers are scalar types, neither of which should have
|
|
specializations of numeric_limits.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 18.2 [lib.support.limits] para 1 from:</p>
|
|
<blockquote>
|
|
|
|
<p> The headers <limits>, <climits>, and <cfloat> supply characteristics of implementation-dependent fundamental types (3.9.1).</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
<blockquote>
|
|
|
|
<p> The headers <limits>, <climits>, and <cfloat> supply characteristics of implementation-dependent arithmetic types (3.9.1).</p>
|
|
</blockquote>
|
|
|
|
<p>Change 18.2.1 [lib.limits] para 1 from:</p>
|
|
<blockquote>
|
|
|
|
<p> The numeric_limits component provides a C++ program with information about various properties of the implementation's representation of the fundamental
|
|
types.</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
<blockquote>
|
|
|
|
<p> The numeric_limits component provides a C++ program with information about various properties of the implementation's representation of the arithmetic
|
|
types.</p>
|
|
</blockquote>
|
|
|
|
<p>Change 18.2.1 [lib.limits] para 2 from:</p>
|
|
<blockquote>
|
|
|
|
<p> Specializations shall be provided for each fundamental type. . .</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
<blockquote>
|
|
|
|
<p> Specializations shall be provided for each arithmetic type. . .</p>
|
|
</blockquote>
|
|
|
|
<p>Change 18.2.1 [lib.limits] para 4 from:</p>
|
|
<blockquote>
|
|
|
|
<p> Non-fundamental standard types. . .</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
<blockquote>
|
|
|
|
<p> Non-arithmetic standard types. . .</p>
|
|
</blockquote>
|
|
|
|
<p>Change 18.2.1.1 [lib.numeric.limits] para 1 from:</p>
|
|
<blockquote>
|
|
|
|
<p> The member is_specialized makes it possible to distinguish between fundamental types, which have specializations, and non-scalar types, which
|
|
do not.</p>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
<blockquote>
|
|
|
|
<p> The member is_specialized makes it possible to distinguish between arithmetic types, which have specializations, and non-arithmetic types,
|
|
which do not.</p>
|
|
</blockquote>
|
|
|
|
<p><i>[post-Toronto: The opinion of the LWG is that the wording in the
|
|
standard, as well as the wording of the proposed resolution, is
|
|
flawed. The term "arithmetic types" is well defined in C
|
|
and C++, and it is not clear that the term is being used correctly.
|
|
It is also not clear that the term "implementation
|
|
dependent" has any useful meaning in this context. The biggest
|
|
problem is that numeric_limits seems to be intended both for built-in
|
|
types and for user-defined types, and the standard doesn't make it
|
|
clear how numeric_limits applies to each of those cases. A wholesale
|
|
review of numeric_limits is needed. A paper would be welcome.]</i></p>
|
|
<hr>
|
|
<a name="202"><h3>202. unique() effects unclear when predicate not an equivalence relation</h3></a><p>
|
|
<b>Section:</b> 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 13 Jan 2000</p>
|
|
<p>
|
|
What should unique() do if you give it a predicate that is not an
|
|
equivalence relation? There are at least two plausible answers:
|
|
</p>
|
|
|
|
<blockquote>
|
|
|
|
<p>
|
|
1. You can't, because 25.2.8 says that it it "eliminates all but
|
|
the first element from every consecutive group of equal
|
|
elements..." and it wouldn't make sense to interpret "equal" as
|
|
meaning anything but an equivalence relation. [It also doesn't
|
|
make sense to interpret "equal" as meaning ==, because then there
|
|
would never be any sense in giving a predicate as an argument at
|
|
all.]
|
|
</p>
|
|
|
|
<p>
|
|
2. The word "equal" should be interpreted to mean whatever the
|
|
predicate says, even if it is not an equivalence relation
|
|
(and in particular, even if it is not transitive).
|
|
</p>
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
The example that raised this question is from Usenet:
|
|
</p>
|
|
|
|
<blockquote>
|
|
|
|
<pre>int f[] = { 1, 3, 7, 1, 2 };
|
|
int* z = unique(f, f+5, greater<int>());</pre>
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
If one blindly applies the definition using the predicate
|
|
greater<int>, and ignore the word "equal", you get:
|
|
</p>
|
|
|
|
<blockquote>
|
|
|
|
<p>
|
|
Eliminates all but the first element from every consecutive group
|
|
of elements referred to by the iterator i in the range [first, last)
|
|
for which *i > *(i - 1).
|
|
</p>
|
|
|
|
</blockquote>
|
|
|
|
<p>
|
|
The first surprise is the order of the comparison. If we wanted to
|
|
allow for the predicate not being an equivalence relation, then we
|
|
should surely compare elements the other way: pred(*(i - 1), *i). If
|
|
we do that, then the description would seem to say: "Break the
|
|
sequence into subsequences whose elements are in strictly increasing
|
|
order, and keep only the first element of each subsequence". So the
|
|
result would be 1, 1, 2. If we take the description at its word, it
|
|
would seem to call for strictly DEcreasing order, in which case the
|
|
result should be 1, 3, 7, 2.<br>
|
|
<br>
|
|
In fact, the SGI implementation of unique() does neither: It yields 1,
|
|
3, 7.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
|
|
<blockquote>
|
|
For a nonempty range, eliminates all but the first element from every
|
|
consecutive group of equivalent elements referred to by the iterator
|
|
<tt>i</tt> in the range [first+1, last) for which the following
|
|
conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
|
|
false</tt>.
|
|
</blockquote>
|
|
|
|
<p>
|
|
Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
|
|
comparison function must be an equivalence relation."
|
|
</p>
|
|
|
|
<p><i>[Redmond: discussed arguments for and against requiring the
|
|
comparison function to be an equivalence relation. Straw poll:
|
|
14-2-5. First number is to require that it be an equivalence
|
|
relation, second number is to explicitly not require that it be an
|
|
equivalence relation, third number is people who believe they need
|
|
more time to consider the issue. A separate issue: Andy Sawyer
|
|
pointed out that "i-1" is incorrect, since "i" can refer to the first
|
|
iterator in the range. Matt provided wording to address this
|
|
problem.]</i></p>
|
|
|
|
<p><i>[Curaçao: The LWG changed "... the range (first,
|
|
last)..." to "... the range [first+1, last)..." for
|
|
clarity. They considered this change close enough to editorial to not
|
|
require another round of review.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG also considered an alternative resolution: change
|
|
25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
|
|
|
|
<blockquote>
|
|
For a nonempty range, eliminates all but the first element from every
|
|
consecutive group of elements referred to by the iterator
|
|
<tt>i</tt> in the range (first, last) for which the following
|
|
conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
|
|
false</tt>.
|
|
</blockquote>
|
|
|
|
<p>
|
|
Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
|
|
comparison function need not be an equivalence relation."
|
|
</p>
|
|
|
|
|
|
<p>Informally: the proposed resolution imposes an explicit requirement
|
|
that the comparison function be an equivalence relation. The
|
|
alternative resolution does not, and it gives enough information so
|
|
that the behavior of unique() for a non-equivalence relation is
|
|
specified. Both resolutions are consistent with the behavior of
|
|
existing implementations.</p>
|
|
<hr>
|
|
<a name="225"><h3>225. std:: algorithms use of other unqualified algorithms</h3></a><p>
|
|
<b>Section:</b> 17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Apr 2000</p>
|
|
<p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
|
|
user namespaces might be found through Koenig lookup?</p>
|
|
<p>For example, a popular standard library implementation includes this
|
|
implementation of std::unique:</p>
|
|
<blockquote>
|
|
<pre>namespace std {
|
|
template <class _ForwardIter>
|
|
_ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
|
|
__first = adjacent_find(__first, __last);
|
|
return unique_copy(__first, __last, __first);
|
|
}
|
|
}</pre>
|
|
</blockquote>
|
|
<p>Imagine two users on opposite sides of town, each using unique on his own
|
|
sequences bounded by my_iterators . User1 looks at his standard library
|
|
implementation and says, "I know how to implement a more efficient
|
|
unique_copy for my_iterators", and writes:</p>
|
|
<blockquote>
|
|
<pre>namespace user1 {
|
|
class my_iterator;
|
|
// faster version for my_iterator
|
|
my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
|
|
}</pre>
|
|
</blockquote>
|
|
<p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
|
|
<p>User2 has other needs, and writes:</p>
|
|
<blockquote>
|
|
<pre>namespace user2 {
|
|
class my_iterator;
|
|
// Returns true iff *c is a unique copy of *a and *b.
|
|
bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
|
|
}</pre>
|
|
</blockquote>
|
|
<p>User2 is shocked to find later that his fully-qualified use of
|
|
std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
|
|
compile (if he's lucky). Looking in the standard, he sees the following Effects
|
|
clause for unique():</p>
|
|
<blockquote>
|
|
<p>Effects: Eliminates all but the first element from every consecutive group
|
|
of equal elements referred to by the iterator i in the range [first, last) for
|
|
which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
|
|
*(i - 1)) != false</p>
|
|
</blockquote>
|
|
<p>The standard gives user2 absolutely no reason to think he can interfere with
|
|
std::unique by defining names in namespace user2. His standard library has been
|
|
built with the template export feature, so he is unable to inspect the
|
|
implementation. User1 eventually compiles his code with another compiler, and
|
|
his version of unique_copy silently stops being called. Eventually, he realizes
|
|
that he was depending on an implementation detail of his library and had no
|
|
right to expect his unique_copy() to be called portably.</p>
|
|
<p>On the face of it, and given above scenario, it may seem obvious that the
|
|
implementation of unique() shown is non-conforming because it uses unique_copy()
|
|
rather than ::std::unique_copy(). Most standard library implementations,
|
|
however, seem to disagree with this notion.</p>
|
|
<p> <i>[Tokyo: Steve Adamczyk from
|
|
the core working group indicates that "std::" is sufficient;
|
|
leading "::" qualification is not required because any namespace
|
|
qualification is sufficient to suppress Koenig lookup.]</i>
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add a paragraph and a note at the end of
|
|
17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a>:</p>
|
|
<blockquote>
|
|
|
|
<p>Unless otherwise specified, no global or non-member function in the
|
|
standard library shall use a function from another namespace which is
|
|
found through <i>argument-dependent name lookup</i> (3.4.2 <a href="basic.html#basic.lookup.koenig"> [basic.lookup.koenig]</a>).</p>
|
|
|
|
<p>[Note: the phrase "unless otherwise specified" is intended to
|
|
allow Koenig lookup in cases like that of ostream_iterators:<br>
|
|
|
|
<br>
|
|
Effects:</p>
|
|
<blockquote>
|
|
<p>*out_stream << value;<br>
|
|
if(delim != 0) *out_stream << delim;<br>
|
|
return (*this);</p>
|
|
<p>--end note]</p>
|
|
</blockquote>
|
|
</blockquote>
|
|
|
|
<p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
|
|
is as yet unsure if the proposed resolution is the best
|
|
solution. Furthermore, the LWG believes that the same problem of
|
|
unqualified library names applies to wording in the standard itself,
|
|
and has opened issue <a href="lwg-active.html#229">229</a> accordingly. Any resolution of
|
|
issue <a href="lwg-active.html#225">225</a> should be coordinated with the resolution of
|
|
issue <a href="lwg-active.html#229">229</a>.]</i></p>
|
|
|
|
<p><i>[Toronto: The LWG is not sure if this is a defect in the
|
|
standard. Most LWG members believe that an implementation of
|
|
<tt>std::unique</tt> like the one quoted in this issue is already
|
|
illegal, since, under certain circumstances, its semantics are not
|
|
those specified in the standard. The standard's description of
|
|
<tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
|
|
should have any effect.]</i></p>
|
|
|
|
<p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
|
|
225, 226, and 229. Their conclusion was that the issues should be
|
|
separated into an LWG portion (Howard's paper, N1387=02-0045), and a
|
|
EWG portion (Dave will write a proposal). The LWG and EWG had
|
|
(separate) discussions of this plan the next day. The proposed
|
|
resolution for this issue is in accordance with Howard's paper.]</i></p>
|
|
|
|
<hr>
|
|
<a name="226"><h3>226. User supplied specializations or overloads of namespace std function templates</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#Review">Review</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Apr 2000</p>
|
|
<p>The issues are: </p>
|
|
<p>1. How can a 3rd party library implementor (lib1) write a version of a standard
|
|
algorithm which is specialized to work with his own class template? </p>
|
|
<p>2. How can another library implementor (lib2) write a generic algorithm which
|
|
will take advantage of the specialized algorithm in lib1?</p>
|
|
<p>This appears to be the only viable answer under current language rules:</p>
|
|
<blockquote>
|
|
<pre>namespace lib1
|
|
{
|
|
// arbitrary-precision numbers using T as a basic unit
|
|
template <class T>
|
|
class big_num { //...
|
|
};
|
|
</pre>
|
|
<pre> // defining this in namespace std is illegal (it would be an
|
|
// overload), so we hope users will rely on Koenig lookup
|
|
template <class T>
|
|
void swap(big_int<T>&, big_int<T>&);
|
|
}</pre>
|
|
<pre>#include <algorithm>
|
|
namespace lib2
|
|
{
|
|
template <class T>
|
|
void generic_sort(T* start, T* end)
|
|
{
|
|
...
|
|
// using-declaration required so we can work on built-in types
|
|
using std::swap;
|
|
// use Koenig lookup to find specialized algorithm if available
|
|
swap(*x, *y);
|
|
}
|
|
}</pre>
|
|
</blockquote>
|
|
<p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
|
|
and somewhat slippery. The implementor needs to remember to write the
|
|
using-declaration, or generic_sort will fail to compile when T is a built-in
|
|
type. The second drawback is that the use of this style in lib2 effectively
|
|
"reserves" names in any namespace which defines types which may
|
|
eventually be used with lib2. This may seem innocuous at first when applied to
|
|
names like swap, but consider more ambiguous names like unique_copy() instead.
|
|
It is easy to imagine the user wanting to define these names differently in his
|
|
own namespace. A definition with semantics incompatible with the standard
|
|
library could cause serious problems (see issue <a href="lwg-active.html#225">225</a>).</p>
|
|
<p>Why, you may ask, can't we just partially specialize std::swap()? It's
|
|
because the language doesn't allow for partial specialization of function
|
|
templates. If you write:</p>
|
|
<blockquote>
|
|
<pre>namespace std
|
|
{
|
|
template <class T>
|
|
void swap(lib1::big_int<T>&, lib1::big_int<T>&);
|
|
}</pre>
|
|
</blockquote>
|
|
<p>You have just overloaded std::swap, which is illegal under the current
|
|
language rules. On the other hand, the following full specialization is legal:</p>
|
|
<blockquote>
|
|
<pre>namespace std
|
|
{
|
|
template <>
|
|
void swap(lib1::other_type&, lib1::other_type&);
|
|
}</pre>
|
|
</blockquote>
|
|
|
|
<p>This issue reflects concerns raised by the "Namespace issue
|
|
with specialized swap" thread on comp.lang.c++.moderated. A
|
|
similar set of concerns was earlier raised on the boost.org mailing
|
|
list and the ACCU-general mailing list. Also see library reflector
|
|
message c++std-lib-7354.</p>
|
|
|
|
<p>
|
|
J. C. van Winkel points out (in c++std-lib-9565) another unexpected
|
|
fact: it's impossible to output a container of std::pair's using copy
|
|
and an ostream_iterator, as long as both pair-members are built-in or
|
|
std:: types. That's because a user-defined operator<< for (for
|
|
example) std::pair<const std::string, int> will not be found:
|
|
lookup for operator<< will be performed only in namespace std.
|
|
Opinions differed on whether or not this was a defect, and, if so,
|
|
whether the defect is that something is wrong with user-defined
|
|
functionality and std, or whether it's that the standard library does
|
|
not provide an operator<< for std::pair<>.
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>Adopt the wording in the <b>Customization Points</b> section of
|
|
Howard Hinnant's paper, N1387=02-0045.</p>
|
|
|
|
<p><i>[Tokyo: Summary, "There is no conforming way to extend
|
|
std::swap for user defined templates." The LWG agrees that
|
|
there is a problem. Would like more information before
|
|
proceeding. This may be a core issue. Core issue 229 has been opened
|
|
to discuss the core aspects of this problem. It was also noted that
|
|
submissions regarding this issue have been received from several
|
|
sources, but too late to be integrated into the issues list.
|
|
]</i></p>
|
|
|
|
<p><i>[Post-Tokyo: A paper with several proposed resolutions,
|
|
J16/00-0029==WG21/N1252, "Shades of namespace std functions
|
|
" by Alan Griffiths, is in the Post-Tokyo mailing. It
|
|
should be considered a part of this issue.]</i></p>
|
|
|
|
<p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
|
|
resolution that involves core changes: it would add partial
|
|
specialization of function template. The Core Working Group is
|
|
reluctant to add partial specialization of function templates. It is
|
|
viewed as a large change, CWG believes that proposal presented leaves
|
|
some syntactic issues unanswered; if the CWG does add partial
|
|
specialization of function templates, it wishes to develop its own
|
|
proposal. The LWG continues to believe that there is a serious
|
|
problem: there is no good way for users to force the library to use
|
|
user specializations of generic standard library functions, and in
|
|
certain cases (e.g. transcendental functions called by
|
|
<tt>valarray</tt> and <tt>complex</tt>) this is important. Koenig
|
|
lookup isn't adequate, since names within the library must be
|
|
qualified with <tt>std</tt> (see issue 225), specialization doesn't
|
|
work (we don't have partial specialization of function templates), and
|
|
users aren't permitted to add overloads within namespace std.
|
|
]</i></p>
|
|
|
|
<p><i>[Copenhagen: Discussed at length, with no consensus. Relevant
|
|
papers in the pre-Copenhagen mailing: N1289, N1295, N1296. Discussion
|
|
focused on four options. (1) Relax restrictions on overloads within
|
|
namespace std. (2) Mandate that the standard library use unqualified
|
|
calls for <tt>swap</tt> and possibly other functions. (3) Introduce
|
|
helper class templates for <tt>swap</tt> and possibly other functions.
|
|
(4) Introduce partial specialization of function templates. Every
|
|
option had both support and opposition. Straw poll (first number is
|
|
support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
|
|
(4) 4, 4.]</i></p>
|
|
|
|
<p><i>[Redmond: Discussed, again no consensus. Herb presented an
|
|
argument that a user who is defining a type <tt>T</tt> with an
|
|
associated <tt>swap</tt> should not be expected to put that
|
|
<tt>swap</tt> in namespace std, either by overloading or by partial
|
|
specialization. The argument is that <tt>swap</tt> is part of
|
|
<tt>T</tt>'s interface, and thus should to in the same namespace as
|
|
<tt>T</tt> and only in that namespace. If we accept this argument,
|
|
the consequence is that standard library functions should use
|
|
unqualified call of <tt>swap</tt>. (And which other functions? Any?)
|
|
A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
|
|
try to put together a proposal before the next meeting.]</i></p>
|
|
|
|
<p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
|
|
225, 226, and 229. Their conclusion was that the issues should be
|
|
separated into an LWG portion (Howard's paper, N1387=02-0045), and a
|
|
EWG portion (Dave will write a proposal). The LWG and EWG had
|
|
(separate) discussions of this plan the next day. The proposed
|
|
resolution is the one proposed by Howard.]</i></p>
|
|
|
|
<hr>
|
|
<a name="229"><h3>229. Unqualified references of other library entities</h3></a><p>
|
|
<b>Section:</b> 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 19 Apr 2000</p>
|
|
<p>Throughout the library chapters, the descriptions of library entities refer
|
|
to other library entities without necessarily qualifying the names.</p>
|
|
|
|
<p>For example, section 25.2.2 "Swap" describes the effect of
|
|
swap_ranges in terms of the unqualified name "swap". This section
|
|
could reasonably be interpreted to mean that the library must be implemented so
|
|
as to do a lookup of the unqualified name "swap", allowing users to
|
|
override any ::std::swap function when Koenig lookup applies.</p>
|
|
|
|
<p>Although it would have been best to use explicit qualification with
|
|
"::std::" throughout, too many lines in the standard would have to be
|
|
adjusted to make that change in a Technical Corrigendum.</p>
|
|
|
|
<p>Issue <a href="lwg-defects.html#182">182</a>, which addresses qualification of
|
|
<tt>size_t</tt>, is a special case of this.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
|
|
<blockquote>
|
|
<p>Whenever a name x defined in the standard library is mentioned, the name x
|
|
is assumed to be fully qualified as ::std::x, unless explicitly described
|
|
otherwise. For example, if the Effects section for library function F is
|
|
described as calling library function G, the function ::std::G is meant.</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
|
|
the LWG to solve a problem in the standard itself similar to the
|
|
problem within implementations of library identified by issue <a href="lwg-active.html#225">225</a>. Any resolution of issue <a href="lwg-active.html#225">225</a> should be
|
|
coordinated with the resolution of this issue.]</i></p>
|
|
|
|
<p><i>[post-Toronto: Howard is undecided about whether it is
|
|
appropriate for all standard library function names referred to in
|
|
other standard library functions to be explicitly qualified by
|
|
<tt>std</tt>: it is common advice that users should define global
|
|
functions that operate on their class in the same namespace as the
|
|
class, and this requires argument-dependent lookup if those functions
|
|
are intended to be called by library code. Several LWG members are
|
|
concerned that valarray appears to require argument-dependent lookup,
|
|
but that the wording may not be clear enough to fall under
|
|
"unless explicitly described otherwise".]</i></p>
|
|
|
|
<p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
|
|
225, 226, and 229. Their conclusion was that the issues should be
|
|
separated into an LWG portion (Howard's paper, N1387=02-0045), and a
|
|
EWG portion (Dave will write a proposal). The LWG and EWG had
|
|
(separate) discussions of this plan the next day. This paper resolves
|
|
issues 225 and 226. In light of that resolution, the proposed
|
|
resolution for the current issue makes sense.]</i></p>
|
|
|
|
<hr>
|
|
<a name="231"><h3>231. Precision in iostream?</h3></a><p>
|
|
<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 25 Apr 2000</p>
|
|
<p>What is the following program supposed to output?</p>
|
|
<pre>#include <iostream>
|
|
|
|
int
|
|
main()
|
|
{
|
|
std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
|
|
std::cout.precision( 0 ) ;
|
|
std::cout << 1.00 << '\n' ;
|
|
return 0 ;
|
|
}</pre>
|
|
<p>From my C experience, I would expect "1e+00"; this is what
|
|
<tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
|
|
"1.000000e+00".</p>
|
|
|
|
<p>The only indication I can find in the standard is 22.2.2.2.2/11,
|
|
where it says "For conversion from a floating-point type, if
|
|
(flags & fixed) != 0 or if str.precision() > 0, then
|
|
str.precision() is specified in the conversion specification."
|
|
This is an obvious error, however, fixed is not a mask for a field,
|
|
but a value that a multi-bit field may take -- the results of and'ing
|
|
fmtflags with ios::fixed are not defined, at least not if
|
|
ios::scientific has been set. G++'s behavior corresponds to what might
|
|
happen if you do use (flags & fixed) != 0 with a typical
|
|
implementation (floatfield == 3 << something, fixed == 1
|
|
<< something, and scientific == 2 << something).</p>
|
|
|
|
<p>Presumably, the intent is either (flags & floatfield) != 0, or
|
|
(flags & floatfield) == fixed; the first gives something more or
|
|
less like the effect of precision in a printf floating point
|
|
conversion. Only more or less, of course. In order to implement printf
|
|
formatting correctly, you must know whether the precision was
|
|
explicitly set or not. Say by initializing it to -1, instead of 6, and
|
|
stating that for floating point conversions, if precision < -1, 6
|
|
will be used, for fixed point, if precision < -1, 1 will be used,
|
|
etc. Plus, of course, if precision == 0 and flags & floatfield ==
|
|
0, 1 should be = used. But it probably isn't necessary to emulate all
|
|
of the anomalies of printf:-).</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Replace 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 11, with the following
|
|
sentence:
|
|
</p>
|
|
<blockquote>
|
|
For conversion from a floating-point type,
|
|
<tt><i>str</i>.precision()</tt> is specified in the conversion
|
|
specification.
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The floatfield determines whether numbers are formatted as if
|
|
with %f, %e, or %g. If the <tt>fixed</tt> bit is set, it's %f,
|
|
if <tt>scientific</tt> it's %e, and if both bits are set, or
|
|
neither, it's %g.</p>
|
|
<p>Turning to the C standard, a precision of 0 is meaningful
|
|
for %f and %e. For %g, precision 0 is taken to be the same as
|
|
precision 1.</p>
|
|
<p>The proposed resolution has the effect that if neither
|
|
<tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
|
|
specifying a precision of 0, which will be internally
|
|
turned into 1. There's no need to call it out as a special
|
|
case.</p>
|
|
<p>The output of the above program will be "1e+00".</p>
|
|
|
|
<p><i>[Post-Curaçao: Howard provided improved wording covering the case
|
|
where precision is 0 and mode is %g.]</i></p>
|
|
|
|
<hr>
|
|
<a name="233"><h3>233. Insertion hints in associative containers</h3></a><p>
|
|
<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Apr 2000</p>
|
|
<p>
|
|
If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
|
|
into the multimap, then <tt>mm.insert(p, x)</tt> inserts
|
|
<tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
|
|
to where it should go. Table 69 claims that the execution time is
|
|
amortized constant if the insert winds up taking place adjacent to
|
|
<tt>p</tt>, but does not say when, if ever, this is guaranteed to
|
|
happen. All it says it that <tt>p</tt> is a hint as to where to
|
|
insert.
|
|
</p>
|
|
<p>
|
|
The question is whether there is any guarantee about the relationship
|
|
between <tt>p</tt> and the insertion point, and, if so, what it
|
|
is.
|
|
</p>
|
|
<p>
|
|
I believe the present state is that there is no guarantee: The user
|
|
can supply <tt>p</tt>, and the implementation is allowed to
|
|
disregard it entirely.
|
|
</p>
|
|
|
|
<p>
|
|
<b>Additional comments from Nathan:</b><br>
|
|
|
|
The vote [in Redmond] was on whether to elaborately specify the use of
|
|
the hint, or to require behavior only if the value could be inserted
|
|
adjacent to the hint. I would like to ensure that we have a chance to
|
|
vote for a deterministic treatment: "before, if possible, otherwise
|
|
after, otherwise anywhere appropriate", as an alternative to the
|
|
proposed "before or after, if possible, otherwise [...]".
|
|
</p>
|
|
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>In table 69 "Associative Container Requirements" in 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in the row for <tt>a.insert(p, t)</tt>,
|
|
change</p>
|
|
|
|
<blockquote>
|
|
iterator p is a hint pointing to where the insert
|
|
should start to search.
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
insertion adjacent to iterator p is preferred if
|
|
more than one insertion point is valid.
|
|
</blockquote>
|
|
|
|
<p>and change</p>
|
|
|
|
<blockquote>
|
|
logarithmic in general, but amortized constant if
|
|
t is inserted right after p.
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
logarithmic in general, but amortized constant if
|
|
t is inserted adjacent to iterator p.
|
|
</blockquote>
|
|
|
|
<p><i>[Toronto: there was general agreement that this is a real defect:
|
|
when inserting an element x into a multiset that already contains
|
|
several copies of x, there is no way to know whether the hint will be
|
|
used. The proposed resolution was that the new element should always
|
|
be inserted as close to the hint as possible. So, for example, if
|
|
there is a subsequence of equivalent values, then providing a.begin()
|
|
as the hint means that the new element should be inserted before the
|
|
subsequence even if a.begin() is far away. JC van Winkel supplied
|
|
precise wording for this proposed resolution, and also for an
|
|
alternative resolution in which hints are only used when they are
|
|
adjacent to the insertion point.]</i></p>
|
|
|
|
<p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
|
|
in which an insertion hint would be used even when it is far from the
|
|
insertion point. This was contingent on seeing a reference
|
|
implementation showing that it is possible to implement this
|
|
requirement without loss of efficiency. John Potter provided such a
|
|
reference implementation.]</i></p>
|
|
|
|
<p><i>[Redmond: The LWG was reluctant to adopt the proposal that
|
|
emerged from Copenhagen: it seemed excessively complicated, and went
|
|
beyond fixing the defect that we identified in Toronto. PJP provided
|
|
the new wording described in this issue. Nathan agrees that we
|
|
shouldn't adopt the more detailed semantics, and notes: "we know that
|
|
you can do it efficiently enough with a red-black tree, but there are
|
|
other (perhaps better) balanced tree techniques that might differ
|
|
enough to make the detailed semantics hard to satisfy."]</i></p>
|
|
|
|
<p><i>[Curaçao: Nathan should give us the alternative wording he
|
|
suggests so the LWG can decide between the two options.]</i></p>
|
|
|
|
<hr>
|
|
<a name="241"><h3>241. Does unique_copy() require CopyConstructible and Assignable?</h3></a><p>
|
|
<b>Section:</b> 25.2.8 <a href="lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
|
|
|
|
<p>Some popular implementations of unique_copy() create temporary
|
|
copies of values in the input sequence, at least if the input iterator
|
|
is a pointer. Such an implementation is built on the assumption that
|
|
the value type is CopyConstructible and Assignable.</p>
|
|
|
|
<p>It is common practice in the standard that algorithms explicitly
|
|
specify any additional requirements that they impose on any of the
|
|
types used by the algorithm. An example of an algorithm that creates
|
|
temporary copies and correctly specifies the additional requirements
|
|
is accumulate(), 26.4.1 <a href="lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
|
|
|
|
<p>Since the specifications of unique() and unique_copy() do not
|
|
require CopyConstructible and Assignable of the InputIterator's value
|
|
type the above mentioned implementations are not standard-compliant. I
|
|
cannot judge whether this is a defect in the standard or a defect in
|
|
the implementations.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 25.2.8 change:</p>
|
|
|
|
<blockquote>
|
|
-4- Requires: The ranges [first, last) and [result, result+(last-first))
|
|
shall not overlap.
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
<p>-4- Requires: The ranges [first, last) and [result,
|
|
result+(last-first)) shall not overlap. The expression *result =
|
|
*first must be valid. If neither InputIterator nor OutputIterator
|
|
meets the requirements of forward iterator then the value type of
|
|
InputIterator must be copy constructible. Otherwise copy
|
|
constructible is not required. </p>
|
|
</blockquote>
|
|
|
|
<p><i>[Redmond: the original proposed resolution didn't impose an
|
|
explicit requirement that the iterator's value type must be copy
|
|
constructible, on the grounds that an input iterator's value type must
|
|
always be copy constructible. Not everyone in the LWG thought that
|
|
this requirement was clear from table 72. It has been suggested that
|
|
it might be possible to implement <tt>unique_copy</tt> without
|
|
requiring assignability, although current implementations do impose
|
|
that requirement. Howard provided new wording.]</i></p>
|
|
|
|
<p><i>[
|
|
Curaçao: The LWG changed the PR editorially to specify
|
|
"neither...nor...meet..." as clearer than
|
|
"both...and...do not meet...". Change believed to be so
|
|
minor as not to require re-review.
|
|
]</i></p>
|
|
|
|
<hr>
|
|
<a name="247"><h3>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p>
|
|
<b>Section:</b> 23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 06 June 2000</p>
|
|
<p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity
|
|
of <tt>vector::insert</tt>:</p>
|
|
|
|
<blockquote>
|
|
Complexity: If first and last are forward iterators, bidirectional
|
|
iterators, or random access iterators, the complexity is linear in
|
|
the number of elements in the range [first, last) plus the distance
|
|
to the end of the vector. If they are input iterators, the complexity
|
|
is proportional to the number of elements in the range [first, last)
|
|
times the distance to the end of the vector.
|
|
</blockquote>
|
|
|
|
<p>First, this fails to address the non-iterator forms of
|
|
<tt>insert</tt>.</p>
|
|
|
|
<p>Second, the complexity for input iterators misses an edge case --
|
|
it requires that an arbitrary number of elements can be added at
|
|
the end of a <tt>vector</tt> in constant time.</p>
|
|
|
|
<p>At the risk of strengthening the requirement, I suggest simply</p>
|
|
|
|
<blockquote>
|
|
Complexity: The complexity is linear in the number of elements
|
|
inserted plus the distance to the end of the vector.
|
|
</blockquote>
|
|
|
|
<p>For input iterators, one may achieve this complexity by first
|
|
inserting at the end of the <tt>vector</tt>, and then using
|
|
<tt>rotate</tt>.</p>
|
|
|
|
<p>I looked to see if <tt>deque</tt> had a similar problem, and was
|
|
surprised to find that <tt>deque</tt> places no requirement on the
|
|
complexity of inserting multiple elements (23.2.1.3 <a href="lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>,
|
|
paragraph 3):</p>
|
|
|
|
<blockquote>
|
|
Complexity: In the worst case, inserting a single element into a
|
|
deque takes time linear in the minimum of the distance from the
|
|
insertion point to the beginning of the deque and the distance
|
|
from the insertion point to the end of the deque. Inserting a
|
|
single element either at the beginning or end of a deque always
|
|
takes constant time and causes a single call to the copy constructor
|
|
of T.
|
|
</blockquote>
|
|
|
|
<p>I suggest:</p>
|
|
|
|
<blockquote>
|
|
Complexity: The complexity is linear in the number of elements
|
|
inserted plus the shorter of the distances to the beginning and
|
|
end of the deque. Inserting a single element at either the
|
|
beginning or the end of a deque causes a single call to the copy
|
|
constructor of T.
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p><i>[Toronto: It's agreed that there is a defect in complexity of
|
|
multi-element insert for vector and deque. For vector, the complexity
|
|
should probably be something along the lines of <tt>c<sub>1</sub> * N
|
|
+ c<sub>2</sub> * distance(i, end())</tt>. However, there is some
|
|
concern about whether it is reasonable to amortize away the copies
|
|
that we get from a reallocation whenever we exceed the vector's
|
|
capacity. For deque, the situation is somewhat less clear. Deque is
|
|
notoriously complicated, and we may not want to impose complexity
|
|
requirements that would imply any implementation technique more
|
|
complicated than a while loop whose body is a single-element
|
|
insert.]</i></p>
|
|
<hr>
|
|
<a name="253"><h3>253. valarray helper functions are almost entirely useless</h3></a><p>
|
|
<b>Section:</b> 26.3.2.1 <a href="lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.3.2.2 <a href="lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 31 Jul 2000</p>
|
|
<p>This discussion is adapted from message c++std-lib-7056 posted
|
|
November 11, 1999. I don't think that anyone can reasonably claim
|
|
that the problem described below is NAD.</p>
|
|
|
|
<p>These valarray constructors can never be called:</p>
|
|
|
|
<pre>
|
|
template <class T>
|
|
valarray<T>::valarray(const slice_array<T> &);
|
|
template <class T>
|
|
valarray<T>::valarray(const gslice_array<T> &);
|
|
template <class T>
|
|
valarray<T>::valarray(const mask_array<T> &);
|
|
template <class T>
|
|
valarray<T>::valarray(const indirect_array<T> &);
|
|
</pre>
|
|
|
|
<p>Similarly, these valarray assignment operators cannot be
|
|
called:</p>
|
|
|
|
<pre>
|
|
template <class T>
|
|
valarray<T> valarray<T>::operator=(const slice_array<T> &);
|
|
template <class T>
|
|
valarray<T> valarray<T>::operator=(const gslice_array<T> &);
|
|
template <class T>
|
|
valarray<T> valarray<T>::operator=(const mask_array<T> &);
|
|
template <class T>
|
|
valarray<T> valarray<T>::operator=(const indirect_array<T> &);
|
|
</pre>
|
|
|
|
<p>Please consider the following example:</p>
|
|
|
|
<pre>
|
|
#include <valarray>
|
|
using namespace std;
|
|
|
|
int main()
|
|
{
|
|
valarray<double> va1(12);
|
|
valarray<double> va2(va1[slice(1,4,3)]); // line 1
|
|
}
|
|
</pre>
|
|
|
|
|
|
<p>Since the valarray va1 is non-const, the result of the sub-expression
|
|
va1[slice(1,4,3)] at line 1 is an rvalue of type const
|
|
std::slice_array<double>. This slice_array rvalue is then used to
|
|
construct va2. The constructor that is used to construct va2 is
|
|
declared like this:</p>
|
|
|
|
<pre>
|
|
template <class T>
|
|
valarray<T>::valarray(const slice_array<T> &);
|
|
</pre>
|
|
|
|
<p>Notice the constructor's const reference parameter. When the
|
|
constructor is called, a slice_array must be bound to this reference.
|
|
The rules for binding an rvalue to a const reference are in 8.5.3,
|
|
paragraph 5 (see also 13.3.3.1.4). Specifically, paragraph 5
|
|
indicates that a second slice_array rvalue is constructed (in this
|
|
case copy-constructed) from the first one; it is this second rvalue
|
|
that is bound to the reference parameter. Paragraph 5 also requires
|
|
that the constructor that is used for this purpose be callable,
|
|
regardless of whether the second rvalue is elided. The
|
|
copy-constructor in this case is not callable, however, because it is
|
|
private. Therefore, the compiler should report an error.</p>
|
|
|
|
<p>Since slice_arrays are always rvalues, the valarray constructor that has a
|
|
parameter of type const slice_array<T> & can never be called. The
|
|
same reasoning applies to the three other constructors and the four
|
|
assignment operators that are listed at the beginning of this post.
|
|
Furthermore, since these functions cannot be called, the valarray helper
|
|
classes are almost entirely useless.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>slice_array:</p>
|
|
<ul>
|
|
<li> remove the copy constructor and copy-assignment operator declarations
|
|
from the slice_array class template definition in 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> </li>
|
|
<li> remove paragraph 3 of 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
|
|
</li>
|
|
<li> remove the copy constructor declaration from 26.3.5.1 <a href="lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a>
|
|
</li>
|
|
<li> change paragraph 1 of 26.3.5.1 <a href="lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> to read "This constructor is declared
|
|
to be private. This constructor need not be defined."</li>
|
|
<li> remove the copy-assignment operator declaration from 26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a>
|
|
</li>
|
|
<li> remove the first sentence of paragraph 1 of 26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a>
|
|
</li>
|
|
<li> Change the first two words of the second sentence of paragraph 1 of
|
|
26.3.5.2 <a href="lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> to "This function."</li>
|
|
</ul>
|
|
|
|
<p>gslice_array:</p>
|
|
<ul>
|
|
<li> remove the copy constructor and copy-assignment operator declarations
|
|
from the gslice_array class template definition in 26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> </li>
|
|
<li> remove the note in paragraph 3 of 26.3.7 <a href="lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
|
|
</li>
|
|
<li> remove the copy constructor declaration from 26.3.7.1 <a href="lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a>
|
|
</li>
|
|
<li> change paragraph 1 of 26.3.7.1 <a href="lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> to read "This constructor is declared
|
|
to be private. This constructor need not be defined."</li>
|
|
<li> remove the copy-assignment operator declaration from 26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a>
|
|
</li>
|
|
<li> remove the first sentence of paragraph 1 of 26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a>
|
|
</li>
|
|
<li> Change the first two words of the second sentence of paragraph 1 of
|
|
26.3.7.2 <a href="lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> to "This function."</li>
|
|
</ul>
|
|
|
|
<p>mask_array:</p>
|
|
<ul>
|
|
<li> remove the copy constructor and copy-assignment operator declarations
|
|
from the mask_array class template definition in 26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> </li>
|
|
<li> remove the note in paragraph 2 of 26.3.8 <a href="lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
|
|
</li>
|
|
<li> remove the copy constructor declaration from 26.3.8.1 <a href="lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a>
|
|
</li>
|
|
<li> change paragraph 1 of 26.3.8.1 <a href="lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> to read "This constructor is declared
|
|
to be private. This constructor need not be defined."</li>
|
|
<li> remove the first sentence of paragraph 1 of 26.3.8.2 <a href="lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a>
|
|
</li>
|
|
<li> Change the first two words of the second sentence of paragraph 1 of
|
|
26.3.8.2 <a href="lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> to "This function."</li>
|
|
</ul>
|
|
|
|
<p>indirect_array:</p>
|
|
<ul>
|
|
<li>remove the copy constructor and copy-assignment operator declarations
|
|
from the indirect_array class definition in 26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
|
|
</li>
|
|
<li> remove the note in paragraph 2 of 26.3.9 <a href="lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
|
|
</li>
|
|
<li> remove the copy constructor declaration from 26.3.9.1 <a href="lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a>
|
|
</li>
|
|
<li> change the descriptive text in 26.3.9.1 <a href="lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> to read "This constructor is
|
|
declared to be private. This constructor need not be defined."</li>
|
|
<li> remove the first sentence of paragraph 1 of 26.3.9.2 <a href="lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a>
|
|
</li>
|
|
<li> Change the first two words of the second sentence of paragraph 1 of
|
|
26.3.9.2 <a href="lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> to "This function."</li>
|
|
</ul>
|
|
<p><i>[This wording is taken from Robert Klarer's reflector message,
|
|
c++std-lib-7827. Gabriel Dos Reis agrees that this general solution
|
|
is correct.]</i></p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>Keeping the valarray constructors private is untenable. Merely
|
|
making valarray a friend of the helper classes isn't good enough,
|
|
because access to the copy constructor is checked in the user's
|
|
environment.</p>
|
|
|
|
<p>Making the assignment operator public is not strictly necessary to
|
|
solve this problem. A majority of the LWG <i>(straw poll: 13-4)</i>
|
|
believed we should make the assignment operators public, in addition
|
|
to the copy constructors, for reasons of symmetry and user
|
|
expectation.</p>
|
|
<hr>
|
|
<a name="254"><h3>254. Exception types in clause 19 are constructed from <tt>std::string</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 19.1 <a href="lib-diagnostics.html#lib.std.exceptions"> [lib.std.exceptions]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Aug 2000</p>
|
|
<p>
|
|
Many of the standard exception types which implementations are
|
|
required to throw are constructed with a const std::string&
|
|
parameter. For example:
|
|
</p>
|
|
|
|
<pre>
|
|
19.1.5 Class out_of_range [lib.out.of.range]
|
|
namespace std {
|
|
class out_of_range : public logic_error {
|
|
public:
|
|
explicit out_of_range(const string& what_arg);
|
|
};
|
|
}
|
|
|
|
1 The class out_of_range defines the type of objects thrown as excep-
|
|
tions to report an argument value not in its expected range.
|
|
|
|
out_of_range(const string& what_arg);
|
|
|
|
Effects:
|
|
Constructs an object of class out_of_range.
|
|
Postcondition:
|
|
strcmp(what(), what_arg.c_str()) == 0.
|
|
</pre>
|
|
|
|
<p>
|
|
There are at least two problems with this:
|
|
</p>
|
|
<ol>
|
|
<li>A program which is low on memory may end up throwing
|
|
std::bad_alloc instead of out_of_range because memory runs out while
|
|
constructing the exception object.</li>
|
|
<li>An obvious implementation which stores a std::string data member
|
|
may end up invoking terminate() during exception unwinding because the
|
|
exception object allocates memory (or rather fails to) as it is being
|
|
copied.</li>
|
|
</ol>
|
|
|
|
<p>
|
|
There may be no cure for (1) other than changing the interface to
|
|
out_of_range, though one could reasonably argue that (1) is not a
|
|
defect. Personally I don't care that much if out-of-memory is reported
|
|
when I only have 20 bytes left, in the case when out_of_range would
|
|
have been reported. People who use exception-specifications might care
|
|
a lot, though.
|
|
</p>
|
|
|
|
<p>
|
|
There is a cure for (2), but it isn't completely obvious. I think a
|
|
note for implementors should be made in the standard. Avoiding
|
|
possible termination in this case shouldn't be left up to chance. The
|
|
cure is to use a reference-counted "string" implementation
|
|
in the exception object. I am not necessarily referring to a
|
|
std::string here; any simple reference-counting scheme for a NTBS
|
|
would do.
|
|
</p>
|
|
|
|
<p><b>Further discussion, in email:</b></p>
|
|
|
|
<p>
|
|
...I'm not so concerned about (1). After all, a library implementation
|
|
can add const char* constructors as an extension, and users don't
|
|
<i>need</i> to avail themselves of the standard exceptions, though this is
|
|
a lame position to be forced into. FWIW, std::exception and
|
|
std::bad_alloc don't require a temporary basic_string.
|
|
</p>
|
|
|
|
<p>
|
|
...I don't think the fixed-size buffer is a solution to the problem,
|
|
strictly speaking, because you can't satisfy the postcondition
|
|
<br>
|
|
<tt> strcmp(what(), what_arg.c_str()) == 0</tt>
|
|
<br>
|
|
For all values of what_arg (i.e. very long values). That means that
|
|
the only truly conforming solution requires a dynamic allocation.
|
|
</p>
|
|
|
|
<p><b>Further discussion, from Redmond:</b></p>
|
|
|
|
<p>The most important progress we made at the Redmond meeting was
|
|
realizing that there are two separable issues here: the const
|
|
string& constructor, and the copy constructor. If a user writes
|
|
something like <tt>throw std::out_of_range("foo")</tt>, the const
|
|
string& constructor is invoked before anything gets thrown. The
|
|
copy constructor is potentially invoked during stack unwinding.</p>
|
|
|
|
<p>The copy constructor is a more serious problem, becuase failure
|
|
during stack unwinding invokes <tt>terminate</tt>. The copy
|
|
constructor must be nothrow. <i>Curaçao: Howard thinks this
|
|
requirement is already present.</i>
|
|
</p>
|
|
|
|
<p>The fundamental problem is that it's difficult to get the nothrow
|
|
requirement to work well with the requirement that the exception
|
|
objects store a string of unbounded size, particularly if you also try
|
|
to make the const string& constructor nothrow. Options discussed
|
|
include:</p>
|
|
|
|
<ul>
|
|
<li>Limit the size of a string that exception objects are required to
|
|
throw: change the postconditions of 19.1.2 <a href="lib-diagnostics.html#lib.domain.error"> [lib.domain.error]</a> paragraph 3
|
|
and 19.1.6 <a href="lib-diagnostics.html#lib.runtime.error"> [lib.runtime.error]</a> paragraph 3 to something like this:
|
|
"strncmp(what(), what_arg._str(), N) == 0, where N is an
|
|
implementation defined constant no smaller than 256".</li>
|
|
<li>Allow the const string& constructor to throw, but not the
|
|
copy constructor. It's the implementor's responsibility to get it
|
|
right. (An implementor might use a simple refcount class.)</li>
|
|
<li>Compromise between the two: an implementation is not allowed to
|
|
throw if the string's length is less than some N, but, if it doesn't
|
|
throw, the string must compare equal to the argument.</li>
|
|
<li>Add a new constructor that takes a const char*</li>
|
|
</ul>
|
|
|
|
<p>(Not all of these options are mutually exclusive.)</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>NAD/Future</p>
|
|
<p><b>Rationale:</b></p>
|
|
|
|
<p>Throwing a bad_alloc while trying to construct a message for another
|
|
exception-derived class is not necessarily a bad thing. And the
|
|
bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
|
|
|
|
<p>
|
|
The copy constructors of all exception-derived classes already have a
|
|
no throw spec. Reference 18.6.1, 19.1 and 15.4/13.
|
|
</p>
|
|
|
|
<p><b>Future:</b></p>
|
|
|
|
<p>All involved would like to see const char* constructors added, but
|
|
this should probably be done for C++0X as opposed to a DR.</p>
|
|
|
|
<p>I believe the no throw specs currently decorating these functions
|
|
could be improved by some kind of static no throw spec checking
|
|
mechanism (in a future C++ language). As they stand, the copy
|
|
constructors might fail via a call to unexpected. I think what is
|
|
intended here is that the copy constructors can't fail.</p>
|
|
|
|
<p><i>[Toronto: some LWG members thought this was merely a QoI issue,
|
|
but most believed that it was at least a borderline defect. There was
|
|
more support for nonnormative advice to implementors than for a
|
|
normative change.]</i></p>
|
|
|
|
<p><i>[Redmond: discussed, without definite conclusion. Most LWG
|
|
members thought there was a real defect lurking here. The above
|
|
proposed resolution/rationale is from Howard, Herb, Kevlin, Martin,
|
|
and Dave.]</i></p>
|
|
|
|
<hr>
|
|
<a name="258"><h3>258. Missing allocator requirement</h3></a><p>
|
|
<b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Aug 2000</p>
|
|
<p>
|
|
From lib-7752:
|
|
</p>
|
|
|
|
<p>
|
|
I've been assuming (and probably everyone else has been assuming) that
|
|
allocator instances have a particular property, and I don't think that
|
|
property can be deduced from anything in Table 32.
|
|
</p>
|
|
|
|
<p>
|
|
I think we have to assume that allocator type conversion is a
|
|
homomorphism. That is, if x1 and x2 are of type X, where
|
|
X::value_type is T, and if type Y is X::template
|
|
rebind<U>::other, then Y(x1) == Y(x2) if and only if x1 == x2.
|
|
</p>
|
|
|
|
<p>
|
|
Further discussion: Howard Hinnant writes, in lib-7757:
|
|
</p>
|
|
|
|
<p>
|
|
I think I can prove that this is not provable by Table 32. And I agree
|
|
it needs to be true except for the "and only if". If x1 != x2, I see no
|
|
reason why it can't be true that Y(x1) == Y(x2). Admittedly I can't
|
|
think of a practical instance where this would happen, or be valuable.
|
|
But I also don't see a need to add that extra restriction. I think we
|
|
only need:
|
|
</p>
|
|
|
|
<blockquote>
|
|
if (x1 == x2) then Y(x1) == Y(x2)
|
|
</blockquote>
|
|
|
|
<p>
|
|
If we decide that == on allocators is transitive, then I think I can
|
|
prove the above. But I don't think == is necessarily transitive on
|
|
allocators. That is:
|
|
</p>
|
|
|
|
<p>
|
|
Given x1 == x2 and x2 == x3, this does not mean x1 == x3.
|
|
</p>
|
|
|
|
<p>Example:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
x1 can deallocate pointers from: x1, x2, x3 <br>
|
|
x2 can deallocate pointers from: x1, x2, x4 <br>
|
|
x3 can deallocate pointers from: x1, x3 <br>
|
|
x4 can deallocate pointers from: x2, x4
|
|
</p>
|
|
|
|
<p>
|
|
x1 == x2, and x2 == x4, but x1 != x4
|
|
</p>
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p><i>[Toronto: LWG members offered multiple opinions. One
|
|
opinion is that it should not be required that <tt>x1 == x2</tt>
|
|
implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
|
|
required that <tt>X(x1) == x1</tt>. Another opinion is that
|
|
the second line from the bottom in table 32 already implies the
|
|
desired property. This issue should be considered in light of
|
|
other issues related to allocator instances.]</i></p>
|
|
<hr>
|
|
<a name="278"><h3>278. What does iterator validity mean?</h3></a><p>
|
|
<b>Section:</b> 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 27 Nov 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>
|
|
But what does the C++ Standard mean by "invalidate"? You
|
|
can still dereference the iterator to a spliced list element, but
|
|
you'd better not use it to delimit a range within the original
|
|
list. For the latter operation, it has definitely lost some of its
|
|
validity.
|
|
</p>
|
|
|
|
<p>
|
|
If we accept the proposed resolution to issue <a href="lwg-defects.html#250">250</a>,
|
|
then we'd better clarify that a "valid" iterator need no
|
|
longer designate an element within the same container as it once did.
|
|
We then have to clarify what we mean by invalidating a past-the-end
|
|
iterator, as when a vector or string grows by reallocation. Clearly,
|
|
such an iterator has a different kind of validity. Perhaps we should
|
|
introduce separate terms for the two kinds of "validity."
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the following text to the end of section 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>,
|
|
after paragraph 5:</p>
|
|
<blockquote>
|
|
An <i>invalid</i> iterator is an iterator that may be
|
|
singular. [Footnote: This definition applies to pointers, since
|
|
pointers are iterators. The effect of dereferencing an iterator that
|
|
has been invalidated is undefined.]
|
|
</blockquote>
|
|
|
|
<p><i>[post-Copenhagen: Matt provided wording.]</i></p>
|
|
|
|
<p><i>[Redmond: General agreement with the intent, some objections to
|
|
the wording. Dave provided new wording.]</i></p>
|
|
|
|
<p><i>[Curaçao: The definition of "singular" is
|
|
contentious. The 278 resolution must be made consistent with
|
|
issue <a href="lwg-defects.html#208">208</a> and 24.1/5. Furthermore, a Rationale paragraph
|
|
is required.]</i></p>
|
|
|
|
<hr>
|
|
<a name="280"><h3>280. Comparison of reverse_iterator to const reverse_iterator</h3></a><p>
|
|
<b>Section:</b> 24.4.1 <a href="lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Steve Cleary <b>Date:</b> 27 Nov 2000</p>
|
|
<p>
|
|
This came from an email from Steve Cleary to Fergus in reference to
|
|
issue <a href="lwg-active.html#179">179</a>. The library working group briefly discussed
|
|
this in Toronto and believed it should be a separate issue. There was
|
|
also some reservations about whether this was a worthwhile problem to
|
|
fix.
|
|
</p>
|
|
|
|
<p>
|
|
Steve said: "Fixing reverse_iterator. std::reverse_iterator can
|
|
(and should) be changed to preserve these additional
|
|
requirements." He also said in email that it can be done without
|
|
breaking user's code: "If you take a look at my suggested
|
|
solution, reverse_iterator doesn't have to take two parameters; there
|
|
is no danger of breaking existing code, except someone taking the
|
|
address of one of the reverse_iterator global operator functions, and
|
|
I have to doubt if anyone has ever done that. . . <i>But</i>, just in
|
|
case they have, you can leave the old global functions in as well --
|
|
they won't interfere with the two-template-argument functions. With
|
|
that, I don't see how <i>any</i> user code could break."
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
<b>Section:</b> 24.4.1.1 <a href="lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
|
|
add/change the following declarations:</p>
|
|
<pre>
|
|
A) Add a templated assignment operator, after the same manner
|
|
as the templated copy constructor, i.e.:
|
|
|
|
template < class U >
|
|
reverse_iterator < Iterator >& operator=(const reverse_iterator< U >& u);
|
|
|
|
B) Make all global functions (except the operator+) have
|
|
two template parameters instead of one, that is, for
|
|
operator ==, !=, <, >, <=, >=, - replace:
|
|
|
|
template < class Iterator >
|
|
typename reverse_iterator< Iterator >::difference_type operator-(
|
|
const reverse_iterator< Iterator >& x,
|
|
const reverse_iterator< Iterator >& y);
|
|
|
|
with:
|
|
|
|
template < class Iterator1, class Iterator2 >
|
|
typename reverse_iterator < Iterator1 >::difference_type operator-(
|
|
const reverse_iterator < Iterator1 > & x,
|
|
const reverse_iterator < Iterator2 > & y);
|
|
</pre>
|
|
<p>
|
|
Also make the addition/changes for these signatures in
|
|
24.4.1.3 <a href="lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
|
|
</p>
|
|
|
|
<p><i>[
|
|
Copenhagen: The LWG is concerned that the proposed resolution
|
|
introduces new overloads. Experience shows that introducing
|
|
overloads is always risky, and that it would be inappropriate to
|
|
make this change without implementation experience. It may be
|
|
desirable to provide this feature in a different way.
|
|
]</i></p>
|
|
|
|
<hr>
|
|
<a name="282"><h3>282. What types does numpunct grouping refer to?</h3></a><p>
|
|
<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 5 Dec 2000</p>
|
|
<p>
|
|
Paragraph 16 mistakenly singles out integral types for inserting
|
|
thousands_sep() characters. This conflicts with the syntax for floating
|
|
point numbers described under 22.2.3.1/2.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change paragraph 16 from:</p>
|
|
|
|
<blockquote>
|
|
For integral types, punct.thousands_sep() characters are inserted into
|
|
the sequence as determined by the value returned by punct.do_grouping()
|
|
using the method described in 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
|
|
</blockquote>
|
|
|
|
<p>To:</p>
|
|
|
|
<blockquote>
|
|
For arithmetic types, punct.thousands_sep() characters are inserted into
|
|
the sequence as determined by the value returned by punct.do_grouping()
|
|
using the method described in 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
|
|
</blockquote>
|
|
|
|
<p><i>[
|
|
Copenhagen: Opinions were divided about whether this is actually an
|
|
inconsistency, but at best it seems to have been unintentional. This
|
|
is only an issue for floating-point output: The standard is
|
|
unambiguous that implementations must parse thousands_sep characters
|
|
when performing floating-point. The standard is also unambiguous that
|
|
this requirement does not apply to the "C" locale.
|
|
]</i></p>
|
|
|
|
<p><i>[
|
|
A survey of existing practice is needed; it is believed that some
|
|
implementations do insert thousands_sep characters for floating-point
|
|
output and others fail to insert thousands_sep characters for
|
|
floating-point input even though this is unambiguously required by the
|
|
standard.
|
|
]</i></p>
|
|
|
|
<p><i>[Post-Curaçao: the above proposed resolution is the consensus of
|
|
Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
|
|
|
|
<hr>
|
|
<a name="283"><h3>283. std::replace() requirement incorrect/insufficient</h3></a><p>
|
|
<b>Section:</b> 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Dec 2000</p>
|
|
<p>
|
|
The requirements in 25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>, p1 that <tt>T</tt> to be
|
|
<tt>Assignable</tt> (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) is not necessary or
|
|
sufficient for either of the algorithms. The algorithms require that
|
|
<tt>std::iterator_traits<ForwardIterator>::value_type</tt> be
|
|
<tt>Assignable</tt> and that both
|
|
<tt>std::iterator_traits<ForwardIterator>::value_type</tt> and be
|
|
<tt>EqualityComparable</tt> (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>) with respect to
|
|
one another.
|
|
</p>
|
|
|
|
<p>
|
|
<b>Further discussion, from Jeremy</b>:
|
|
</p>
|
|
|
|
<p>There are a number of problems with the requires clauses for the
|
|
algorithms in 25.1 <a href="lib-algorithms.html#lib.alg.nonmodifying"> [lib.alg.nonmodifying]</a> and 25.2 <a href="lib-algorithms.html#lib.alg.modifying.operations"> [lib.alg.modifying.operations]</a>. The requires
|
|
clause of each algorithm should describe the necessary and sufficient
|
|
requirements on the inputs to the algorithm such that the algorithm
|
|
compiles and runs properly. Many of the requires clauses fail to do
|
|
this. Here is a summary of the kinds of mistakes:</p>
|
|
|
|
<ol>
|
|
<li> Use of EqualityComparable, which only puts requirements on a single
|
|
type, when in fact an equality operator is required between two
|
|
different types, typically either T and the iterators value_type
|
|
or between the value_type's of two different iterators.</li>
|
|
|
|
<li> Use of Assignable for T when in fact what was needed is Assignable
|
|
for the value_type of the iterator, and convertability from T to the
|
|
value_type of the iterator. Or for output iterators, the requirement
|
|
should be that T is writable to the iterator (output iterators do
|
|
not have value types; see issue <a href="lwg-active.html#324">324</a>).</li>
|
|
|
|
<li> Lack of a requires clause.</li>
|
|
</ol>
|
|
|
|
<p>Here is the list of algorithms that contain mistakes:</p>
|
|
<ul>
|
|
<li>25.1.2 <a href="lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a>
|
|
</li>
|
|
<li>25.1.3 <a href="lib-algorithms.html#lib.alg.find.end"> [lib.alg.find.end]</a>
|
|
</li>
|
|
<li>25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a>
|
|
</li>
|
|
<li>25.1.6 <a href="lib-algorithms.html#lib.alg.count"> [lib.alg.count]</a>
|
|
</li>
|
|
<li>25.1.7 <a href="lib-algorithms.html#lib.mismatch"> [lib.mismatch]</a>
|
|
</li>
|
|
<li>25.1.8 <a href="lib-algorithms.html#lib.alg.equal"> [lib.alg.equal]</a>
|
|
</li>
|
|
<li>25.1.9 <a href="lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a>
|
|
</li>
|
|
<li>25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>
|
|
</li>
|
|
<li>25.2.5 <a href="lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a>
|
|
</li>
|
|
<li>25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Also, in the requirements for EqualityComparable, the requirement that
|
|
the operator be defined for const objects is lacking.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a> Change p1 from</p>
|
|
|
|
<blockquote>
|
|
In Table 28, T is a type to be supplied by a C++ program instantiating
|
|
a template, a, b, and c are values of type T.
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
In Table 28, T is a type to be supplied by a C++ program instantiating
|
|
a template, a, b, and c are values of type const T.
|
|
</blockquote>
|
|
|
|
<p>25.1.2 <a href="lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a> Change p1 from</p>
|
|
|
|
<blockquote>
|
|
Requires: Type T is EqualityComparable (20.1.1).
|
|
</blockquote>
|
|
|
|
<p>to </p>
|
|
|
|
<blockquote>
|
|
Requires: There must be a equality operator defined that accepts type
|
|
std::iterator_traits<InputIterator>::reference for the left operand
|
|
and const T for the right operand.
|
|
</blockquote>
|
|
|
|
|
|
<p>25.1.3 <a href="lib-algorithms.html#lib.alg.find.end"> [lib.alg.find.end]</a> Add the following requires clause</p>
|
|
|
|
<blockquote>
|
|
Requires: There must be an equality operator defined that accepts
|
|
type const std::iterator_traits<ForwardIterator1>::value_type for the
|
|
left operand and const
|
|
std::iterator_traits<ForwardIterator2>::value_type for the right
|
|
operand.
|
|
</blockquote>
|
|
|
|
<p>25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> Add the following requires clause</p>
|
|
|
|
<blockquote>
|
|
Requires: There must be an equality operator defined that accepts
|
|
type const std::iterator_traits<ForwardIterator1>::value_type for the
|
|
left operand and const
|
|
std::iterator_traits<ForwardIterator2>::value_type for the right
|
|
operand.
|
|
</blockquote>
|
|
|
|
|
|
<p>25.1.5 <a href="lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> Add the following requires clause</p>
|
|
|
|
<blockquote>
|
|
Requires: T must be EqualityComparable (20.1.1).
|
|
</blockquote>
|
|
|
|
<p>25.1.6 <a href="lib-algorithms.html#lib.alg.count"> [lib.alg.count]</a> Change p1 from</p>
|
|
|
|
<blockquote>
|
|
Requires: Type T is EqualityComparable (20.1.1).
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
Requires: There must be a equality operator defined that accepts type
|
|
std::iterator_traits<InputIterator>::reference for the left operand
|
|
and const T for the right operand.
|
|
</blockquote>
|
|
|
|
<p>25.1.7 <a href="lib-algorithms.html#lib.mismatch"> [lib.mismatch]</a> Add the following requires clause</p>
|
|
|
|
<blockquote>
|
|
Requires: There must be an equality operator defined that accepts type
|
|
std::iterator_traits<InputIterator1>::reference for the left operand
|
|
and std::iterator_traits<InputIterator2>::reference for the right operand.
|
|
</blockquote>
|
|
|
|
|
|
<p>25.1.8 <a href="lib-algorithms.html#lib.alg.equal"> [lib.alg.equal]</a> Add the following requires clause</p>
|
|
|
|
<blockquote>
|
|
Requires: There must be an equality operator defined that accepts type
|
|
std::iterator_traits<InputIterator1>::reference for the left operand
|
|
and std::iterator_traits<InputIterator2>::reference for the right operand.
|
|
</blockquote>
|
|
|
|
<p>25.1.9 <a href="lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a> Add the following requires clause</p>
|
|
|
|
<blockquote>
|
|
Requires: There must be an equality operator defined that accepts
|
|
type const std::iterator_traits<ForwardIterator1>::value_type for
|
|
the left operand and const
|
|
std::iterator_traits<ForwardIterator2>::value_type for the right
|
|
operand.
|
|
</blockquote>
|
|
|
|
<p>Change change p4 from</p>
|
|
|
|
<blockquote>
|
|
Requires: Type T is EqualityComparable (20.1.1), type Size is
|
|
convertible to integral type (4.7.12.3).
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
Requires: There must be an equality operator defined that accepts
|
|
const std::iterator_traits<ForwardIterator>::value_type for the left
|
|
operand and const T for the right operand. The type Size is convertible to
|
|
integral type (4.7.12.3).
|
|
</blockquote>
|
|
|
|
<p>25.2.4 <a href="lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> Change p1 from</p>
|
|
|
|
<blockquote>
|
|
Requires: Type T is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) (and, for replace(),
|
|
EqualityComparable (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>)).
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
Requires: Type std::iterator_traits<ForwardIterator>::value_type
|
|
is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) and the type const T is convertible to
|
|
std::iterator_traits<ForwardIterator>::value_type. For replace(), an
|
|
equality operator must be defined that accepts type
|
|
std::iterator_traits<ForwardIterator>::reference for the left operand
|
|
and const T for the right operand.
|
|
</blockquote>
|
|
|
|
<p>and change p4 from</p>
|
|
|
|
<blockquote>
|
|
Requires: Type T is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>) (and, for replace_copy(),
|
|
EqualityComparable (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>)). The ranges [first, last) and [result,
|
|
result + (last - first)) shall not overlap.
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
Requires: Both types const T and
|
|
std::iterator_traits<InputIterator>::reference are writable to the
|
|
OutputIterator type. For replace_copy() an equality operator must be
|
|
defined that accepts type
|
|
std::iterator_traits<InputIterator>::reference for the left operand
|
|
and const T for the right operand. The ranges [first, last) and [result,
|
|
result + (last - first)) shall not overlap.
|
|
</blockquote>
|
|
|
|
<p>25.2.5 <a href="lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a> Change p1 from</p>
|
|
|
|
<blockquote>
|
|
Requires: Type T is Assignable (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> ). Size is convertible to an integral
|
|
type (3.9.1 <a href="basic.html#basic.fundamental"> [basic.fundamental]</a> ).
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
Requires: Type const T is writable to the OutputIterator. Size is
|
|
convertible to an integral type (3.9.1 <a href="basic.html#basic.fundamental"> [basic.fundamental]</a> ).
|
|
</blockquote>
|
|
|
|
|
|
<p>25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> Change p1 from</p>
|
|
|
|
<blockquote>
|
|
Requires: Type T is EqualityComparable (20.1.1 <a href="lib-utilities.html#lib.equalitycomparable"> [lib.equalitycomparable]</a>).
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
Requires: There must be an equality operator defined that accepts
|
|
type const std::iterator_traits<ForwardIterator>::value_type for the left
|
|
operand and const T for the right operand. The type
|
|
std::iterator_traits<ForwardIterator>::value_type must be Assignable
|
|
(23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>).
|
|
</blockquote>
|
|
|
|
<p><i>[Curaçao: Jeremy reports he has run the changes through his
|
|
automated test tools. At the request of the LWG, Jeremy will reword
|
|
the PR in terms of valid expressions rather than "equality
|
|
operator".]</i></p>
|
|
|
|
<hr>
|
|
<a name="290"><h3>290. Requirements to for_each and its function object</h3></a><p>
|
|
<b>Section:</b> 25.1.1 <a href="lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 03 Jan 2001</p>
|
|
<p>The specification of the for_each algorithm does not have a
|
|
"Requires" section, which means that there are no
|
|
restrictions imposed on the function object whatsoever. In essence it
|
|
means that I can provide any function object with arbitrary side
|
|
effects and I can still expect a predictable result. In particular I
|
|
can expect that the function object is applied exactly last - first
|
|
times, which is promised in the "Complexity" section.
|
|
</p>
|
|
|
|
<p>I don't see how any implementation can give such a guarantee
|
|
without imposing requirements on the function object.
|
|
</p>
|
|
|
|
<p>Just as an example: consider a function object that removes
|
|
elements from the input sequence. In that case, what does the
|
|
complexity guarantee (applies f exactly last - first times) mean?
|
|
</p>
|
|
|
|
<p>One can argue that this is obviously a nonsensical application and
|
|
a theoretical case, which unfortunately it isn't. I have seen
|
|
programmers shooting themselves in the foot this way, and they did not
|
|
understand that there are restrictions even if the description of the
|
|
algorithm does not say so.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add a "Requires" section to section 25.1.1 similar to those
|
|
proposed for transform and the numeric algorithms (see issue
|
|
<a href="lwg-defects.html#242">242</a>):
|
|
</p>
|
|
|
|
<blockquote>
|
|
-2- <b>Requires</b>: In the range [first, last], f shall not invalidate
|
|
iterators or subranges.
|
|
</blockquote>
|
|
|
|
<p><i>[Copenhagen: The LWG agrees that a function object passed to an
|
|
algorithm should not invalidate iterators in the range that the
|
|
algorithm is operating on. The LWG believes that this should be a
|
|
blanket statement in Clause 25, not just a special requirement for
|
|
<tt>for_each</tt>.
|
|
]</i></p>
|
|
|
|
<hr>
|
|
<a name="291"><h3>291. Underspecification of set algorithms</h3></a><p>
|
|
<b>Section:</b> 25.3.5 <a href="lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 03 Jan 2001</p>
|
|
<p>
|
|
The standard library contains four algorithms that compute set
|
|
operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
|
|
<tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>. Each
|
|
of these algorithms takes two sorted ranges as inputs, and writes the
|
|
output of the appropriate set operation to an output range. The elements
|
|
in the output range are sorted.
|
|
</p>
|
|
|
|
<p>
|
|
The ordinary mathematical definitions are generalized so that they
|
|
apply to ranges containing multiple copies of a given element. Two
|
|
elements are considered to be "the same" if, according to an
|
|
ordering relation provided by the user, neither one is less than the
|
|
other. So, for example, if one input range contains five copies of an
|
|
element and another contains three, the output range of <tt>set_union</tt>
|
|
will contain five copies, the output range of
|
|
<tt>set_intersection</tt> will contain three, the output range of
|
|
<tt>set_difference</tt> will contain two, and the output range of
|
|
<tt>set_symmetric_difference</tt> will contain two.
|
|
</p>
|
|
|
|
<p>
|
|
Because two elements can be "the same" for the purposes
|
|
of these set algorithms, without being identical in other respects
|
|
(consider, for example, strings under case-insensitive comparison),
|
|
this raises a number of unanswered questions:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>If we're copying an element that's present in both of the
|
|
input ranges, which one do we copy it from?</li>
|
|
<li>If there are <i>n</i> copies of an element in the relevant
|
|
input range, and the output range will contain fewer copies (say
|
|
<i>m</i>) which ones do we choose? The first <i>m</i>, or the last
|
|
<i>m</i>, or something else?</li>
|
|
<li>Are these operations stable? That is, does a run of equivalent
|
|
elements appear in the output range in the same order as as it
|
|
appeared in the input range(s)?</li>
|
|
</ul>
|
|
|
|
<p>
|
|
The standard should either answer these questions, or explicitly
|
|
say that the answers are unspecified. I prefer the former option,
|
|
since, as far as I know, all existing implementations behave the
|
|
same way.
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>Add the following to the end of 25.3.5.2 <a href="lib-algorithms.html#lib.set.union"> [lib.set.union]</a> paragraph 5:</p>
|
|
<blockquote>
|
|
If [first1, last1) contains <i>m</i> elements that are equivalent to
|
|
each other and [first2, last2) contains <i>n</i> elements that are
|
|
equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
|
|
will be copied to the output range: all <i>m</i> of these elements
|
|
from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
|
|
[first2, last2), in that order.
|
|
</blockquote>
|
|
|
|
<p>Add the following to the end of 25.3.5.3 <a href="lib-algorithms.html#lib.set.intersection"> [lib.set.intersection]</a> paragraph 5:</p>
|
|
<blockquote>
|
|
If [first1, last1) contains <i>m</i> elements that are equivalent to each
|
|
other and [first2, last2) contains <i>n</i> elements that are
|
|
equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
|
|
elements from [first1, last1) are copied to the output range.
|
|
</blockquote>
|
|
|
|
<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 <a href="lib-algorithms.html#lib.set.difference"> [lib.set.difference]</a>
|
|
paragraph 4:</p>
|
|
<blockquote>
|
|
If [first1, last1) contains <i>m</i> elements that are equivalent to each
|
|
other and [first2, last2) contains <i>n</i> elements that are
|
|
equivalent to them, the last max(<i>m-n</i>, 0) elements from
|
|
[first1, last1) are copied to the output range.
|
|
</blockquote>
|
|
|
|
<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 <a href="lib-algorithms.html#lib.set.symmetric.difference"> [lib.set.symmetric.difference]</a>
|
|
paragraph 4:</p>
|
|
<blockquote>
|
|
If [first1, last1) contains <i>m</i> elements that are equivalent to
|
|
each other and [first2, last2) contains <i>n</i> elements that are
|
|
equivalent to them, then |<i>m - n</i>| of those elements will be
|
|
copied to the output range: the last <i>m - n</i> of these elements
|
|
from [first1, last1) if <i>m</i> > <i>n</i>, and the last <i>n -
|
|
m</i> of these elements from [first2, last2) if <i>m</i> < <i>n</i>.
|
|
</blockquote>
|
|
|
|
<p><i>[Curaçao: Missing Rationale and missing status comments from
|
|
Redmond made discussion difficult. For union, doesn't the standard
|
|
already say this? Howard, others think maybe so. Several thought the
|
|
PR may be "too complicated".]</i></p>
|
|
|
|
<hr>
|
|
<a name="294"><h3>294. User defined macros and standard headers</h3></a><p>
|
|
<b>Section:</b> 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> James Kanze <b>Date:</b> 11 Jan 2001</p>
|
|
<p>Paragraph 2 of 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A
|
|
translation unit that includes a header shall not contain any macros
|
|
that define names declared in that header." As I read this, it
|
|
would mean that the following program is legal:</p>
|
|
|
|
<pre>
|
|
#define npos 3.14
|
|
#include <sstream>
|
|
</pre>
|
|
|
|
<p>since npos is not defined in <sstream>. It is, however, defined
|
|
in <string>, and it is hard to imagine an implementation in
|
|
which <sstream> didn't include <string>.</p>
|
|
|
|
<p>I think that this phrase was probably formulated before it was
|
|
decided that a standard header may freely include other standard
|
|
headers. The phrase would be perfectly appropriate for C, for
|
|
example. In light of 17.4.4.1 <a href="lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
|
|
it isn't stringent enough.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In paragraph 2 of 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, change "A
|
|
translation unit that includes a header shall not contain any macros
|
|
that define names declared in that header." to "A
|
|
translation unit that includes a header shall not contain any macros
|
|
that define names declared in any standard header."</p>
|
|
|
|
<p><i>[Copenhagen: the general idea is clearly correct, but there is
|
|
concern about making sure that the two paragraphs in 17.4.3.1.1 <a href="lib-intro.html#lib.macro.names"> [lib.macro.names]</a> remain consistent. Nathan will provide new
|
|
wording.]</i></p>
|
|
|
|
<hr>
|
|
<a name="299"><h3>299. Incorrect return types for iterator dereference</h3></a><p>
|
|
<b>Section:</b> 24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> John Potter <b>Date:</b> 22 Jan 2001</p>
|
|
<p>
|
|
In section 24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>,
|
|
Table 75 gives the return type of *r-- as convertible to T. This is
|
|
not consistent with Table 74 which gives the return type of *r++ as
|
|
T&. *r++ = t is valid while *r-- = t is invalid.
|
|
</p>
|
|
|
|
<p>
|
|
In section 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>,
|
|
Table 76 gives the return type of a[n] as convertible to T. This is
|
|
not consistent with the semantics of *(a + n) which returns T& by
|
|
Table 74. *(a + n) = t is valid while a[n] = t is invalid.
|
|
</p>
|
|
|
|
<p>
|
|
Discussion from the Copenhagen meeting: the first part is
|
|
uncontroversial. The second part, operator[] for Random Access
|
|
Iterators, requires more thought. There are reasonable arguments on
|
|
both sides. Return by value from operator[] enables some potentially
|
|
useful iterators, e.g. a random access "iota iterator" (a.k.a
|
|
"counting iterator" or "int iterator"). There isn't any obvious way
|
|
to do this with return-by-reference, since the reference would be to a
|
|
temporary. On the other hand, <tt>reverse_iterator</tt> takes an
|
|
arbitrary Random Access Iterator as template argument, and its
|
|
operator[] returns by reference. If we decided that the return type
|
|
in Table 76 was correct, we would have to change
|
|
<tt>reverse_iterator</tt>. This change would probably affect user
|
|
code.
|
|
</p>
|
|
|
|
<p>
|
|
History: the contradiction between <tt>reverse_iterator</tt> and the
|
|
Random Access Iterator requirements has been present from an early
|
|
stage. In both the STL proposal adopted by the committee
|
|
(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
|
|
Stepanov and Lee), the Random Access Iterator requirements say that
|
|
operator[]'s return value is "convertible to T". In N0527
|
|
reverse_iterator's operator[] returns by value, but in HPL-95-11
|
|
(R.1), and in the STL implementation that HP released to the public,
|
|
reverse_iterator's operator[] returns by reference. In 1995, the
|
|
standard was amended to reflect the contents of HPL-95-11 (R.1). The
|
|
original intent for operator[] is unclear.
|
|
</p>
|
|
|
|
<p>
|
|
In the long term it may be desirable to add more fine-grained
|
|
iterator requirements, so that access method and traversal strategy
|
|
can be decoupled. (See "Improved Iterator Categories and
|
|
Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions
|
|
about issue 299 should keep this possibility in mind.
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In section 24.1.4 <a href="lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, change the return type in table
|
|
75 from "convertible to T" to T&.</p>
|
|
|
|
<p>In section 24.1.5 <a href="lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>, change the return type in table
|
|
76 from "convertible to T" to T&.</p>
|
|
|
|
<p><i>[Curaçao: Jeremy volunteered to work on this issue.]</i></p>
|
|
|
|
<hr>
|
|
<a name="300"><h3>300. list::merge() specification incomplete</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#Open">Open</a> <b>Submitter:</b> John Pedretti <b>Date:</b> 23 Jan 2001</p>
|
|
<p>
|
|
The "Effects" clause for list::merge() (23.2.2.4, p23)
|
|
appears to be incomplete: it doesn't cover the case where the argument
|
|
list is identical to *this (i.e., this == &x). The requirement in the
|
|
note in p24 (below) is that x be empty after the merge which is surely
|
|
unintended in this case.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraps 23-25 with:</p>
|
|
<blockquote>
|
|
<p>
|
|
23 Effects: if (&x == this) does nothing; otherwise, merges the two
|
|
sorted ranges [begin(), end()) and [x.begin(), x.end()). The result
|
|
is a range in which the elements will be sorted in non-decreasing
|
|
order according to the ordering defined by comp; that is, for every
|
|
iterator i in the range other than the first, the condition comp(*i,
|
|
*(i - 1)) will be false.
|
|
</p>
|
|
|
|
<p>
|
|
24 Notes: Stable: if (&x != this), then for equivalent elements in the
|
|
two original ranges, the elements from the original range [begin(),
|
|
end()) always precede the elements from the original range [x.begin(),
|
|
x.end()). If (&x != this) the range [x.begin(), x.end()) is empty
|
|
after the merge.
|
|
</p>
|
|
|
|
<p>
|
|
25 Complexity: At most size() + x.size() - 1 applications of comp if
|
|
(&x ! = this); otherwise, no applications of comp are performed. If
|
|
an exception is thrown other than by a comparison there are no
|
|
effects.
|
|
</p>
|
|
|
|
</blockquote>
|
|
|
|
<p><i>[Copenhagen: The original proposed resolution did not fix all of
|
|
the problems in 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25. Three different
|
|
paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
|
|
Changing p23, without changing the other two, appears to introduce
|
|
contradictions. Additionally, "merges the argument list into the
|
|
list" is excessively vague.]</i></p>
|
|
|
|
<p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
|
|
|
|
<hr>
|
|
<a name="304"><h3>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3></a><p>
|
|
<b>Section:</b> 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 5 Feb 2001</p>
|
|
<p>
|
|
We all "know" that input iterators are allowed to produce
|
|
values when dereferenced of which there is no other in-memory copy.
|
|
</p>
|
|
|
|
<p>
|
|
But: Table 72, with a careful reading, seems to imply that this can only be
|
|
the case if the value_type has no members (e.g. is a built-in type).
|
|
</p>
|
|
|
|
<p>The problem occurs in the following entry:</p>
|
|
|
|
<pre>
|
|
a->m pre: (*a).m is well-defined
|
|
Equivalent to (*a).m
|
|
</pre>
|
|
|
|
<p>
|
|
<tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
|
|
type, but since <tt>operator->()</tt> must return a pointer for
|
|
<tt>a->m</tt> to be well-formed, it needs something to return a
|
|
pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
|
|
buffered somewhere to make a legal input iterator.
|
|
</p>
|
|
|
|
<p>I don't think this was intentional.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p><i>[Copenhagen: the two obvious possibilities are to keep the
|
|
<tt>operator-></tt> requirement for Input Iterators, and put
|
|
in a non-normative note describing how it can be implemented with
|
|
proxies, or else moving the <tt>operator-></tt> requirement
|
|
from Input Iterator to Forward Iterator. If we do the former
|
|
we'll also have to change <tt>istreambuf_iterator</tt>, because
|
|
it has no <tt>operator-></tt>. A straw poll showed roughly equal
|
|
support for the two options.]</i></p>
|
|
<hr>
|
|
<a name="305"><h3>305. Default behavior of codecvt<wchar_t, char, mbstate_t>::length()</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#Ready">Ready</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 24 Jan 2001</p>
|
|
<p>22.2.1.5/3 introduces codecvt in part with:</p>
|
|
|
|
<blockquote>
|
|
codecvt<wchar_t,char,mbstate_t> converts between the native
|
|
character sets for tiny and wide characters. Instantiations on
|
|
mbstate_t perform conversion between encodings known to the library
|
|
implementor.
|
|
</blockquote>
|
|
|
|
<p>But 22.2.1.5.2/10 describes do_length in part with:</p>
|
|
|
|
<blockquote>
|
|
... codecvt<wchar_t, char, mbstate_t> ... return(s) the lesser of max and
|
|
(from_end-from).
|
|
</blockquote>
|
|
|
|
<p>
|
|
The semantics of do_in and do_length are linked. What one does must
|
|
be consistent with what the other does. 22.2.1.5/3 leads me to
|
|
believe that the vendor is allowed to choose the algorithm that
|
|
codecvt<wchar_t,char,mbstate_t>::do_in performs so that it makes
|
|
his customers happy on a given platform. But 22.2.1.5.2/10 explicitly
|
|
says what codecvt<wchar_t,char,mbstate_t>::do_length must
|
|
return. And thus indirectly specifies the algorithm that
|
|
codecvt<wchar_t,char,mbstate_t>::do_in must perform. I believe
|
|
that this is not what was intended and is a defect.
|
|
</p>
|
|
|
|
<p>Discussion from the -lib reflector:
|
|
|
|
<br>This proposal would have the effect of making the semantics of
|
|
all of the virtual functions in <tt>codecvt<wchar_t, char,
|
|
mbstate_t></tt> implementation specified. Is that what we want, or
|
|
do we want to mandate specific behavior for the base class virtuals
|
|
and leave the implementation specified behavior for the codecvt_byname
|
|
derived class? The tradeoff is that former allows implementors to
|
|
write a base class that actually does something useful, while the
|
|
latter gives users a way to get known and specified---albeit
|
|
useless---behavior, and is consistent with the way the standard
|
|
handles other facets. It is not clear what the original intention
|
|
was.</p>
|
|
|
|
<p>
|
|
Nathan has suggest a compromise: a character that is a widened version
|
|
of the characters in the basic execution character set must be
|
|
converted to a one-byte sequence, but there is no such requirement
|
|
for characters that are not part of the basic execution character set.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change 22.2.1.5.2/5 from:
|
|
</p>
|
|
<p>
|
|
The instantiations required in Table 51 (lib.locale.category), namely
|
|
codecvt<wchar_t,char,mbstate_t> and
|
|
codecvt<char,char,mbstate_t>, store no characters. Stores no more
|
|
than (to_limit-to) destination elements. It always leaves the to_next
|
|
pointer pointing one beyond the last element successfully stored.
|
|
</p>
|
|
<p>
|
|
to:
|
|
</p>
|
|
<p>
|
|
Stores no more than (to_limit-to) destination elements, and leaves the
|
|
to_next pointer pointing one beyond the last element successfully
|
|
stored. codecvt<char,char,mbstate_t> stores no characters.
|
|
</p>
|
|
|
|
<p>Change 22.2.1.5.2/10 from:</p>
|
|
|
|
<blockquote>
|
|
-10- Returns: (from_next-from) where from_next is the largest value in
|
|
the range [from,from_end] such that the sequence of values in the
|
|
range [from,from_next) represents max or fewer valid complete
|
|
characters of type internT. The instantiations required in Table 51
|
|
(21.1.1.1.1), namely codecvt<wchar_t, char, mbstate_t> and
|
|
codecvt<char, char, mbstate_t>, return the lesser of max and
|
|
(from_end-from).
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
-10- Returns: (from_next-from) where from_next is the largest value in
|
|
the range [from,from_end] such that the sequence of values in the range
|
|
[from,from_next) represents max or fewer valid complete characters of
|
|
type internT. The instantiation codecvt<char, char, mbstate_t> returns
|
|
the lesser of max and (from_end-from).
|
|
</blockquote>
|
|
|
|
<p><i>[Redmond: Nathan suggested an alternative resolution: same as
|
|
above, but require that, in the default encoding, a character from the
|
|
basic execution character set would map to a single external
|
|
character. The straw poll was 8-1 in favor of the proposed
|
|
resolution.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>The default encoding should be whatever users of a given platform
|
|
would expect to be the most natural. This varies from platform to
|
|
platform. In many cases there is a preexisting C library, and users
|
|
would expect the default encoding to be whatever C uses in the default
|
|
"C" locale. We could impose a guarantee like the one Nathan suggested
|
|
(a character from the basic execution character set must map to a
|
|
single external character), but this would rule out important
|
|
encodings that are in common use: it would rule out JIS, for
|
|
example, and it would rule out a fixed-width encoding of UCS-4.</p>
|
|
|
|
<p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
|
|
"shift-JIS" changed to "JIS".]</i></p>
|
|
|
|
<hr>
|
|
<a name="309"><h3>309. Does sentry catch exceptions?</h3></a><p>
|
|
<b>Section:</b> 27.6 <a href="lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 19 Mar 2001</p>
|
|
<p>
|
|
The descriptions of the constructors of basic_istream<>::sentry
|
|
(27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>) and basic_ostream<>::sentry
|
|
(27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>) do not explain what the functions do in
|
|
case an exception is thrown while they execute. Some current
|
|
implementations allow all exceptions to propagate, others catch them
|
|
and set ios_base::badbit instead, still others catch some but let
|
|
others propagate.
|
|
</p>
|
|
|
|
<p>
|
|
The text also mentions that the functions may call setstate(failbit)
|
|
(without actually saying on what object, but presumably the stream
|
|
argument is meant). That may have been fine for
|
|
basic_istream<>::sentry prior to issue <a href="lwg-defects.html#195">195</a>, since
|
|
the function performs an input operation which may fail. However,
|
|
issue <a href="lwg-defects.html#195">195</a> amends 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p2 to
|
|
clarify that the function should actually call setstate(failbit |
|
|
eofbit), so the sentence in p3 is redundant or even somewhat
|
|
contradictory.
|
|
</p>
|
|
|
|
<p>
|
|
The same sentence that appears in 27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3
|
|
doesn't seem to be very meaningful for basic_istream<>::sentry
|
|
which performs no input. It is actually rather misleading since it
|
|
would appear to guide library implementers to calling
|
|
setstate(failbit) when os.tie()->flush(), the only called function,
|
|
throws an exception (typically, it's badbit that's set in response to
|
|
such an event).
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add the following paragraph immediately after
|
|
27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p5</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
If an exception is thrown during the preparation then ios::badbit
|
|
is turned on* in is's error state.
|
|
</p>
|
|
|
|
<p>
|
|
[Footnote: This is done without causing an ios::failure to be thrown.
|
|
--- end footnote]
|
|
</p>
|
|
|
|
<p>
|
|
If (is.exceptions() & ios_base::badbit)!= 0 then the exception is
|
|
rethrown.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>And strike the following sentence from 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>, p5</p>
|
|
|
|
<blockquote>
|
|
During preparation, the constructor may call setstate(failbit)
|
|
(which may throw ios_base::failure (lib.iostate.flags))
|
|
</blockquote>
|
|
|
|
<p>Add the following paragraph immediately after
|
|
27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
If an exception is thrown during the preparation then ios::badbit
|
|
is turned on* in os's error state.
|
|
</p>
|
|
|
|
<p>
|
|
[Footnote: This is done without causing an ios::failure to be
|
|
thrown. --- end footnote]
|
|
</p>
|
|
|
|
<p>
|
|
If (os.exceptions() & ios_base::badbit)!= 0 then the exception
|
|
is rethrown.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>And strike the following sentence from 27.6.2.3 <a href="lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>, p3</p>
|
|
|
|
<blockquote>
|
|
During preparation, the constructor may call setstate(failbit)
|
|
(which may throw ios_base::failure (lib.iostate.flags))
|
|
</blockquote>
|
|
|
|
<p>(Note that the removal of the two sentences means that the ctors
|
|
will not be able to report the failure of any implementation-dependent
|
|
operations referred to in footnotes 280 and 293, unless such
|
|
operations throw an exception.)</p>
|
|
|
|
<p><i>[
|
|
Copenhagen: It was agreed that there was an issue here, but there was
|
|
disagreement about the resolution. Some LWG members argued that a
|
|
sentry's constructor should not catch exceptions, because sentries
|
|
should only be used within (un)formatted input functions and that
|
|
exception handling is the responsibility of those functions, not of
|
|
the sentries.
|
|
]</i></p>
|
|
|
|
<hr>
|
|
<a name="320"><h3>320. list::assign overspecified</h3></a><p>
|
|
<b>Section:</b> 23.2.2.1 <a href="lib-containers.html#lib.list.cons"> [lib.list.cons]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 17 May 2001</p>
|
|
<p>
|
|
Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
|
|
the "effects" of a call to erase followed by a call to insert.
|
|
</p>
|
|
|
|
<p>
|
|
I would like to document that implementers have the freedom to implement
|
|
assign by other methods, as long as the end result is the same and the
|
|
exception guarantee is as good or better than the basic guarantee.
|
|
</p>
|
|
|
|
<p>
|
|
The motivation for this is to use T's assignment operator to recycle
|
|
existing nodes in the list instead of erasing them and reallocating
|
|
them with new values. It is also worth noting that, with careful
|
|
coding, most common cases of assign (everything but assignment with
|
|
true input iterators) can elevate the exception safety to strong if
|
|
T's assignment has a nothrow guarantee (with no extra memory cost).
|
|
Metrowerks does this. However I do not propose that this subtlety be
|
|
standardized. It is a QoI issue. </p>
|
|
|
|
<p>Existing practise:
|
|
Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change 23.2.2.1/7 from:</p>
|
|
|
|
<blockquote>
|
|
<p>Effects:</p>
|
|
|
|
<pre>
|
|
erase(begin(), end());
|
|
insert(begin(), first, last);
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
<p>Effects: Replaces the contents of the list with the range [first, last).</p>
|
|
</blockquote>
|
|
|
|
<p>In 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, in Table 67 (sequence requirements),
|
|
add two new rows:</p>
|
|
<pre>
|
|
a.assign(i,j) void pre: i,j are not iterators into a.
|
|
Replaces elements in a with a copy
|
|
of [i, j).
|
|
|
|
a.assign(n,t) void pre: t is not a reference into a.
|
|
Replaces elements in a with n copies
|
|
of t.
|
|
</pre>
|
|
|
|
<p>Change 23.2.2.1/8 from:</p>
|
|
|
|
<blockquote>
|
|
<p>Effects:</p>
|
|
<pre>
|
|
erase(begin(), end());
|
|
insert(begin(), n, t);
|
|
</pre>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
|
|
<blockquote>
|
|
<p>Effects: Replaces the contents of the list with n copies of t.</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Redmond: Proposed resolution was changed slightly. Previous
|
|
version made explicit statement about exception safety, which wasn't
|
|
consistent with the way exception safety is expressed elsewhere.
|
|
Also, the change in the sequence requirements is new. Without that
|
|
change, the proposed resolution would have required that assignment of
|
|
a subrange would have to work. That too would have been
|
|
overspecification; it would effectively mandate that assignment use a
|
|
temporary. Howard provided wording.
|
|
]</i></p>
|
|
|
|
<p><i>[Curaçao: Made editorial improvement in wording; changed
|
|
"Replaces elements in a with copies of elements in [i, j)."
|
|
with "Replaces the elements of a with a copy of [i, j)."
|
|
Changes not deemed serious enough to requre rereview.]</i></p>
|
|
|
|
<hr>
|
|
<a name="323"><h3>323. abs() overloads in different headers</h3></a><p>
|
|
<b>Section:</b> 26.5 <a href="lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 4 June 2001</p>
|
|
<p>Currently the standard mandates the following overloads of
|
|
abs():</p>
|
|
|
|
<pre>
|
|
abs(long), abs(int) in <cstdlib>
|
|
|
|
abs(float), abs(double), abs(long double) in <cmath>
|
|
|
|
template<class T> T abs(const complex<T>&) in <complex>
|
|
|
|
template<class T> valarray<T> abs(const valarray<T>&); in <valarray>
|
|
</pre>
|
|
|
|
<p>
|
|
The problem is that having only some overloads visible of a function
|
|
that works on "implicitly inter-convertible" types is dangerous in
|
|
practice. The headers that get included at any point in a translation
|
|
unit can change unpredictably during program
|
|
development/maintenance. The wrong overload might be unintentionally
|
|
selected.
|
|
</p>
|
|
|
|
<p>
|
|
Currently, there is nothing that mandates the simultaneous visibility
|
|
of these overloads. Indeed, some vendors have begun fastidiously
|
|
reducing dependencies among their (public) headers as a QOI issue: it
|
|
helps people to write portable code by refusing to compile unless all
|
|
the correct headers are #included.
|
|
</p>
|
|
|
|
<p>The same issue may exist for other functions in the library.</p>
|
|
|
|
<p>Redmond: PJP reports that C99 adds two new kinds of abs: comples,
|
|
and int_max_abs.</p>
|
|
|
|
<p>Related issue: <a href="lwg-closed.html#343">343</a>.</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p><i>[Redmond: General agreement that the current situation is
|
|
somewhat fragile. No consensus on whether it's more fragile than any
|
|
number of other things, or whether there's any good way to fix it.
|
|
Walter suggests that <tt>abs</tt> should be defined for all built-in
|
|
types in both <cmath> and <cstdlib>, but that no effort
|
|
should be made to put all overloads for class types in one place.
|
|
Beman suggests closing this issue as "NAD Future", and adding a
|
|
<all> header as an extension. The <all> header would
|
|
solve a more general problem: users who can't remember which names are
|
|
defined in which headers. (See issue <a href="lwg-closed.html#343">343</a>)]</i></p>
|
|
|
|
<hr>
|
|
<a name="324"><h3>324. Do output iterators have value types?</h3></a><p>
|
|
<b>Section:</b> 24.1.2 <a href="lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 7 June 2001</p>
|
|
|
|
<p>Table 73 suggests that output iterators have value types. It
|
|
requires the expression "*a = t". Additionally, although Table 73
|
|
never lists "a = t" or "X(a) = t" in the "expressions" column, it
|
|
contains a note saying that "a = t" and "X(a) = t" have equivalent
|
|
(but nowhere specified!) semantics.</p>
|
|
|
|
<p>According to 24.1/9, t is supposed to be "a value of value type
|
|
T":</p>
|
|
|
|
<blockquote>
|
|
In the following sections, a and b denote values of X, n denotes a
|
|
value of the difference type Distance, u, tmp, and m denote
|
|
identifiers, r denotes a value of X&, t denotes a value of
|
|
value type T.
|
|
</blockquote>
|
|
|
|
<p>Two other parts of the standard that are relevant to whether
|
|
output iterators have value types:</p>
|
|
|
|
<ul>
|
|
<li>24.1/1 says "All iterators i support the expression *i,
|
|
resulting in a value of some class, enumeration, or built-in type
|
|
T, called the value type of the iterator".</li>
|
|
|
|
<li>
|
|
24.3.1/1, which says "In the case of an output iterator, the types
|
|
iterator_traits<Iterator>::difference_type
|
|
iterator_traits<Iterator>::value_type are both defined as void."
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The first of these passages suggests that "*i" is supposed to
|
|
return a useful value, which contradicts the note in 24.1.2/2 saying
|
|
that the only valid use of "*i" for output iterators is in an
|
|
expression of the form "*i = t". The second of these passages appears
|
|
to contradict Table 73, because it suggests that "*i"'s return value
|
|
should be void. The second passage is also broken in the case of a an
|
|
iterator type, like non-const pointers, that satisfies both the output
|
|
iterator requirements and the forward iterator requirements.</p>
|
|
|
|
<p>What should the standard say about <tt>*i</tt>'s return value when
|
|
i is an output iterator, and what should it say about that t is in the
|
|
expression "*i = t"? Finally, should the standard say anything about
|
|
output iterators' pointer and reference types?</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>24.1 p1, change</p>
|
|
|
|
<blockquote>
|
|
<p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
|
|
in a value of some class, enumeration, or built-in type <tt>T</tt>,
|
|
called the value type of the iterator.</p>
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
<p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
|
|
resulting in a value of some class, enumeration, or built-in type
|
|
<tt>T</tt>, called the value type of the iterator. All output
|
|
iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
|
|
value of some type that is in the set of types that are <i>writable</i> to
|
|
the particular iterator type of <tt>i</tt>.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>24.1 p9, add</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
<tt>o</tt> denotes a value of some type that is writable to the
|
|
output iterator.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>Table 73, change</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
*a = t
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
*r = o
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>and change</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
*r++ = t
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
*r++ = o
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p><i>[post-Redmond: Jeremy provided wording]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>The LWG considered two options: change all of the language that
|
|
seems to imply that output iterators have value types, thus making it
|
|
clear that output iterators have no value types, or else define value
|
|
types for output iterator consistently. The LWG chose the former
|
|
option, because it seems clear that output iterators were never
|
|
intended to have value types. This was a deliberate design decision,
|
|
and any language suggesting otherwise is simply a mistake.</p>
|
|
|
|
<p>A future revision of the standard may wish to revisit this design
|
|
decision.</p>
|
|
<hr>
|
|
<a name="325"><h3>325. Misleading text in moneypunct<>::do_grouping</h3></a><p>
|
|
<b>Section:</b> 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Jul 2001</p>
|
|
<p>The Returns clause in 22.2.6.3.2, p3 says about
|
|
moneypunct<charT>::do_grouping()
|
|
</p>
|
|
|
|
<blockquote>
|
|
Returns: A pattern defined identically as the result of
|
|
numpunct<charT>::do_grouping().241)
|
|
</blockquote>
|
|
|
|
<p>Footnote 241 then reads</p>
|
|
|
|
<blockquote>
|
|
This is most commonly the value "\003" (not "3").
|
|
</blockquote>
|
|
|
|
<p>
|
|
The returns clause seems to imply that the two member functions must
|
|
return an identical value which in reality may or may not be true,
|
|
since the facets are usually implemented in terms of struct std::lconv
|
|
and return the value of the grouping and mon_grouping, respectively.
|
|
The footnote also implies that the member function of the moneypunct
|
|
facet (rather than the overridden virtual functions in moneypunct_byname)
|
|
most commonly return "\003", which contradicts the C standard which
|
|
specifies the value of "" for the (most common) C locale.
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
|
|
|
|
<blockquote>
|
|
Returns: A pattern defined identically as, but not necessarily
|
|
equal to, the result of numpunct<charT>::do_grouping().241)
|
|
</blockquote>
|
|
|
|
<p>and replace the text in Footnote 241 with the following:</p>
|
|
|
|
<blockquote>
|
|
To specify grouping by 3s the value is "\003", not "3".
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
The fundamental problem is that the description of the locale facet
|
|
virtuals serves two purposes: describing the behavior of the base
|
|
class, and describing the meaning of and constraints on the behavior
|
|
in arbitrary derived classes. The new wording makes that separation a
|
|
little bit clearer. The footnote (which is nonnormative) is not
|
|
supposed to say what the grouping is in the "C" locale or in any other
|
|
locale. It is just a reminder that the values are interpreted as small
|
|
integers, not ASCII characters.
|
|
</p>
|
|
<hr>
|
|
<a name="329"><h3>329. vector capacity, reserve and reallocation</h3></a><p>
|
|
<b>Section:</b> 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>, 23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 13 Jul 2001</p>
|
|
<p>
|
|
There is an apparent contradiction about which circumstances can cause
|
|
a reallocation of a vector in Section 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> and
|
|
section 23.2.4.3 <a href="lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>.
|
|
</p>
|
|
|
|
<p>23.2.4.2p5 says:</p>
|
|
<blockquote>
|
|
Notes: Reallocation invalidates all the references, pointers, and iterators
|
|
referring to the elements in the sequence. It is guaranteed that no
|
|
reallocation takes place during insertions that happen after a call to
|
|
reserve() until the time when an insertion would make the size of the vector
|
|
greater than the size specified in the most recent call to reserve().
|
|
</blockquote>
|
|
|
|
<p>Which implies if I do</p>
|
|
|
|
<pre>
|
|
std::vector<int> vec;
|
|
vec.reserve(23);
|
|
vec.reserve(0);
|
|
vec.insert(vec.end(),1);
|
|
</pre>
|
|
|
|
<p>then the implementation may reallocate the vector for the insert,
|
|
as the size specified in the previous call to reserve was zero.</p>
|
|
|
|
<p>However, the previous paragraphs (23.2.4.2, p1-2) state:</p>
|
|
<blockquote>
|
|
<p>
|
|
(capacity) Returns: The total number of elements the vector
|
|
can hold without requiring reallocation
|
|
</p>
|
|
<p>
|
|
...After reserve(), capacity() is greater or equal to the
|
|
argument of reserve if reallocation happens; and equal to the previous value
|
|
of capacity() otherwise...
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>
|
|
This implies that vec.capacity() is still 23, and so the insert()
|
|
should not require a reallocation, as vec.size() is 0. This is backed
|
|
up by 23.2.4.3p1:
|
|
</p>
|
|
<blockquote>
|
|
(insert) Notes: Causes reallocation if the new size is greater than the old
|
|
capacity.
|
|
</blockquote>
|
|
|
|
<p>
|
|
Though this doesn't rule out reallocation if the new size is less
|
|
than the old capacity, I think the intent is clear.
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the wording of 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5 to:</p>
|
|
|
|
<blockquote>
|
|
Notes: Reallocation invalidates all the references, pointers, and
|
|
iterators referring to the elements in the sequence. It is guaranteed
|
|
that no reallocation takes place during insertions that happen after a
|
|
call to reserve() until the time when an insertion would make the size
|
|
of the vector greater than the value of capacity().
|
|
</blockquote>
|
|
|
|
<p><i>[Redmond: original proposed resolution was modified slightly. In
|
|
the original, the guarantee was that there would be no reallocation
|
|
until the size would be greater than the value of capacity() after the
|
|
most recent call to reserve(). The LWG did not believe that the
|
|
"after the most recent call to reserve()" added any useful
|
|
information.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>There was general agreement that, when reserve() is called twice in
|
|
succession and the argument to the second invocation is smaller than
|
|
the argument to the first, the intent was for the second invocation to
|
|
have no effect. Wording implying that such cases have an effect on
|
|
reallocation guarantees was inadvertant.</p>
|
|
<hr>
|
|
<a name="333"><h3>333. does endl imply synchronization with the device?</h3></a><p>
|
|
<b>Section:</b> 27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 27 Aug 2001</p>
|
|
<p>A footnote in 27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> states:</p>
|
|
<blockquote>
|
|
[Footnote: The effect of executing cout << endl is to insert a
|
|
newline character in the output sequence controlled by cout, then
|
|
synchronize it with any external file with which it might be
|
|
associated. --- end foonote]
|
|
</blockquote>
|
|
|
|
<p>
|
|
Does the term "file" here refer to the external device?
|
|
This leads to some implementation ambiguity on systems with fully
|
|
buffered files where a newline does not cause a flush to the device.
|
|
</p>
|
|
|
|
<p>
|
|
Choosing to sync with the device leads to significant performance
|
|
penalties for each call to endl, while not sync-ing leads to
|
|
errors under special circumstances.
|
|
</p>
|
|
|
|
<p>
|
|
I could not find any other statement that explicitly defined
|
|
the behavior one way or the other.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Remove footnote 300 from section 27.6.2.7 <a href="lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>.</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>We already have normative text saying what <tt>endl</tt> does: it
|
|
inserts a newline character and calls <tt>flush</tt>. This footnote
|
|
is at best redundant, at worst (as this issue says) misleading,
|
|
because it appears to make promises about what <tt>flush</tt>
|
|
does.</p>
|
|
<hr>
|
|
<a name="334"><h3>334. map::operator[] specification forces inefficient implementation</h3></a><p>
|
|
<b>Section:</b> 23.3.1.2 <a href="lib-containers.html#lib.map.access"> [lib.map.access]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Andrea Griffini <b>Date:</b> 02 Sep 2001</p>
|
|
<p>
|
|
The current standard describes map::operator[] using a
|
|
code example. That code example is however quite
|
|
inefficient because it requires several useless copies
|
|
of both the passed key_type value and of default
|
|
constructed mapped_type instances.
|
|
My opinion is that was not meant by the comitee to
|
|
require all those temporary copies.
|
|
</p>
|
|
|
|
<p>Currently map::operator[] behaviour is specified as: </p>
|
|
<pre>
|
|
Returns:
|
|
(*((insert(make_pair(x, T()))).first)).second.
|
|
</pre>
|
|
|
|
<p>
|
|
This specification however uses make_pair that is a
|
|
template function of which parameters in this case
|
|
will be deduced being of type const key_type& and
|
|
const T&. This will create a pair<key_type,T> that
|
|
isn't the correct type expected by map::insert so
|
|
another copy will be required using the template
|
|
conversion constructor available in pair to build
|
|
the required pair<const key_type,T> instance.
|
|
</p>
|
|
|
|
<p>If we consider calling of key_type copy constructor
|
|
and mapped_type default constructor and copy
|
|
constructor as observable behaviour (as I think we
|
|
should) then the standard is in this place requiring
|
|
two copies of a key_type element plus a default
|
|
construction and two copy construction of a mapped_type
|
|
(supposing the addressed element is already present
|
|
in the map; otherwise at least another copy
|
|
construction for each type).
|
|
</p>
|
|
|
|
<p>A simple (half) solution would be replacing the description with:</p>
|
|
<pre>
|
|
Returns:
|
|
(*((insert(value_type(x, T()))).first)).second.
|
|
</pre>
|
|
|
|
<p>This will remove the wrong typed pair construction that
|
|
requires one extra copy of both key and value.</p>
|
|
|
|
<p>However still the using of map::insert requires temporary
|
|
objects while the operation, from a logical point of view,
|
|
doesn't require any. </p>
|
|
|
|
<p>I think that a better solution would be leaving free an
|
|
implementer to use a different approach than map::insert
|
|
that, because of its interface, forces default constructed
|
|
temporaries and copies in this case.
|
|
The best solution in my opinion would be just requiring
|
|
map::operator[] to return a reference to the mapped_type
|
|
part of the contained element creating a default element
|
|
with the specified key if no such an element is already
|
|
present in the container. Also a logarithmic complexity
|
|
requirement should be specified for the operation.
|
|
</p>
|
|
|
|
<p>
|
|
This would allow library implementers to write alternative
|
|
implementations not using map::insert and reaching optimal
|
|
performance in both cases of the addressed element being
|
|
present or absent from the map (no temporaries at all and
|
|
just the creation of a new pair inside the container if
|
|
the element isn't present).
|
|
Some implementer has already taken this option but I think
|
|
that the current wording of the standard rules that as
|
|
non-conforming.
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>
|
|
Replace 23.3.1.2 <a href="lib-containers.html#lib.map.access"> [lib.map.access]</a> paragraph 1 with
|
|
</p>
|
|
<blockquote>
|
|
<p>
|
|
-1- Effects: If there is no key equivalent to x in the map, inserts
|
|
value_type(x, T()) into the map.
|
|
</p>
|
|
<p>
|
|
-2- Returns: A reference to the mapped_type corresponding to x in *this.
|
|
</p>
|
|
<p>
|
|
-3- Complexity: logarithmic.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[This is the second option mentioned above. Howard provided
|
|
wording. We may also wish to have a blanket statement somewhere in
|
|
clause 17 saying that we do not intend the semantics of sample code
|
|
fragments to be interpreted as specifing exactly how many copies are
|
|
made. See issue <a href="lwg-active.html#98">98</a> for a similar problem.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
This is the second solution described above; as noted, it is
|
|
consistent with existing practice.
|
|
</p>
|
|
|
|
<p>Note that we now need to specify the complexity explicitly, because
|
|
we are no longer defining <tt>operator[]</tt> in terms of
|
|
<tt>insert</tt>.</p>
|
|
<hr>
|
|
<a name="336"><h3>336. Clause 17 lack of references to deprecated headers</h3></a><p>
|
|
<b>Section:</b> 17 <a href="lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 05 Sep 2001</p>
|
|
<p>From c++std-edit-873:</p>
|
|
|
|
<p>17.4.1.2 <a href="lib-intro.html#lib.headers"> [lib.headers]</a>, Table 11. In this table, the header
|
|
<strstream> is missing.</p>
|
|
|
|
<p>This shows a general problem: The whole clause 17 refers quite
|
|
often to clauses 18 through 27, but D.7 is also a part of the standard
|
|
library (though a deprecated one).</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p><i>[Redmond: The LWG agrees that <strstream> should be added
|
|
to table 11. A review is needed to determine whether there are any
|
|
other places in clause 17 where clause D material should be referred
|
|
to. Beman will review clause 17.]</i></p>
|
|
|
|
<p><i>[Curaçao: Beman emailed wording to Matt, but not in time for the
|
|
pre-meeting mailing.]</i></p>
|
|
|
|
<hr>
|
|
<a name="338"><h3>338. is whitespace allowed between `-' and a digit?</h3></a><p>
|
|
<b>Section:</b> 22.2 <a href="lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 17 Sep 2001</p>
|
|
<p>
|
|
From Stage 2 processing in 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the
|
|
original text or the text corrected by the proposed resolution of
|
|
issue <a href="lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
|
|
within a number, but 22.2.3.1 <a href="lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a>, p2, which gives the
|
|
format for integer and floating point values, says that whitespace is
|
|
optional between a plusminus and a sign.
|
|
</p>
|
|
|
|
<p>
|
|
The text needs to be clarified to either consistently allow or
|
|
disallow whitespace between a plusminus and a sign. It might be
|
|
worthwhile to consider the fact that the C library stdio facility does
|
|
not permit whitespace embedded in numbers and neither does the C or
|
|
C++ core language (the syntax of integer-literals is given in 2.13.1 <a href="lex.html#lex.icon"> [lex.icon]</a>, that of floating-point-literals in 2.13.3 <a href="lex.html#lex.fcon"> [lex.fcon]</a> of the C++ standard).
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the first part of 22.2.3.1 <a href="lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 from:</p>
|
|
<blockquote>
|
|
<p>
|
|
The syntax for number formats is as follows, where <tt>digit</tt>
|
|
represents the radix set specified by the <tt>fmtflags</tt> argument
|
|
value, <tt>whitespace</tt> is as determined by the facet
|
|
<tt>ctype<charT></tt> (22.2.1.1), and <tt>thousands-sep</tt> and
|
|
<tt>decimal-point</tt> are the results of corresponding
|
|
<tt>numpunct<charT></tt> members. Integer values have the
|
|
format:
|
|
</p>
|
|
<pre>
|
|
integer ::= [sign] units
|
|
sign ::= plusminus [whitespace]
|
|
plusminus ::= '+' | '-'
|
|
units ::= digits [thousands-sep units]
|
|
digits ::= digit [digits]
|
|
</pre>
|
|
</blockquote>
|
|
<p>to:</p>
|
|
<blockquote>
|
|
<p>
|
|
The syntax for number formats is as follows, where <tt>digit</tt>
|
|
represents the radix set specified by the <tt>fmtflags</tt> argument
|
|
value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
|
|
results of corresponding <tt>numpunct<charT></tt> members.
|
|
Integer values have the format:
|
|
</p>
|
|
<pre>
|
|
integer ::= [sign] units
|
|
sign ::= plusminus
|
|
plusminus ::= '+' | '-'
|
|
units ::= digits [thousands-sep units]
|
|
digits ::= digit [digits]
|
|
</pre>
|
|
</blockquote>
|
|
<p><b>Rationale:</b></p>
|
|
<p>It's not clear whether the format described in 22.2.3.1 <a href="lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 has any normative weight: nothing in the
|
|
standard says how, or whether, it's used. However, there's no reason
|
|
for it to differ gratuitously from the very specific description of
|
|
numeric processing in 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>. The proposed
|
|
resolution removes all mention of "whitespace" from that format.</p>
|
|
<hr>
|
|
<a name="339"><h3>339. definition of bitmask type restricted to clause 27</h3></a><p>
|
|
<b>Section:</b> 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 17 September 2001</p>
|
|
<p>
|
|
The ctype_category::mask type is declared to be an enum in 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> with p1 then stating that it is a bitmask type, most
|
|
likely referring to the definition of bitmask type in 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>, p1. However, the said definition only applies to
|
|
clause 27, making the reference in 22.2.1 somewhat dubious.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
|
|
<blockquote>
|
|
Several types defined in clause 27 are bitmask types. Each bitmask type
|
|
can be implemented as an enumerated type that overloads certain operators,
|
|
as an integer type, or as a bitset (23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>).
|
|
</blockquote>
|
|
<p>to read</p>
|
|
<blockquote>
|
|
Several types defined in clauses lib.language.support through
|
|
lib.input.output and Annex D are bitmask types. Each bitmask type can
|
|
be implemented as an enumerated type that overloads certain operators,
|
|
as an integer type, or as a bitset (lib.template.bitset).
|
|
</blockquote>
|
|
|
|
<p>
|
|
Additionally, change the definition in 22.2.1 to adopt the same
|
|
convention as in clause 27 by replacing the existing text with the
|
|
following (note, in particluar, the cross-reference to 17.3.2.1.2 in
|
|
22.2.1, p1):
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>22.2.1 The ctype category [lib.category.ctype]</p>
|
|
<pre>
|
|
namespace std {
|
|
class ctype_base {
|
|
public:
|
|
typedef <b><i>T</i></b> mask;
|
|
|
|
// numeric values are for exposition only.
|
|
static const mask space = 1 << 0;
|
|
static const mask print = 1 << 1;
|
|
static const mask cntrl = 1 << 2;
|
|
static const mask upper = 1 << 3;
|
|
static const mask lower = 1 << 4;
|
|
static const mask alpha = 1 << 5;
|
|
static const mask digit = 1 << 6;
|
|
static const mask punct = 1 << 7;
|
|
static const mask xdigit = 1 << 8;
|
|
static const mask alnum = alpha | digit;
|
|
static const mask graph = alnum | punct;
|
|
};
|
|
}
|
|
</pre>
|
|
|
|
<p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>).</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
|
|
consistent with the rest of the standard.]</i></p>
|
|
|
|
<hr>
|
|
<a name="340"><h3>340. interpretation of <tt>has_facet<Facet>(loc)</tt>
|
|
</h3></a><p>
|
|
<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2001</p>
|
|
<p>
|
|
It's unclear whether 22.1.1.1.1, p3 says that
|
|
<tt>has_facet<Facet>(loc)</tt> returns true for any <tt>Facet</tt>
|
|
from Table 51 or whether it includes Table 52 as well:
|
|
</p>
|
|
|
|
<blockquote>
|
|
For any locale <tt>loc</tt> either constructed, or returned by
|
|
locale::classic(), and any facet <tt>Facet</tt> that is a member of a
|
|
standard category, <tt>has_facet<Facet>(loc)</tt> is true. Each
|
|
locale member function which takes a <tt>locale::category</tt>
|
|
argument operates on the corresponding set of facets.
|
|
</blockquote>
|
|
|
|
<p>
|
|
It seems that it comes down to which facets are considered to be members of a
|
|
standard category. Intuitively, I would classify all the facets in Table 52 as
|
|
members of their respective standard categories, but there are an unbounded set
|
|
of them...
|
|
</p>
|
|
|
|
<p>
|
|
The paragraph implies that, for instance, <tt>has_facet<num_put<C,
|
|
OutputIterator> >(loc)</tt> must always return true. I don't think that's
|
|
possible. If it were, then <tt>use_facet<num_put<C, OutputIterator>
|
|
>(loc)</tt> would have to return a reference to a distinct object for each
|
|
valid specialization of <tt>num_put<C, OutputIteratory></tt>, which is
|
|
clearly impossible.
|
|
</p>
|
|
|
|
<p>
|
|
On the other hand, if none of the facets in Table 52 is a member of a standard
|
|
category then none of the locale member functions that operate on entire
|
|
categories of facets will work properly.
|
|
</p>
|
|
|
|
<p>
|
|
It seems that what p3 should mention that it's required (permitted?)
|
|
to hold only for specializations of <tt>Facet</tt> from Table 52 on
|
|
<tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
|
|
<tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
|
|
{
|
|
{i,o}<tt>streambuf_iterator</tt><{<tt>char</tt>,<tt>wchar_t</tt>}<tt>></tt>
|
|
}.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 3, change
|
|
"that is a member of a standard category" to "shown in Table 51".</p>
|
|
<p><b>Rationale:</b></p>
|
|
<p>The facets in Table 52 are an unbounded set. Locales should not be
|
|
required to contain an infinite number of facets.</p>
|
|
|
|
<p>It's not necessary to talk about which values of InputIterator and
|
|
OutputIterator must be supported. Table 51 already contains a
|
|
complete list of the ones we need.</p>
|
|
<hr>
|
|
<a name="341"><h3>341. Vector reallocation and swap</h3></a><p>
|
|
<b>Section:</b> 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 27 Sep 2001</p>
|
|
<p>It is a common idiom to reduce the capacity of a vector by swapping it with
|
|
an empty one:</p>
|
|
<pre>
|
|
std::vector<SomeType> vec;
|
|
// fill vec with data
|
|
std::vector<SomeType>().swap(vec);
|
|
// vec is now empty, with minimal capacity
|
|
</pre>
|
|
|
|
<p>However, the wording of 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>paragraph 5 prevents
|
|
the capacity of a vector being reduced, following a call to
|
|
reserve(). This invalidates the idiom, as swap() is thus prevented
|
|
from reducing the capacity. The proposed wording for issue <a href="lwg-active.html#329">329</a> does not affect this. Consequently, the example above
|
|
requires the temporary to be expanded to cater for the contents of
|
|
vec, and the contents be copied across. This is a linear-time
|
|
operation.</p>
|
|
|
|
<p>However, the container requirements state that swap must have constant
|
|
complexity (23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> note to table 65).</p>
|
|
|
|
<p>This is an important issue, as reallocation affects the validity of
|
|
references and iterators.</p>
|
|
|
|
<p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
|
|
references and iterators remain valid after a call to swap, if they refer to
|
|
an element before the new end() of the vector into which they originally
|
|
pointed, in which case they refer to the element at the same index position.
|
|
Iterators and references that referred to an element whose index position
|
|
was beyond the new end of the vector are invalidated.</p>
|
|
|
|
<p>If the note to table 65 is taken as the desired intent, then there are two
|
|
possibilities with regard to iterators and references:</p>
|
|
|
|
<ol>
|
|
<li>All Iterators and references into both vectors are invalidated.</li>
|
|
<li>Iterators and references into either vector remain valid, and remain
|
|
pointing to the same element. Consequently iterators and references that
|
|
referred to one vector now refer to the other, and vice-versa.</li>
|
|
</ol>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Add a new paragraph after 23.2.4.2 <a href="lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5:</p>
|
|
<blockquote>
|
|
<pre>
|
|
void swap(vector<T,Allocator>& x);
|
|
</pre>
|
|
<p>
|
|
<b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
|
|
with that of <tt>x</tt>.</p>
|
|
<p>
|
|
<b>Complexity:</b> Constant time.</p>
|
|
</blockquote>
|
|
|
|
<p><i>[This solves the problem reported for this issue. We may also
|
|
have a problem with a circular definition of swap() for other
|
|
containers.]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>
|
|
swap should be constant time. The clear intent is that it should just
|
|
do pointer twiddling, and that it should exchange all properties of
|
|
the two vectors, including their reallocation guarantees.
|
|
</p>
|
|
<hr>
|
|
<a name="342"><h3>342. seek and eofbit</h3></a><p>
|
|
<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 09 Oct 201</p>
|
|
<p>I think we have a defect.</p>
|
|
|
|
<p>According to lwg issue <a href="lwg-defects.html#60">60</a> which is now a dr, the
|
|
description of seekg in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 38 now looks
|
|
like:</p>
|
|
|
|
<blockquote>
|
|
Behaves as an unformatted input function (as described in 27.6.1.3,
|
|
paragraph 1), except that it does not count the number of characters
|
|
extracted and does not affect the value returned by subsequent calls to
|
|
gcount(). After constructing a sentry object, if fail() != true,
|
|
executes rdbuf()­>pubseekpos( pos).
|
|
</blockquote>
|
|
|
|
<p>And according to lwg issue <a href="lwg-defects.html#243">243</a> which is also now a dr,
|
|
27.6.1.3, paragraph 1 looks like:</p>
|
|
|
|
<blockquote>
|
|
Each unformatted input function begins execution by constructing an
|
|
object of class sentry with the default argument noskipws (second)
|
|
argument true. If the sentry object returns true, when converted to a
|
|
value of type bool, the function endeavors to obtain the requested
|
|
input. Otherwise, if the sentry constructor exits by throwing an
|
|
exception or if the sentry object returns false, when converted to a
|
|
value of type bool, the function returns without attempting to obtain
|
|
any input. In either case the number of extracted characters is set to
|
|
0; unformatted input functions taking a character array of non-zero
|
|
size as an argument shall also store a null character (using charT())
|
|
in the first location of the array. If an exception is thrown during
|
|
input then ios::badbit is turned on in *this'ss error state. If
|
|
(exception()&badbit)!= 0 then the exception is rethrown. It also counts
|
|
the number of characters extracted. If no exception has been thrown it
|
|
ends by storing the count in a member object and returning the value
|
|
specified. In any event the sentry object is destroyed before leaving
|
|
the unformatted input function.
|
|
</blockquote>
|
|
|
|
<p>And finally 27.6.1.1.2/5 says this about sentry:</p>
|
|
|
|
<blockquote>
|
|
If, after any preparation is completed, is.good() is true, ok_ != false
|
|
otherwise, ok_ == false.
|
|
</blockquote>
|
|
|
|
<p>
|
|
So although the seekg paragraph says that the operation proceeds if
|
|
!fail(), the behavior of unformatted functions says the operation
|
|
proceeds only if good(). The two statements are contradictory when only
|
|
eofbit is set. I don't think the current text is clear which condition
|
|
should be respected.
|
|
</p>
|
|
|
|
<p><b>Further discussion from Redmond:</b></p>
|
|
|
|
<p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
|
|
"unformatted". That makes specific claims about sentry that
|
|
aren't quite appropriate for seeking, which has less fragile failure
|
|
modes than actual input. If we do really mean that it's unformatted
|
|
input, it should behave the same way as other unformatted input. On
|
|
the other hand, "principle of least surprise" is that seeking from EOF
|
|
ought to be OK.</p>
|
|
|
|
<p>Dietmar: nothing should depend on eofbit. Eofbit should only be
|
|
examined by the user to determine why something failed.</p>
|
|
|
|
<p><i>[Taken from c++std-lib-8873, c++std-lib-8874, c++std-lib-8876]</i></p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p><i>[Howard will do a survey to find out if there are any other
|
|
places where we have a problem, where the difference between
|
|
<tt>fail()</tt> and <tt>!good()</tt> is important.]</i></p>
|
|
<hr>
|
|
<a name="347"><h3>347. locale::category and bitmask requirements</h3></a><p>
|
|
<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Date:</b> 23 Oct 2001</p>
|
|
<p>
|
|
In 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> paragraph 1, the category members
|
|
are described as bitmask elements. In fact, the bitmask requirements
|
|
in 17.3.2.1.2 <a href="lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> don't seem quite right: <tt>none</tt>
|
|
and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
|
|
|
|
<p>In particular, the requirements for <tt>none</tt> interact poorly
|
|
with the requirement that the LC_* constants from the C library must
|
|
be recognizable as C++ locale category constants. LC_* values should
|
|
not be mixed with these values to make category values.</p>
|
|
|
|
<p>We have two options for the proposed resolution. Informally:
|
|
option 1 removes the requirement that LC_* values be recognized as
|
|
category arguments. Option 2 changes the category type so that this
|
|
requirement is implementable, by allowing <tt>none</tt> to be some
|
|
value such as 0x1000 instead of 0.</p>
|
|
|
|
<p>Nathan writes: "I believe my proposed resolution [Option 2] merely
|
|
re-expresses the status quo more clearly, without introducing any
|
|
changes beyond resolving the DR.</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
<b>Option 1:</b> <br>
|
|
Replace the first two paragraphs of 22.1.1.1 <a href="lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
|
|
<blockquote>
|
|
<pre>
|
|
typedef int category;
|
|
</pre>
|
|
|
|
<p>Valid category values include the <tt>locale</tt> member bitmask
|
|
elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
|
|
<tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
|
|
represents a single locale category. In addition, <tt>locale</tt> member
|
|
bitmask constant <tt>none</tt> is defined as zero and represents no
|
|
category. And locale member bitmask constant <tt>all</tt> is defined such that
|
|
the expression</p>
|
|
<pre>
|
|
(collate | ctype | monetary | numeric | time | messages | all) == all
|
|
</pre>
|
|
<p>
|
|
is <tt>true</tt>, and represents the union of all categories. Further
|
|
the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
|
|
represent a single category, represents the union of the two
|
|
categories.
|
|
</p>
|
|
|
|
<p>
|
|
<tt>locale</tt> member functions expecting a <tt>category</tt>
|
|
argument require one of the <tt>category</tt> values defined above, or
|
|
the union of two or more such values. Such a <tt>category</tt>
|
|
argument identifies a set of locale categories. Each locale category,
|
|
in turn, identifies a set of locale facets, including at least those
|
|
shown in Table 51:
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>
|
|
<b>Option 2:</b> <br>
|
|
Replace the first paragraph of 22.1.1.1 <a href="lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
|
|
<blockquote>
|
|
<p>
|
|
Valid category values include the enumerated values. In addition, the
|
|
result of applying commutative operators | and & to any two valid
|
|
values is valid, and results in the setwise union and intersection,
|
|
respectively, of the argument categories. The values <tt>all</tt> and
|
|
<tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
|
|
expressions <tt>(cat | all == all)</tt>, <tt>(cat & all == cat)</tt>,
|
|
<tt>(cat | none == cat)</tt> and <tt>(cat & none == none)</tt> are
|
|
true. For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
|
|
remaining enumerated values, <tt>(cat1 & cat2 == none)</tt> is true.
|
|
For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
|
|
of <tt>(cat1 & ~cat2)</tt> is valid, and equals the setwise union of
|
|
those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
|
|
[Footnote: it is not required that <tt>all</tt> equal the setwise union
|
|
of the other enumerated values; implementations may add extra categories.]
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Curaçao: need input from locale experts.]</i></p>
|
|
|
|
<hr>
|
|
<a name="348"><h3>348. Minor issue with std::pair operator<</h3></a><p>
|
|
<b>Section:</b> 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 23 Oct 2001</p>
|
|
<p>
|
|
The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
|
|
operator< on any pair type which contains a pointer.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 6, replace:</p>
|
|
<pre>
|
|
Returns: x.first < y.first || (!(y.first < x.first) && x.second <
|
|
y.second).
|
|
</pre>
|
|
<p>With:</p>
|
|
<pre>
|
|
Returns: std::less<T1>()( x.first, y.first ) ||
|
|
(!std::less<T1>()( y.first, x.first) &&
|
|
std::less<T2>()( x.second, y.second ) )
|
|
</pre>
|
|
|
|
<p><i>[Curaçao: LWG leaning toward NAD. In favor of the PR is
|
|
that it removes a trap for users. Concerns: 1) will break some
|
|
small amount of existing code (which define less and operator <
|
|
with different behavior), 2) don't have any indication of rationale
|
|
for current design (and unwilling to change without knowing
|
|
rationale), 3) consistency; pairs of ptrs would behave differenly from
|
|
individual pointers.]</i></p>
|
|
|
|
<hr>
|
|
<a name="349"><h3>349. Minor typographical error in ostream_iterator</h3></a><p>
|
|
<b>Section:</b> 24.5.2 <a href="lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 24 Oct 2001</p>
|
|
<p>24.5.2 [lib.ostream.iterator] states:</p>
|
|
<pre>
|
|
[...]
|
|
|
|
private:
|
|
// basic_ostream<charT,traits>* out_stream; exposition only
|
|
// const char* delim; exposition only
|
|
</pre>
|
|
|
|
<p>Whilst it's clearly marked "exposition only", I suspect 'delim'
|
|
should be of type 'const charT*'.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 24.5.2 <a href="lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>, replace <tt>const char* delim</tt> with
|
|
<tt>const charT* delim</tt>.
|
|
</p>
|
|
<hr>
|
|
<a name="350"><h3>350. allocator<>::address</h3></a><p>
|
|
<b>Section:</b> 20.4.1.1 <a href="lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>, 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 25 Oct 2001</p>
|
|
<p>See c++std-lib-9006 and c++std-lib-9007. This issue is taken
|
|
verbatim from -9007.</p>
|
|
|
|
<p>
|
|
The core language feature allowing definition of operator&() applied
|
|
to any non-builtin type makes that operator often unsafe to use in
|
|
implementing libraries, including the Standard Library. The result
|
|
is that many library facilities fail for legal user code, such as
|
|
the fragment</p>
|
|
<pre>
|
|
class A { private: A* operator&(); };
|
|
std::vector<A> aa;
|
|
|
|
class B { };
|
|
B* operator&(B&) { return 0; }
|
|
std::vector<B> ba;
|
|
</pre>
|
|
|
|
<p>
|
|
In particular, the requirements table for Allocator (Table 32) specifies
|
|
no semantics at all for member address(), and allocator<>::address is
|
|
defined in terms of unadorned operator &.
|
|
</p>
|
|
|
|
<p><i>[Curaçao: The LWG believes both examples are ill-formed.
|
|
The contained type is required to be CopyConstructible (20.1.3), and
|
|
that includes the requirement that &t return the usual types and
|
|
values. Since the CopyConstructible requirements appear to have been
|
|
written to deal with the concerns of this issue, the LWG feels it is
|
|
NAD unless someone can come up with a well-formed example exhibiting a
|
|
problem.]</i></p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 20.4.1.1, Change the definition of allocator<>::address from:</p>
|
|
<blockquote>
|
|
Returns: &x
|
|
</blockquote>
|
|
|
|
<p>to:</p>
|
|
|
|
<p>
|
|
Returns: The value that the built in operator&(x) would return if not
|
|
overloaded.
|
|
</p>
|
|
|
|
<p>
|
|
In 20.1.5, Table 32, add to the Notes column of the a.address(r) and
|
|
a.address(s) lines, respectively:
|
|
</p>
|
|
|
|
<pre>
|
|
allocator<T>::address(r)
|
|
allocator<T>::address(s)
|
|
</pre>
|
|
|
|
<p>In addition, in clause 17.4.1.1, add a statement:</p>
|
|
|
|
<blockquote>
|
|
The Standard Library does not apply operator& to any type for which
|
|
operator& may be overloaded.
|
|
</blockquote>
|
|
|
|
<p><i>[Curaçao: If the issues isn't NAD, suggest changing "if not
|
|
overloaded" to "ignoring all overloads".]</i></p>
|
|
|
|
<p><b>Rationale:</b></p>
|
|
<p>The obvious implementations for std::allocator<>::address are</p>
|
|
<pre>
|
|
T* reinterpret_cast<T*>(&static_cast<char&>(o));
|
|
</pre>
|
|
|
|
<p>and</p>
|
|
|
|
<pre>
|
|
T const* reinterpret_cast<T const*>(&static_cast<char const&>(o));
|
|
</pre>
|
|
|
|
<p>
|
|
but to define them formally in terms of reinterpret_cast<> seems
|
|
to introduce semantic difficulties best avoided. Using a.address()
|
|
should not introduce unspecified or implementation-defined semantics
|
|
into a user program.</p>
|
|
<hr>
|
|
<a name="352"><h3>352. missing fpos requirements</h3></a><p>
|
|
<b>Section:</b> 21.1.2 <a href="lib-strings.html#lib.char.traits.typedefs"> [lib.char.traits.typedefs]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2 Dec 2001</p>
|
|
<p>
|
|
<i>(1)</i>
|
|
There are no requirements on the <tt>stateT</tt> template parameter of
|
|
<tt>fpos</tt> listed in 27.4.3. The interface appears to require that
|
|
the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
|
|
and I think also DefaultConstructible (to implement the operations in
|
|
Table 88).
|
|
</p>
|
|
<p>
|
|
21.1.2, p3, however, only requires that
|
|
<tt>char_traits<charT>::state_type</tt> meet the requirements of
|
|
CopyConstructible types.
|
|
</p>
|
|
<p>
|
|
<i>(2)</i>
|
|
Additionally, the <tt>stateT</tt> template argument has no
|
|
corresponding typedef in fpos which might make it difficult to use in
|
|
generic code.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Modify 21.1.2, p4 from
|
|
</p>
|
|
<p>
|
|
Requires: <tt>state_type</tt> shall meet the requirements of
|
|
CopyConstructible types (20.1.3).
|
|
</p>
|
|
<p>
|
|
Requires: state_type shall meet the requirements of Assignable
|
|
(23.1, p4), CopyConstructible (20.1.3), and
|
|
DefaultConstructible (20.1.4) types.
|
|
</p>
|
|
<p>
|
|
Add to the definition of the fpos class template the following member:
|
|
</p>
|
|
<pre>
|
|
typedef stateT state_type;
|
|
</pre>
|
|
<p>
|
|
and add to 27.4.3.1 a paragraph with the following text:
|
|
</p>
|
|
<pre>
|
|
typedef stateT state_type;
|
|
</pre>
|
|
<p>
|
|
Requires: <tt>state_type</tt> shall meet the requirements of
|
|
Assignable (23.1, p4), CopyConstructible (20.1.3), and
|
|
DefaultConstructible (20.1.4) types.
|
|
</p>
|
|
|
|
<p><i>[Curaçao: The LWG feels this is two issues, as indicated
|
|
above. The first is a defect; more I/O experts need to review
|
|
the PR. The second is questionable; who would use it? Unless
|
|
motivation is provided, the second should be considered NAD.]</i></p>
|
|
|
|
<hr>
|
|
<a name="354"><h3>354. Associative container lower/upper bound requirements</h3></a><p>
|
|
<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Hans Aberg <b>Date:</b> 17 Dec 2001</p>
|
|
<p>
|
|
Discussions in the thread "Associative container lower/upper bound
|
|
requirements" on comp.std.c++ suggests that there is a defect in the
|
|
C++ standard, Table 69 of section 23.1.2, "Associative containers",
|
|
[lib.associative.reqmts]. It currently says:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
a.find(k): returns an iterator pointing to an element with the key equivalent to
|
|
k, or a.end() if such an element is not found.
|
|
</p>
|
|
|
|
<p>
|
|
a.lower_bound(k): returns an iterator pointing to the first element with
|
|
key not less than k.
|
|
</p>
|
|
|
|
<p>
|
|
a.upper_bound(k): returns an iterator pointing to the first element with
|
|
key greater than k.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p>
|
|
We have "or a.end() if such an element is not found" for
|
|
<tt>find</tt>, but not for <tt>upper_bound</tt> or
|
|
<tt>lower_bound</tt>. As the text stands, one would be forced to
|
|
insert a new element into the container and return an iterator to that
|
|
in case the sought iterator does not exist, which does not seem to be
|
|
the intention (and not possible with the "const" versions).
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
|
|
<p>Change Table 69 of section 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> indicated entries
|
|
to:</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
a.lower_bound(k): returns an iterator pointing to the first element with
|
|
key not less than k, or a.end() if such an element is not found.
|
|
</p>
|
|
|
|
<p>
|
|
a.upper_bound(k): returns an iterator pointing to the first element with
|
|
key greater than k, or a.end() if such an element is not found.
|
|
</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Curaçao: LWG reviewed PR.]</i></p>
|
|
|
|
<hr>
|
|
<a name="355"><h3>355. Operational semantics for a.back()</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#Review">Review</a> <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 23 Jan 2002</p>
|
|
|
|
<p>Table 68 "Optional Sequence Operations" in 23.1.1/12
|
|
specifies operational semantics for "a.back()" as
|
|
"*--a.end()", which may be ill-formed <i>[because calling
|
|
operator-- on a temporary (the return) of a built-in type is
|
|
ill-formed]</i>, provided a.end() returns a simple pointer rvalue
|
|
(this is almost always the case for std::vector::end(), for
|
|
example). Thus, the specification is not only incorrect, it
|
|
demonstrates a dangerous construct: "--a.end()" may
|
|
successfully compile and run as intended, but after changing the type
|
|
of the container or the mode of compilation it may produce
|
|
compile-time error. </p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the specification in table 68 "Optional Sequence
|
|
Operations" in 23.1.1/12 for "a.back()" from</p>
|
|
|
|
|
|
<blockquote>
|
|
*--a.end()
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
<p>*a.rbegin()</p>
|
|
</blockquote>
|
|
|
|
<p>and the specification for "a.pop_back()" from</p>
|
|
|
|
<blockquote>
|
|
a.erase(--a.end())
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
<p>a.erase(rbegin())</p>
|
|
</blockquote>
|
|
|
|
<p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
|
|
a.end(); return *--tmp; }" to "*a.rbegin()", and from
|
|
"{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
|
|
"a.erase(rbegin())".]</i></p>
|
|
|
|
<p><i>[There is a second possible defect; table 68 "Optional
|
|
Sequence Operations" in the "Operational Semantics"
|
|
column uses operations present only in the "Reversible
|
|
Container" requirements, yet there is no stated dependency
|
|
between these separate requirements tables. Ask in Santa Cruz if the
|
|
LWG would like a new issue opened.]</i></p>
|
|
|
|
<hr>
|
|
<a name="356"><h3>356. Meaning of ctype_base::mask enumerators</h3></a><p>
|
|
<b>Section:</b> 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jan 2002</p>
|
|
|
|
<p>What should the following program print?</p>
|
|
|
|
<pre>
|
|
#include <locale>
|
|
#include <iostream>
|
|
|
|
class my_ctype : public std::ctype<char>
|
|
{
|
|
typedef std::ctype<char> base;
|
|
public:
|
|
my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
|
|
{
|
|
std::copy(base::classic_table(), base::classic_table() + base::table_size,
|
|
my_table);
|
|
my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
|
|
}
|
|
private:
|
|
mask my_table[base::table_size];
|
|
};
|
|
|
|
int main()
|
|
{
|
|
my_ctype ct;
|
|
std::cout << "isspace: " << ct.is(std::ctype_base::space, '_') << " "
|
|
<< "isalpha: " << ct.is(std::ctype_base::alpha, '_') << std::endl;
|
|
}
|
|
</pre>
|
|
|
|
<p>The goal is to create a facet where '_' is treated as whitespace.</p>
|
|
|
|
<p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0". On
|
|
Microsoft C++ it prints "isspace: 1 isalpha: 1".</p>
|
|
|
|
<p>
|
|
I believe that both implementations are legal, and the standard does not
|
|
give enough guidance for users to be able to use std::ctype's
|
|
protected interface portably.</p>
|
|
|
|
<p>
|
|
The above program assumes that ctype_base::mask enumerators like
|
|
<tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
|
|
say that a character is both a space and a printing character is to or
|
|
those two enumerators together. This is suggested by the "exposition
|
|
only" values in 22.2.1 <a href="lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, but it is nowhere specified in
|
|
normative text. An alternative interpretation is that the more
|
|
specific categories subsume the less specific. The above program
|
|
gives the results it does on the Microsoft compiler because, on that
|
|
compiler, <tt>print</tt> has all the bits set for each specific
|
|
printing character class.
|
|
</p>
|
|
|
|
<p>From the point of view of std::ctype's public interface, there's no
|
|
important difference between these two techniques. From the point of
|
|
view of the protected interface, there is. If I'm defining a facet
|
|
that inherits from std::ctype<char>, I'm the one who defines the
|
|
value that table()['a'] returns. I need to know what combination of
|
|
mask values I should use. This isn't so very esoteric: it's exactly
|
|
why std::ctype has a protected interface. If we care about users
|
|
being able to write their own ctype facets, we have to give them a
|
|
portable way to do it.
|
|
</p>
|
|
|
|
<p>
|
|
Related reflector messages:
|
|
lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
|
|
lib-9277, lib-9279.
|
|
</p>
|
|
|
|
<p>Issue <a href="lwg-active.html#339">339</a> is related, but not identical. The
|
|
proposed resolution if issue <a href="lwg-active.html#339">339</a> says that
|
|
ctype_base::mask must be a bitmask type. It does not say that the
|
|
ctype_base::mask elements are bitmask elements, so it doesn't
|
|
directly affect this issue.</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Informally, we have three choices:</p>
|
|
<ol>
|
|
<li>Require that the enumerators are disjoint (except for alnum and
|
|
graph)</li>
|
|
<li>Require that the enumerators are not disjoint, and specify which
|
|
of them subsume which others. (e.g. mandate that lower includes alpha
|
|
and print)</li>
|
|
<li>Explicitly leave this unspecified, which the result that the above
|
|
program is not portable.</li>
|
|
</ol>
|
|
|
|
<p>Either of the first two options is just as good from the standpoint
|
|
of portability. Either one will require some implementations to
|
|
change.</p>
|
|
|
|
<hr>
|
|
<a name="357"><h3>357. <cmath> float functions cannot return HUGE_VAL</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#Open">Open</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 26 Feb 2002</p>
|
|
<p>
|
|
The float versions of the math functions have no meaningful value to return
|
|
for a range error. The long double versions have a value they can return,
|
|
but it isn't necessarily the most reasonable value.
|
|
</p>
|
|
|
|
<p>
|
|
Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long
|
|
double overloaded versions of these functions, with the same semantics,"
|
|
referring to the math functions from the C90 standard.
|
|
</p>
|
|
|
|
<p>
|
|
The C90 standard, in section 7.5.1, paragraph 3, says that functions return
|
|
"the value of the macro HUGE_VAL" when they encounter a range error.
|
|
Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a
|
|
positive double expression, not necessarily representable as a float."
|
|
</p>
|
|
|
|
<p>
|
|
Therefore, the float versions of the math functions have no way to
|
|
signal a range error. <i>[Curaçao: The LWG notes that this isn't
|
|
strictly correct, since errno is set.]</i> The semantics require that they
|
|
return HUGE_VAL, but they cannot because HUGE_VAL might not be
|
|
representable as a float.
|
|
</p>
|
|
|
|
<p>
|
|
The problem with long double functions is less severe because HUGE_VAL is
|
|
representable as a long double. On the other hand, it might not be a "huge"
|
|
long double value, and might fall well within the range of normal return
|
|
values for a long double function. Therefore, it does not make sense for a
|
|
long double function to return a double (HUGE_VAL) for a range error.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Curaçao: C99 was faced with a similar problem, which they fixed by
|
|
adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p>
|
|
|
|
<p>C++ must also fix, but it should be done in the context of the
|
|
general C99 based changes to C++, not via DR. Thus the LWG in Curaçao
|
|
felt the resolution should be NAD, FUTURE, but the issue is being held
|
|
open for one more meeting to ensure LWG members not present during the
|
|
discussion concur.</p>
|
|
<hr>
|
|
<a name="358"><h3>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p>
|
|
<p>
|
|
I don't think <tt>thousands_sep</tt> is being treated correctly after
|
|
decimal_point has been seen. Since grouping applies only to the
|
|
integral part of the number, the first such occurrence should, IMO,
|
|
terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
|
|
and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
|
|
interpreted in the fractional part of a number.)
|
|
</p>
|
|
|
|
<p>
|
|
The easiest change I can think of that resolves this issue would be
|
|
something like below.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change the first sentence of 22.2.2.1.2, p9 from
|
|
</p>
|
|
|
|
<blockquote>
|
|
If discard is true then the position of the character is
|
|
remembered, but the character is otherwise ignored. If it is not
|
|
discarded, then a check is made to determine if c is allowed as
|
|
the next character of an input field of the conversion specifier
|
|
returned by stage 1. If so it is accumulated.
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
|
|
accumulated, then the position of the character is remembered, but
|
|
the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
|
|
already been accumulated, the character is discarded and Stage 2
|
|
terminates. ...
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<a name="359"><h3>359. num_put<>::do_put (..., bool) undocumented</h3></a><p>
|
|
<b>Section:</b> 22.2.2.2.1 <a href="lib-locales.html#lib.facet.num.put.members"> [lib.facet.num.put.members]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p>
|
|
<p>22.2.2.2.1, p1:</p>
|
|
|
|
<pre>
|
|
iter_type put (iter_type out, ios_base& str, char_type fill,
|
|
bool val) const;
|
|
...
|
|
|
|
1 Returns: do_put (out, str, fill, val).
|
|
</pre>
|
|
|
|
<p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
|
|
however, 22.2.2.2.2, p23:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
iter_type put (iter_type out, ios_base& str, char_type fill,
|
|
bool val) const;
|
|
</pre>
|
|
|
|
|
|
Effects: If (str.flags() & ios_base::boolalpha) == 0 then do
|
|
out = do_put(out, str, fill, (int)val)
|
|
Otherwise do
|
|
<pre>
|
|
string_type s =
|
|
val ? use_facet<ctype<charT> >(loc).truename()
|
|
: use_facet<ctype<charT> >(loc).falsename();
|
|
</pre>
|
|
and then insert the characters of s into out. <i>out</i>.
|
|
</blockquote>
|
|
|
|
<p>
|
|
This means that the bool overload of <tt>do_put()</tt> will never be called,
|
|
which contradicts the first paragraph. Perhaps the declaration
|
|
should read <tt>do_put()</tt>, and not <tt>put()</tt>?
|
|
</p>
|
|
|
|
<p>
|
|
Note also that there is no <b>Returns</b> clause for this function, which
|
|
should probably be corrected, just as should the second occurrence
|
|
of <i>"out."</i> in the text.
|
|
</p>
|
|
|
|
<p>
|
|
I think the least invasive change to fix it would be something like
|
|
the following:
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
In 22.2.2.2.2, p23, make the following changes
|
|
</p>
|
|
|
|
<blockquote>
|
|
Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
|
|
of the member function.
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
|
|
avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
|
|
do_put (..., bool))</tt>
|
|
like so:
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
23 <b>Returns</b>: If <tt>(str.flags() &
|
|
ios_base::boolalpha) == 0</tt> then
|
|
<tt>do_put (out, str, fill, (int)val)</tt>
|
|
Otherwise the function obtains a string <tt>s</tt> as if by
|
|
<pre>
|
|
string_type s =
|
|
val ? use_facet<ctype<charT> >(loc).truename()
|
|
: use_facet<ctype<charT> >(loc).falsename();
|
|
</pre>
|
|
and then inserts each character <tt>c</tt> of s into out via
|
|
<tt>*out++ = c</tt>
|
|
and returns <tt>out</tt>.
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<a name="360"><h3>360. locale mandates inefficient implementation</h3></a><p>
|
|
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p>
|
|
<p>
|
|
22.1.1, p7 (copied below) allows iostream formatters and extractors
|
|
to make assumptions about the values returned from facet members.
|
|
However, such assumptions are apparently not guaranteed to hold
|
|
in other cases (e.g., when the facet members are being called directly
|
|
rather than as a result of iostream calls, or between successive
|
|
calls to the same iostream functions with no interevening calls to
|
|
<tt>imbue()</tt>, or even when the facet member functions are called
|
|
from other member functions of other facets). This restriction
|
|
prevents locale from being implemented efficiently.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the first sentence in 22.1.1, p7 from</p>
|
|
<blockquote>
|
|
In successive calls to a locale facet member function during
|
|
a call to an iostream inserter or extractor or a streambuf member
|
|
function, the returned result shall be identical. [Note: This
|
|
implies that such results may safely be reused without calling
|
|
the locale facet member function again, and that member functions
|
|
of iostream classes cannot safely call <tt>imbue()</tt>
|
|
themselves, except as specified elsewhere. --end note]
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
|
|
<blockquote>
|
|
In successive calls to a locale facet member function on a facet
|
|
object installed in the same locale, the returned result shall be
|
|
identical. ...
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<a name="361"><h3>361. num_get<>::do_get (..., void*&) checks grouping</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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p>
|
|
<p>
|
|
22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only
|
|
for integral types (issue 282 suggests that this should be done for
|
|
all arithmetic types).
|
|
</p>
|
|
|
|
<p>
|
|
22.2.2.1.2, p12 requires that grouping be checked for all extractors
|
|
including that for <tt>void*</tt>.
|
|
</p>
|
|
|
|
<p>
|
|
I don't think that's right. <tt>void*</tt> values should not be checked for
|
|
grouping, should they? (Although if they should, then <tt>num_put</tt> needs
|
|
to write them out, otherwise their extraction will fail.)
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change the first sentence of 22.2.2.2.2, p12 from
|
|
</p>
|
|
<blockquote>
|
|
Digit grouping is checked. That is, the positions of discarded
|
|
separators is examined for consistency with
|
|
use_facet<numpunct<charT> >(loc).grouping().
|
|
If they are not consistent then ios_base::failbit is assigned
|
|
to err.
|
|
</blockquote>
|
|
|
|
<p>to</p>
|
|
<blockquote>
|
|
Except for conversions to void*, digit grouping is checked...
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<a name="362"><h3>362. bind1st/bind2nd type safety</h3></a><p>
|
|
<b>Section:</b> 20.3.6.2 <a href="lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Andrew Demkin <b>Date:</b> 26 Apr 2002</p>
|
|
<p>
|
|
The definition of bind1st() (20.3.6.2 <a href="lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in
|
|
the construction of an unsafe binding between incompatible pointer
|
|
types. For example, given a function whose first parameter type is
|
|
'pointer to T', it's possible without error to bind an argument of
|
|
type 'pointer to U' when U does not derive from T:
|
|
</p>
|
|
<pre>
|
|
foo(T*, int);
|
|
|
|
struct T {};
|
|
struct U {};
|
|
|
|
U u;
|
|
|
|
int* p;
|
|
int* q;
|
|
|
|
for_each(p, q, bind1st(ptr_fun(foo), &u)); // unsafe binding
|
|
</pre>
|
|
|
|
<p>
|
|
The definition of bind1st() includes a functional-style conversion to
|
|
map its argument to the expected argument type of the bound function
|
|
(see below):
|
|
</p>
|
|
<pre>
|
|
typename Operation::first_argument_type(x)
|
|
</pre>
|
|
|
|
<p>
|
|
A functional-style conversion (5.2.3 <a href="expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
|
|
semantically equivalent to an explicit cast expression (5.4 <a href="expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
|
|
as a reinterpret_cast, thus masking the error.
|
|
</p>
|
|
|
|
<p>The problem and proposed change also apply to 20.3.6.4 <a href="lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
The simplest and most localized change to prevent such errors is to
|
|
require bind1st() use a static_cast expression rather than the
|
|
functional-style conversion; that is, have bind1st() return:
|
|
</p>
|
|
<pre>
|
|
binder1st<Operation>( op,
|
|
static_cast<typename Operation::first_argument_type>(x)).
|
|
</pre>
|
|
|
|
<p>
|
|
A more agressive solution is to change the semantics of
|
|
functional-style conversions to not permit a reinterpret_cast. For
|
|
contexts that require the semantics of reinterpret_cast, the language
|
|
may want to require the use of an explicit cast expression such as
|
|
'(T) x' or 'reinterpret_cast<T>(x)' and limit the behavior of
|
|
the functional notation to match statically-checked and standard
|
|
conversions (as defined by 5.2.9 and 4.10, etc.). Although changing
|
|
the semantics of functional-style conversions may seem drastic and
|
|
does have language-wide ramifications, it has the benefit of better
|
|
unifying the conversion rules for user defined types and built-in
|
|
types, which can be especially important for generic template
|
|
programming.
|
|
</p>
|
|
<hr>
|
|
<a name="363"><h3>363. Missing exception specification in 27.4.2.1.1</h3></a><p>
|
|
<b>Section:</b> 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 20 May 2002</p>
|
|
<p>
|
|
The destructor of ios_base::failure should have an empty throw
|
|
specification, because the destructor of its base class, exception, is
|
|
declared in this way.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the destructor to</p>
|
|
<pre>
|
|
virtual ~failure() throw();
|
|
</pre>
|
|
<hr>
|
|
<a name="364"><h3>364. Inconsistent wording in 27.5.2.4.2</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#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 10 May 2002</p>
|
|
<p>
|
|
27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> paragraph 1 is inconsistent with the Effects
|
|
clause for seekoff.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Make this paragraph, the Effects clause for setbuf, consistent in wording
|
|
with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
|
|
to indicate the purpose of setbuf:
|
|
</p>
|
|
|
|
<p>Original text:</p>
|
|
|
|
<blockquote>
|
|
1 Effects: Performs an operation that is defined separately for each
|
|
class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
|
|
</blockquote>
|
|
|
|
<p>Proposed text:</p>
|
|
|
|
<blockquote>
|
|
1 Effects: Influences stream buffering in a way that is defined separately
|
|
for each class derived from basic_streambuf in this clause
|
|
(27.7.1.3, 27.8.1.4).
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<a name="365"><h3>365. Lack of const-qualification in clause 27</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#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 10 May 2002</p>
|
|
<p>
|
|
None of the following member functions are declared const, but we
|
|
believe each should be. See document N1360 for details and rationale.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.5.2 and 27.5.2.2.3</p>
|
|
<p>Replace</p>
|
|
<pre>
|
|
streamsize in_avail();
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
streamsize in_avail() const;
|
|
</pre>
|
|
|
|
<p>In 27.5.2 and 27.5.2.4.3, and 27.8.1.1 and 27.8.1.4</p>
|
|
<p>Replace</p>
|
|
<pre>
|
|
virtual streamsize showmanyc();
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
virtual streamsize showmanyc() const;
|
|
</pre>
|
|
|
|
<p>In 27.6.1.1 and 27.6.1.3</p>
|
|
<p>Replace</p>
|
|
<pre>
|
|
pos_type tellg();
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
pos_type tellg() const;
|
|
</pre>
|
|
|
|
<p>This requires additional change, because paragraph 37 describes the
|
|
return value in terms of calls to non-const member functions. Either of
|
|
the two following solutions would allow tellg to be declared const.</p>
|
|
|
|
<p>Option 1: Implementers may cast away const-ness, to allow calling the
|
|
non-const rdbuf.</p>
|
|
<p>In paragraph 37, replace:</p>
|
|
<pre>
|
|
.... rdbuf()
|
|
->pubseekoff(0, cur, in).
|
|
</pre>
|
|
<p>by</p>
|
|
<pre>
|
|
.... const_cast<basic_istream<charT, traits>*>(this)->rdbuf()
|
|
->pubseekoff(0, cur, in).
|
|
</pre>
|
|
|
|
<p>Option 2: Provide const member functions to do the job. The proposals in
|
|
a later section (specifically, the modifications concerning rdbuf
|
|
throughout the iostream library) meet most of this need; we would also
|
|
need the following addition to basic_streambuf:</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
basic_streambuf<charT,traits>::pos_type
|
|
basic_streambuf<charT,traits>::position(ios_base::openmode mode =
|
|
ios_base::in|ios_base::out)
|
|
const;
|
|
</pre>
|
|
<p>Effects: same as calling basic_streambuf::pubseekoff(0, ios base::cur, mode)</p>
|
|
</blockquote>
|
|
|
|
<p>In 27.6.2.1 and 27.6.2.4</p>
|
|
<p>Replace</p>
|
|
<pre>
|
|
pos_type tellp();
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
pos_type tell() const;
|
|
</pre>
|
|
|
|
<p>This requires additional change; see the discussion for tellg() above.</p>
|
|
|
|
<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
|
|
<p>Replace</p>
|
|
<pre>
|
|
bool is_open();
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
bool is_open() const;
|
|
</pre>
|
|
<hr>
|
|
<a name="366"><h3>366. Excessive const-qualification</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#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 10 May 2002</p>
|
|
<p>
|
|
The following member functions are declared const, yet return non-const
|
|
pointers. We believe they are should be changed, because they allow code
|
|
that may surprise the user. See document N1360 for details and
|
|
rationale.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>In 27.4.4 and 27.4.4.2</p>
|
|
<p>Replace</p>
|
|
<pre>
|
|
basic_ostream<charT,traits>* tie() const;
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
basic_ostream<charT,traits>* tie();
|
|
const basic_ostream<charT,traits>* tie() const;
|
|
</pre>
|
|
|
|
<p>and replace</p>
|
|
<pre>
|
|
basic_streambuf<charT,traits>* rdbuf() const;
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
basic_streambuf<charT,traits>* rdbuf();
|
|
const basic_streambuf<charT,traits>* rdbuf() const;
|
|
</pre>
|
|
|
|
<p>In 27.5.2 and 27.5.2.3.1</p>
|
|
<p>Replace</p>
|
|
<pre>
|
|
char_type* eback() const;
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
char_type* eback();
|
|
const char_type* eback() const;
|
|
</pre>
|
|
|
|
<p>Replace</p>
|
|
<pre>
|
|
char_type gptr() const;
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
char_type* gptr();
|
|
const char_type* gptr() const;
|
|
</pre>
|
|
|
|
<p>Replace</p>
|
|
<pre>
|
|
char_type* egptr() const;
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
char_type* egptr();
|
|
const char_type* egptr() const;
|
|
</pre>
|
|
|
|
<p>In 27.5.2 and 27.5.2.3.2</p>
|
|
<p>Replace</p>
|
|
<pre>
|
|
char_type* pbase() const;
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
char_type* pbase();
|
|
const char_type* pbase() const;
|
|
</pre>
|
|
|
|
<p>Replace</p>
|
|
<pre>
|
|
char_type* pptr() const;
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
char_type* pptr();
|
|
const char_type* pptr() const;
|
|
</pre>
|
|
|
|
<p>Replace</p>
|
|
<pre>
|
|
char_type* epptr() const;
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
char_type* epptr();
|
|
const char_type* epptr() const;
|
|
</pre>
|
|
|
|
<p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
|
|
<p>Replace</p>
|
|
<pre>
|
|
basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
basic_stringbuf<charT,traits,Allocator>* rdbuf();
|
|
const basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
|
|
</pre>
|
|
|
|
<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
|
|
<p>Replace</p>
|
|
<pre>
|
|
basic_filebuf<charT,traits>* rdbuf() const;
|
|
</pre>
|
|
<p>with</p>
|
|
<pre>
|
|
basic_filebuf<charT,traits>* rdbuf();
|
|
const basic_filebuf<charT,traits>* rdbuf() const;
|
|
</pre>
|
|
<hr>
|
|
<a name="367"><h3>367. remove_copy/remove_copy_if and Input Iterators</h3></a><p>
|
|
<b>Section:</b> 25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 13 May 2002</p>
|
|
<p>
|
|
remove_copy and remove_copy_if (25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>) permit their
|
|
input range to be marked with Input Iterators. However, since two
|
|
operations are required against the elements to copy (comparison and
|
|
assigment), when the input range uses Input Iterators, a temporary
|
|
copy must be taken to avoid dereferencing the iterator twice. This
|
|
therefore requires the value type of the InputIterator to be
|
|
CopyConstructible. If the iterators are at least Forward Iterators,
|
|
then the iterator can be dereferenced twice, or a reference to the
|
|
result maintained, so the temporary is not required.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add "If InputIterator does not meet the requirements of forward
|
|
iterator, then the value type of InputIterator must be copy
|
|
constructible. Otherwise copy constructible is not required." to
|
|
25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> paragraph 6.
|
|
</p>
|
|
<hr>
|
|
<a name="368"><h3>368. basic_string::replace has two "Throws" paragraphs</h3></a><p>
|
|
<b>Section:</b> 21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 3 Jun 2002</p>
|
|
<p>
|
|
21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a> basic_string::replace, second
|
|
signature, given in paragraph 1, has two "Throws" paragraphs (3 and
|
|
5).
|
|
</p>
|
|
|
|
<p>
|
|
In addition, the second "Throws" paragraph (5) includes specification
|
|
(beginning with "Otherwise, the function replaces ...") that should be
|
|
part of the "Effects" paragraph.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<hr>
|
|
<a name="369"><h3>369. io stream objects and static ctors</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#New">New</a> <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 8 Jul 2002</p>
|
|
<p>
|
|
Is it safe to use standard iostream objects from constructors of
|
|
static objects? Are standard iostream objects constructed and are
|
|
their associations established at that time?
|
|
</p>
|
|
|
|
<p>Surpisingly enough, Standard does NOT require that.</p>
|
|
|
|
<p>
|
|
27.3/2 [lib.iostream.objects] guarantees that standard iostream
|
|
objects are constructed and their associations are established before
|
|
the body of main() begins execution. It also refers to ios_base::Init
|
|
class as the panacea for constructors of static objects.
|
|
</p>
|
|
|
|
<p>
|
|
However, there's nothing in 27.3 [lib.iostream.objects],
|
|
in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
|
|
that would require implementations to allow access to standard
|
|
iostream objects from constructors of static objects.
|
|
</p>
|
|
|
|
<p>Details:</p>
|
|
|
|
<p>Core text refers to some magic object ios_base::Init, which will
|
|
be discussed below:</p>
|
|
|
|
<blockquote>
|
|
"The [standard iostream] objects are constructed, and their
|
|
associations are established at some time prior to or during
|
|
first time an object of class basic_ios<charT,traits>::Init
|
|
is constructed, and in any case before the body of main
|
|
begins execution." (27.3/2 [lib.iostream.objects])
|
|
</blockquote>
|
|
|
|
<p>
|
|
The first <i>non-normative</i> footnote encourages implementations
|
|
to initialize standard iostream objects earlier than required.
|
|
</p>
|
|
|
|
<p>However, the second <i>non-normative</i> footnote makes an explicit
|
|
and unsupported claim:</p>
|
|
|
|
<blockquote>
|
|
"Constructors and destructors for static objects can access these
|
|
[standard iostream] objects to read input from stdin or write output
|
|
to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
|
|
</blockquote>
|
|
|
|
<p>
|
|
The only bit of magic is related to that ios_base::Init class. AFAIK,
|
|
the rationale behind ios_base::Init was to bring an instance of this
|
|
class to each translation unit which #included <iostream> or
|
|
related header. Such an inclusion would support the claim of footnote
|
|
quoted above, because in order to use some standard iostream object it
|
|
is necessary to #include <iostream>.
|
|
</p>
|
|
|
|
<p>
|
|
However, while Standard explicitly describes ios_base::Init as
|
|
an appropriate class for doing the trick, I failed to found a
|
|
mention of an _instance_ of ios_base::Init in Standard.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
At the end of header <iostream> synopsis in 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>
|
|
</p>
|
|
|
|
<pre>
|
|
namespace std
|
|
{
|
|
... extern istream cin; ...
|
|
</pre>
|
|
|
|
<p>add the following lines</p>
|
|
|
|
<pre>
|
|
namespace
|
|
{
|
|
ios_base::Init <some_implementation_defined_name>;
|
|
}
|
|
}
|
|
</pre>
|
|
<hr>
|
|
<a name="370"><h3>370. Minor error in basic_istream::get</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#New">New</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 15 Jul 2002</p>
|
|
<p>Defect report for description of basic_istream::get (section 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), paragraph 15. The description for the get function
|
|
with the following signature:</p>
|
|
|
|
<pre>
|
|
basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>&
|
|
sb);
|
|
</pre>
|
|
|
|
<p>is incorrect. It reads</p>
|
|
|
|
<blockquote>
|
|
Effects: Calls get(s,n,widen('\n'))
|
|
</blockquote>
|
|
|
|
<p>which I believe should be:</p>
|
|
|
|
<blockquote>
|
|
Effects: Calls get(sb,widen('\n'))
|
|
</blockquote>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>Change the <b>Effects</b> paragraph to:</p>
|
|
<blockquote>
|
|
Effects: Calls get(sb,widen('\n'))
|
|
</blockquote>
|
|
<hr>
|
|
<a name="371"><h3>371. Stability of multiset and multimap member functions</h3></a><p>
|
|
<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Frank Compagner <b>Date:</b> 20 Jul 2002</p>
|
|
<p>
|
|
The requirements for multiset and multimap containers (23.1
|
|
[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
|
|
23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
|
|
the stability of the required (mutating) member functions. It appears
|
|
the standard allows these functions to reorder equivalent elements of
|
|
the container at will, yet the pervasive red-black tree implementation
|
|
appears to provide stable behaviour.
|
|
</p>
|
|
|
|
<p>This is of most concern when considering the behaviour of erase().
|
|
A stability requirement would guarantee the correct working of the
|
|
following 'idiom' that removes elements based on a certain predicate
|
|
function.
|
|
</p>
|
|
|
|
<pre>
|
|
multimap<int, int> m;
|
|
multimap<int, int>::iterator i = m.begin();
|
|
while (i != m.end()) {
|
|
if (pred(i))
|
|
m.erase (i++);
|
|
else
|
|
++i;
|
|
}
|
|
</pre>
|
|
|
|
<p>
|
|
Although clause 23.1.2/8 guarantees that i remains a valid iterator
|
|
througout this loop, absence of the stability requirement could
|
|
potentially result in elements being skipped. This would make
|
|
this code incorrect, and, furthermore, means that there is no way
|
|
of erasing these elements without iterating first over the entire
|
|
container, and second over the elements to be erased. This would
|
|
be unfortunate, and have a negative impact on both performance and
|
|
code simplicity.
|
|
</p>
|
|
|
|
<p>
|
|
If the stability requirement is intended, it should be made explicit
|
|
(probably through an extra paragraph in clause 23.1.2).
|
|
</p>
|
|
<p>
|
|
If it turns out stability cannot be guaranteed, i'd argue that a
|
|
remark or footnote is called for (also somewhere in clause 23.1.2) to
|
|
warn against relying on stable behaviour (as demonstrated by the code
|
|
above). If most implementations will display stable behaviour, any
|
|
problems emerging on an implementation without stable behaviour will
|
|
be hard to track down by users. This would also make the need for an
|
|
erase_if() member function that much greater.
|
|
</p>
|
|
|
|
<p>This issue is somewhat related to LWG issue <a href="lwg-closed.html#130">130</a>.</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<hr>
|
|
<a name="372"><h3>372. Inconsistent description of stdlib exceptions</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>, 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a>, <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Randy Maddox <b>Date:</b> 22 Jul 2002</p>
|
|
|
|
<p>Paragraph 3 under clause 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, Restrictions on
|
|
Exception Handling, states that "Any other functions defined in the
|
|
C++ Standard Library that do not have an exception-specification may
|
|
throw implementation-defined exceptions unless otherwise specified."
|
|
This statement is followed by a reference to footnote 178 at the
|
|
bottom of that page which states, apparently in reference to the C++
|
|
Standard Library, that "Library implementations are encouraged (but
|
|
not required) to report errors by throwing exceptions from (or derived
|
|
from) the standard exceptions."</p>
|
|
|
|
<p>These statements appear to be in direct contradiction to clause
|
|
18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a>, which states "The class exception defines the
|
|
base class for the types of objects thrown as exceptions by the C++
|
|
Standard library components ...".</p>
|
|
|
|
<p>Is this inconsistent?</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<hr>
|
|
<a name="373"><h3>373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?</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>, 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Keith Baker <b>Date:</b> 23 Jul 2002</p>
|
|
|
|
<p>
|
|
In 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>
|
|
(exception()&badbit) != 0 is used in testing for rethrow, yet
|
|
exception() is the constructor to class std::exception in 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> that has no return type. Should member function
|
|
exceptions() found in 27.4.4 <a href="lib-iostreams.html#lib.ios"> [lib.ios]</a> be used instead?
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
</p>
|
|
<hr>
|
|
<a name="374"><h3>374. moneypunct::frac_digits returns int not unsigned</h3></a><p>
|
|
<b>Section:</b> 22.2.6.3.1 <a href="lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 8 Aug 2002</p>
|
|
<p>
|
|
In section 22.2.6.3.1 <a href="lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, frac_digits() returns type
|
|
"int". This implies that frac_digits() might return a negative value,
|
|
but a negative value is nonsensical. It should return "unsigned".
|
|
</p>
|
|
|
|
<p>
|
|
Similarly, in section 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>, do_frac_digits()
|
|
should return "unsigned".
|
|
</p>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<hr>
|
|
<a name="375"><h3>375. basic_ios should be ios_base in 27.7.1.3</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#New">New</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 14 Aug 2002</p>
|
|
<p>
|
|
In Section 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>: Table 90, Table 91, and paragraph
|
|
14 all contain references to "basic_ios::" which should be
|
|
"ios_base::".
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change all references to "basic_ios" in Table 90, Table 91, and
|
|
paragraph 14 to "ios_base".
|
|
</p>
|
|
<hr>
|
|
<a name="376"><h3>376. basic_streambuf semantics</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#New">New</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 14 Aug 2002</p>
|
|
<p>
|
|
In Section 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that
|
|
the four conditions should be mutually exclusive, but they are not.
|
|
The first two cases, as written, are subcases of the third. I think it
|
|
would be clearer if the conditions were rewritten as follows:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<p>
|
|
(which & (ios_base::in|ios_base::out)) == ios_base::in
|
|
</p>
|
|
|
|
<p>
|
|
(which & (ios_base::in|ios_base::out)) == ios_base::out
|
|
</p>
|
|
|
|
<p>
|
|
(which & (ios_base::in|ios_base::out)) ==
|
|
(ios_base::in|ios_base::out)
|
|
and way == either ios_base::beg or ios_base::end
|
|
</p>
|
|
|
|
<p>Otherwise</p>
|
|
</blockquote>
|
|
|
|
<p>
|
|
As written, it is unclear what should be the result if cases 1 & 2
|
|
are true, but case 3 is false, e.g.,
|
|
</p>
|
|
|
|
<blockquote>
|
|
seekoff(0, ios_base::cur, ios_base::in | ios_base::out)
|
|
</blockquote>
|
|
|
|
<p><b>Proposed resolution:</b></p>
|
|
<hr>
|
|
<a name="377"><h3>377. basic_string::insert and length_error</h3></a><p>
|
|
<b>Section:</b> 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 16 Aug 2002</p>
|
|
<p>
|
|
Section 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, paragraph 4, contains the following,
|
|
"Then throws length_error if size() >= npos - rlen."
|
|
</p>
|
|
|
|
<p>
|
|
Related to DR 83, this sentence should probably be removed.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<hr>
|
|
<a name="378"><h3>378. locale immutability and locale::operator=()</h3></a><p>
|
|
<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
|
|
<p>
|
|
I think there is a problem with 22.1.1, p6 which says that
|
|
</p>
|
|
<pre>
|
|
-6- An instance of locale is immutable; once a facet reference
|
|
is obtained from it, that reference remains usable as long
|
|
as the locale value itself exists.
|
|
</pre>
|
|
<p>
|
|
and 22.1.1.2, p4:
|
|
</p>
|
|
<pre>
|
|
const locale& operator=(const locale& other) throw();
|
|
|
|
-4- Effects: Creates a copy of other, replacing the current value.
|
|
</pre>
|
|
<p>
|
|
How can a reference to a facet obtained from a locale object remain
|
|
valid after an assignment that clearly must replace all the facets
|
|
in the locale object? Imagine a program such as this
|
|
</p>
|
|
<pre>
|
|
std::locale loc ("de_DE");
|
|
const std::ctype<char> &r0 = std::use_facet<std::ctype<char> >(loc);
|
|
loc = std::locale ("en_US");
|
|
const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(loc);
|
|
</pre>
|
|
<p>
|
|
Is r0 really supposed to be preserved and destroyed only when loc goes
|
|
out of scope?
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Suggest to replace 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>, p6 with
|
|
</p>
|
|
<pre>
|
|
-6- Unless assigned a new value, locale objects are immutable;
|
|
once a facet reference is obtained from it, that reference
|
|
remains usable as long as the locale object itself exists
|
|
or until the locale object is assigned the value of another,
|
|
distinct locale object.
|
|
</pre>
|
|
<hr>
|
|
<a name="379"><h3>379. nonsensical ctype::do_widen() requirement</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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
|
|
<p>
|
|
The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
|
|
</p>
|
|
<pre>
|
|
charT do_widen (char c) const;
|
|
|
|
-11- Effects: Applies the simplest reasonable transformation from
|
|
a char value or sequence of char values to the corresponding
|
|
charT value or values. The only characters for which unique
|
|
transformations are required are those in the basic source
|
|
character set (2.2). For any named ctype category with a
|
|
ctype<charT> facet ctw and valid ctype_base::mask value
|
|
M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
|
|
</pre>
|
|
<p>
|
|
Shouldn't the last sentence instead read
|
|
</p>
|
|
<pre>
|
|
For any named ctype category with a ctype<char> facet ctc
|
|
and valid ctype_base::mask value M
|
|
(ctc.is(M, c) || !is(M, do_widen(c))) is true.
|
|
</pre>
|
|
<p>
|
|
I.e., if the narrow character c is not a member of a class of
|
|
characters then neither is the widened form of c. (To paraphrase
|
|
footnote 224.)
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Replace the last sentence of 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>, p11 with the
|
|
following text:
|
|
</p>
|
|
<pre>
|
|
For any named ctype category with a ctype<char> facet ctc
|
|
and valid ctype_base::mask value M
|
|
(ctc.is(M, c) || !is(M, do_widen(c))) is true.
|
|
</pre>
|
|
<hr>
|
|
<a name="380"><h3>380. typos in codecvt tables 53 and 54</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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
|
|
<p>
|
|
Tables 53 and 54 in 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> are both titled "convert
|
|
result values," when surely "do_in/do_out result values" must have
|
|
been intended for Table 53 and "do_unshift result values" for Table
|
|
54.
|
|
</p>
|
|
<p>
|
|
Table 54, row 3 says that the meaning of partial is "more characters
|
|
needed to be supplied to complete termination." The function is not
|
|
supplied any characters, it is given a buffer which it fills with
|
|
characters or, more precisely, destination elements (i.e., an escape
|
|
sequence). So partial means that space for more than (to_limit - to)
|
|
destination elements was needed to terminate a sequence given the
|
|
value of state.
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Change the title of Table 53 to "do_in/do_out result values" and
|
|
the title of Table 54 to "do_unshift result values."
|
|
</p>
|
|
<p>
|
|
Change the text in Table 54, row 3, under the heading Meaning to
|
|
"space for more than (to_limit - to) destination elements was
|
|
needed to terminate a sequence given the value of state."
|
|
</p>
|
|
<hr>
|
|
<a name="381"><h3>381. detection of invalid mbstate_t in codecvt</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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
|
|
<p>
|
|
All but one codecvt member functions that take a state_type argument
|
|
list as one of their preconditions that the state_type argument have
|
|
a valid value. However, according to 22.2.1.5.2, p6,
|
|
codecvt::do_unshift() is the only codecvt member that is supposed to
|
|
return error if the state_type object is invalid.
|
|
</p>
|
|
|
|
<p>
|
|
It seems to me that the treatment of state_type by all codecvt member
|
|
functions should be the same and the current requirements should be
|
|
changed. Since the detection of invalid state_type values may be
|
|
difficult in general or computationally expensive in some specific
|
|
cases, I propose the following:
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
Add a new paragraph before 22.2.1.5.2, p5, and after the function
|
|
declaration below
|
|
</p>
|
|
<pre>
|
|
result do_unshift(stateT& state,
|
|
externT* to, externT* to_limit, externT*& to_next) const;
|
|
</pre>
|
|
<p>
|
|
as follows:
|
|
</p>
|
|
<pre>
|
|
Requires: (to <= to_end) well defined and true; state initialized,
|
|
if at the beginning of a sequence, or else equal to the result of
|
|
converting the preceding characters in the sequence.
|
|
</pre>
|
|
<p>
|
|
and change the text in Table 54, row 4, under the heading Meaning
|
|
from
|
|
</p>
|
|
<pre>
|
|
state has invalid value
|
|
</pre>
|
|
<p>
|
|
to
|
|
</p>
|
|
<pre>
|
|
an unspecified error has occurred
|
|
</pre>
|
|
<p>
|
|
The return value of error should allow implementers to detect and
|
|
report invalid state values but shouldn't require it, hence the
|
|
word "unspecified" in the new wording.
|
|
</p>
|
|
<hr>
|
|
<a name="382"><h3>382. codecvt do_in/out result</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#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 30 Aug 2002</p>
|
|
<p>
|
|
It seems that the descriptions of codecvt do_in() and do_out() leave
|
|
sufficient room for interpretation so that two implementations of
|
|
codecvt may not work correctly with the same filebuf. Specifically,
|
|
the following seems less than adequately specified:
|
|
</p>
|
|
|
|
<ol>
|
|
<li>
|
|
the conditions under which the functions terminate
|
|
</li>
|
|
<li>
|
|
precisely when the functions return ok
|
|
</li>
|
|
<li>
|
|
precisely when the functions return partial
|
|
</li>
|
|
<li>
|
|
the full set of conditions when the functions return error
|
|
</li>
|
|
</ol>
|
|
|
|
<ol>
|
|
<li>
|
|
22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2 says this about the effects of the
|
|
function: ...Stops if it encounters a character it cannot
|
|
convert... This assumes that there *is* a character to
|
|
convert. What happens when there is a sequence that doesn't form a
|
|
valid source character, such as an unassigned or invalid UNICODE
|
|
character, or a sequence that cannot possibly form a character
|
|
(e.g., the sequence "\xc0\xff" in UTF-8)?
|
|
</li>
|
|
<li>
|
|
Table 53 says that the function returns codecvt_base::ok
|
|
to indicate that the function(s) "completed the conversion."
|
|
Suppose that the source sequence is "\xc0\x80" in UTF-8,
|
|
with from pointing to '\xc0' and (from_end==from + 1).
|
|
It is not clear whether the return value should be ok
|
|
or partial (see below).
|
|
</li>
|
|
<li>
|
|
Table 53 says that the function returns codecvt_base::partial
|
|
if "not all source characters converted." With the from pointers
|
|
set up the same way as above, it is not clear whether the return
|
|
value should be partial or ok (see above).
|
|
</li>
|
|
<li>
|
|
Table 53, in the row describing the meaning of error mistakenly
|
|
refers to a "from_type" character, without the symbol from_type
|
|
having been defined. Most likely, the word "source" character
|
|
is intended, although that is not sufficient. The functions
|
|
may also fail when they encounter an invalid source sequence
|
|
that cannot possibly form a valid source character (e.g., as
|
|
explained in bullet 1 above).
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
Finally, the conditions described at the end of 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p4 don't seem to be possible:
|
|
</p>
|
|
<blockquote>
|
|
"A return value of partial, if (from_next == from_end),
|
|
indicates that either the destination sequence has not
|
|
absorbed all the available destination elements, or that
|
|
additional source elements are needed before another
|
|
destination element can be produced."
|
|
</blockquote>
|
|
<p>
|
|
If the value is partial, it's not clear to me that (from_next
|
|
==from_end) could ever hold if there isn't enough room
|
|
in the destination buffer. In order for (from_next==from_end) to
|
|
hold, all characters in that range must have been successfully
|
|
converted (according to 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2) and since there are no
|
|
further source characters to convert, no more room in the
|
|
destination buffer can be needed.
|
|
</p>
|
|
<p>
|
|
It's also not clear to me that (from_next==from_end) could ever
|
|
hold if additional source elements are needed to produce another
|
|
destination character (not element as incorrectly stated in the
|
|
text). partial is returned if "not all source characters have
|
|
been converted" according to Table 53, which also implies that
|
|
(from_next==from) does NOT hold.
|
|
</p>
|
|
<p>
|
|
Could it be that the intended qualifying condition was actually
|
|
(from_next != from_end), i.e., that the sentence was supposed
|
|
to read
|
|
</p>
|
|
<blockquote>
|
|
"A return value of partial, if (from_next != from_end),..."
|
|
</blockquote>
|
|
<p>
|
|
which would make perfect sense, since, as far as I understand it,
|
|
partial can only occur if (from_next != from_end)?
|
|
</p>
|
|
<p><b>Proposed resolution:</b></p>
|
|
<p>
|
|
To address these issues, I propose that paragraphs 2, 3, and 4
|
|
be rewritten as follows. The proposal incorporates the accepted
|
|
resolution of lwg issue 19.
|
|
</p>
|
|
<pre>
|
|
-2- Effects: Converts characters in the range of source elements
|
|
[from, from_end), placing the results in sequential positions
|
|
starting at destination to. Converts no more than (from_end­from)
|
|
source elements, and stores no more than (to_limit­to)
|
|
destination elements.
|
|
|
|
Stops if it encounters a sequence of source elements it cannot
|
|
convert to a valid destination character. It always leaves the
|
|
from_next and to_next pointers pointing one beyond the last
|
|
element successfully converted.
|
|
|
|
[Note: If returns noconv, internT and externT are the same type
|
|
and the converted sequence is identical to the input sequence
|
|
[from, from_next). to_next is set equal to to, the value of
|
|
state is unchanged, and there are no changes to the values in
|
|
[to, to_limit). --end note]
|
|
|
|
-3- Notes: Its operations on state are unspecified.
|
|
[Note: This argument can be used, for example, to maintain shift
|
|
state, to specify conversion options (such as count only), or to
|
|
identify a cache of seek offsets. --end note]
|
|
|
|
-4- Returns: An enumeration value, as summarized in Table 53:
|
|
|
|
Table 53 -- do_in/do_out result values
|
|
|
|
Value Meaning
|
|
+---------+----------------------------------------------------+
|
|
| ok | successfully completed the conversion of all |
|
|
| | complete characters in the source range |
|
|
+---------+----------------------------------------------------+
|
|
| partial | the characters in the source range would, after |
|
|
| | conversion, require space greater than that |
|
|
| | available in the destination range |
|
|
+---------+----------------------------------------------------+
|
|
| error | encountered either a sequence of elements in the |
|
|
| | source range forming a valid source character that |
|
|
| | could not be converted to a destination character, |
|
|
| | or a sequence of elements in the source range that |
|
|
| | could not possibly form a valid source character |
|
|
+---------+----------------------------------------------------+
|
|
| noconv | internT and externT are the same type, and input |
|
|
| | sequence is identical to converted sequence |
|
|
+---------+----------------------------------------------------+
|
|
|
|
A return value of partial, i.e., if (from_next != from_end),
|
|
indicates that either the destination sequence has not absorbed
|
|
all the available destination elements, or that additional
|
|
source elements are needed before another destination character
|
|
can be produced.
|
|
</pre>
|
|
<p>----- End of document -----</p>
|
|
</body>
|
|
</html>
|