1 |
20 |
jlechner |
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
|
2 |
|
|
<html><head><title>C++ Standard Library Defect Report List</title></head>
|
3 |
|
|
|
4 |
|
|
<body bgcolor="#ffffff" text="#000000">
|
5 |
|
|
<table>
|
6 |
|
|
<tbody><tr>
|
7 |
|
|
<td align="left">Doc. no.</td>
|
8 |
|
|
<td align="left">N1909=05-0169</td>
|
9 |
|
|
</tr>
|
10 |
|
|
<tr>
|
11 |
|
|
<td align="left">Date:</td>
|
12 |
|
|
<td align="left">2005-10-23</td>
|
13 |
|
|
</tr>
|
14 |
|
|
<tr>
|
15 |
|
|
<td align="left">Project:</td>
|
16 |
|
|
<td align="left">Programming Language C++</td>
|
17 |
|
|
</tr>
|
18 |
|
|
<tr>
|
19 |
|
|
<td align="left">Reply to:</td>
|
20 |
|
|
<td align="left">Howard Hinnant <howard.hinnant@gmail.com></td>
|
21 |
|
|
</tr>
|
22 |
|
|
</tbody></table>
|
23 |
|
|
<h1>C++ Standard Library Defect Report List (Revision R39)</h1>
|
24 |
|
|
<p>Reference ISO/IEC IS 14882:1998(E)</p>
|
25 |
|
|
<p>Also see:</p>
|
26 |
|
|
<ul>
|
27 |
|
|
<li>
|
28 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
|
29 |
|
|
<li>
|
30 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
|
31 |
|
|
<li>
|
32 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
|
33 |
|
|
<li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
|
34 |
|
|
<li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
|
35 |
|
|
</ul>
|
36 |
|
|
<p>This document contains only library issues which have been closed
|
37 |
|
|
by the Library Working Group (LWG) after being found to be defects
|
38 |
|
|
in the standard. That is, issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a>. See the
|
39 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects. See the
|
40 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> for active issues and more information. The
|
41 |
|
|
introductory material in that document also applies to this
|
42 |
|
|
document.</p>
|
43 |
|
|
<h2>Revision History</h2>
|
44 |
|
|
<ul>
|
45 |
|
|
<li>R39:
|
46 |
|
|
2005-10-14 post-Mont Tremblant mailing.
|
47 |
|
|
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
|
48 |
|
|
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
|
49 |
|
|
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#497">497</a> from Review to Ready.
|
50 |
|
|
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#514">514</a> from New to Open.
|
51 |
|
|
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#519">519</a> from New to Ready.
|
52 |
|
|
Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
|
53 |
|
|
Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
|
54 |
|
|
</li>
|
55 |
|
|
<li>R38:
|
56 |
|
|
2005-07-03 pre-Mont Tremblant mailing.
|
57 |
|
|
Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
|
58 |
|
|
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
|
59 |
|
|
</li>
|
60 |
|
|
<li>R37:
|
61 |
|
|
2005-06 mid-term mailing.
|
62 |
|
|
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>.
|
63 |
|
|
</li>
|
64 |
|
|
<li>R36:
|
65 |
|
|
2005-04 post-Lillehammer mailing. All issues in "ready" status except
|
66 |
|
|
for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
|
67 |
|
|
previously in "DR" status were moved to "WP".
|
68 |
|
|
</li>
|
69 |
|
|
<li>R35:
|
70 |
|
|
2005-03 pre-Lillehammer mailing.
|
71 |
|
|
</li>
|
72 |
|
|
<li>R34:
|
73 |
|
|
2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
|
74 |
|
|
</li>
|
75 |
|
|
<li>R33:
|
76 |
|
|
2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
|
77 |
|
|
</li>
|
78 |
|
|
<li>R32:
|
79 |
|
|
2004-09 pre-Redmond mailing: reflects new proposed resolutions and
|
80 |
|
|
new issues received after the 2004-07 mailing. Added
|
81 |
|
|
new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
|
82 |
|
|
</li>
|
83 |
|
|
<li>R31:
|
84 |
|
|
2004-07 mid-term mailing: reflects new proposed resolutions and
|
85 |
|
|
new issues received after the post-Sydney mailing. Added
|
86 |
|
|
new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>.
|
87 |
|
|
</li>
|
88 |
|
|
<li>R30:
|
89 |
|
|
Post-Sydney mailing: reflects decisions made at the Sydney meeting.
|
90 |
|
|
Voted all "Ready" issues from R29 into the working paper.
|
91 |
|
|
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>.
|
92 |
|
|
</li>
|
93 |
|
|
<li>R29:
|
94 |
|
|
Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
|
95 |
|
|
</li>
|
96 |
|
|
<li>R28:
|
97 |
|
|
Post-Kona mailing: reflects decisions made at the Kona meeting.
|
98 |
|
|
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
|
99 |
|
|
</li>
|
100 |
|
|
<li>R27:
|
101 |
|
|
Pre-Kona mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
|
102 |
|
|
</li>
|
103 |
|
|
<li>R26:
|
104 |
|
|
Post-Oxford mailing: reflects decisions made at the Oxford meeting.
|
105 |
|
|
All issues in Ready status were voted into DR status. All issues in
|
106 |
|
|
DR status were voted into WP status.
|
107 |
|
|
</li>
|
108 |
|
|
<li>R25:
|
109 |
|
|
Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
|
110 |
|
|
</li>
|
111 |
|
|
<li>R24:
|
112 |
|
|
Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
|
113 |
|
|
meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
|
114 |
|
|
moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
|
115 |
|
|
at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
|
116 |
|
|
concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
|
117 |
|
|
</li>
|
118 |
|
|
<li>R23:
|
119 |
|
|
Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>.
|
120 |
|
|
Moved issues in the TC to TC status.
|
121 |
|
|
</li>
|
122 |
|
|
<li>R22:
|
123 |
|
|
Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
|
124 |
|
|
</li>
|
125 |
|
|
<li>R21:
|
126 |
|
|
Pre-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
|
127 |
|
|
</li>
|
128 |
|
|
<li>R20:
|
129 |
|
|
Post-Redmond mailing; reflects actions taken in Redmond. Added
|
130 |
|
|
new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues
|
131 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence
|
132 |
|
|
not discussed at the meeting.
|
133 |
|
|
|
134 |
|
|
All Ready issues were moved to DR status, with the exception of issues
|
135 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
|
136 |
|
|
|
137 |
|
|
Noteworthy issues discussed at Redmond include
|
138 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>,
|
139 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
|
140 |
|
|
</li>
|
141 |
|
|
<li>R19:
|
142 |
|
|
Pre-Redmond mailing. Added new issues
|
143 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>.
|
144 |
|
|
</li>
|
145 |
|
|
<li>R18:
|
146 |
|
|
Post-Copenhagen mailing; reflects actions taken in Copenhagen.
|
147 |
|
|
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
|
148 |
|
|
new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
|
149 |
|
|
|
150 |
|
|
Changed status of issues
|
151 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>
|
152 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>
|
153 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>
|
154 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>
|
155 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>
|
156 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>
|
157 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
|
158 |
|
|
to DR.
|
159 |
|
|
|
160 |
|
|
Changed status of issues
|
161 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>
|
162 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>
|
163 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>
|
164 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>
|
165 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>
|
166 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>
|
167 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>
|
168 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>
|
169 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>
|
170 |
|
|
to Ready.
|
171 |
|
|
|
172 |
|
|
Closed issues
|
173 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
|
174 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
|
175 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
|
176 |
|
|
as NAD.
|
177 |
|
|
|
178 |
|
|
</li>
|
179 |
|
|
<li>R17:
|
180 |
|
|
Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
|
181 |
|
|
resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
|
182 |
|
|
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
|
183 |
|
|
</li>
|
184 |
|
|
<li>R16:
|
185 |
|
|
post-Toronto mailing; reflects actions taken in Toronto. Added new
|
186 |
|
|
issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>. Changed status of issues
|
187 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>,
|
188 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>,
|
189 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>,
|
190 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>,
|
191 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>,
|
192 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>,
|
193 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>,
|
194 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>,
|
195 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>,
|
196 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
|
197 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
|
198 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
|
199 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened
|
200 |
|
|
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
|
201 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
|
202 |
|
|
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
|
203 |
|
|
appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
|
204 |
|
|
the bug in enough places.
|
205 |
|
|
</li>
|
206 |
|
|
<li>R15:
|
207 |
|
|
pre-Toronto mailing. Added issues
|
208 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting
|
209 |
|
|
changes so that we pass Weblint tests.
|
210 |
|
|
</li>
|
211 |
|
|
<li>R14:
|
212 |
|
|
post-Tokyo II mailing; reflects committee actions taken in
|
213 |
|
|
Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
|
214 |
|
|
</li>
|
215 |
|
|
<li>R13:
|
216 |
|
|
pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
|
217 |
|
|
</li>
|
218 |
|
|
<li>R12:
|
219 |
|
|
pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
|
220 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
|
221 |
|
|
of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
|
222 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
|
223 |
|
|
</li>
|
224 |
|
|
<li>R11:
|
225 |
|
|
post-Kona mailing: Updated to reflect LWG and full committee actions
|
226 |
|
|
in Kona (99-0048/N1224). Note changed resolution of issues
|
227 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a>
|
228 |
|
|
to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
|
229 |
|
|
"closed" documents. Changed the proposed resolution of issue
|
230 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
|
231 |
|
|
of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
|
232 |
|
|
</li>
|
233 |
|
|
<li>R10:
|
234 |
|
|
pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
|
235 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
|
236 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
|
237 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
|
238 |
|
|
</li>
|
239 |
|
|
<li>R9:
|
240 |
|
|
pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
|
241 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
|
242 |
|
|
"closed" documents. (99-0030/N1206, 25 Aug 99)
|
243 |
|
|
</li>
|
244 |
|
|
<li>R8:
|
245 |
|
|
post-Dublin mailing. Updated to reflect LWG and full committee actions
|
246 |
|
|
in Dublin. (99-0016/N1193, 21 Apr 99)
|
247 |
|
|
</li>
|
248 |
|
|
<li>R7:
|
249 |
|
|
pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
|
250 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
|
251 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
|
252 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
|
253 |
|
|
</li>
|
254 |
|
|
<li>R6:
|
255 |
|
|
pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
|
256 |
|
|
and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
|
257 |
|
|
</li>
|
258 |
|
|
<li>R5:
|
259 |
|
|
update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
|
260 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare
|
261 |
|
|
for making list public. (30 Dec 98)
|
262 |
|
|
</li>
|
263 |
|
|
<li>R4:
|
264 |
|
|
post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
|
265 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
|
266 |
|
|
issues corrected. (22 Oct 98)
|
267 |
|
|
</li>
|
268 |
|
|
<li>R3:
|
269 |
|
|
post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
|
270 |
|
|
added, many issues updated to reflect LWG consensus (12 Oct 98)
|
271 |
|
|
</li>
|
272 |
|
|
<li>R2:
|
273 |
|
|
pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
|
274 |
|
|
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
|
275 |
|
|
</li>
|
276 |
|
|
<li>R1:
|
277 |
|
|
Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
|
278 |
|
|
format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
|
279 |
|
|
</li>
|
280 |
|
|
</ul>
|
281 |
|
|
<h2>Defect Reports</h2>
|
282 |
|
|
<hr>
|
283 |
|
|
<a name="1"><h3>1. C library linkage editing oversight</h3></a><p><b>Section:</b> 17.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 16 Nov 1997</p>
|
284 |
|
|
<p>The change specified in the proposed resolution below did not make
|
285 |
|
|
it into the Standard. This change was accepted in principle at the
|
286 |
|
|
London meeting, and the exact wording below was accepted at the
|
287 |
|
|
Morristown meeting.</p>
|
288 |
|
|
<p><b>Proposed resolution:</b></p>
|
289 |
|
|
<p>Change 17.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> paragraph 2
|
290 |
|
|
from:</p>
|
291 |
|
|
|
292 |
|
|
<blockquote>
|
293 |
|
|
<p>It is unspecified whether a name from the Standard C library
|
294 |
|
|
declared with external linkage has either extern "C" or
|
295 |
|
|
extern "C++" linkage.</p>
|
296 |
|
|
</blockquote>
|
297 |
|
|
|
298 |
|
|
<p>to:</p>
|
299 |
|
|
|
300 |
|
|
<blockquote>
|
301 |
|
|
<p>Whether a name from the Standard C library declared with external
|
302 |
|
|
linkage has extern "C" or extern "C++" linkage
|
303 |
|
|
is implementation defined. It is recommended that an implementation
|
304 |
|
|
use extern "C++" linkage for this purpose.</p>
|
305 |
|
|
</blockquote>
|
306 |
|
|
<hr>
|
307 |
|
|
<a name="3"><h3>3. Atexit registration during atexit() call is not described</h3></a><p><b>Section:</b> 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.start.term"> [lib.support.start.term]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 12 Dec 1997</p>
|
308 |
|
|
<p>We appear not to have covered all the possibilities of
|
309 |
|
|
exit processing with respect to
|
310 |
|
|
atexit registration. <br>
|
311 |
|
|
<br>
|
312 |
|
|
Example 1: (C and C++)</p>
|
313 |
|
|
|
314 |
|
|
<pre> #include <stdlib.h>
|
315 |
|
|
void f1() { }
|
316 |
|
|
void f2() { atexit(f1); }
|
317 |
|
|
|
318 |
|
|
int main()
|
319 |
|
|
{
|
320 |
|
|
atexit(f2); // the only use of f2
|
321 |
|
|
return 0; // for C compatibility
|
322 |
|
|
}</pre>
|
323 |
|
|
|
324 |
|
|
<p>At program exit, f2 gets called due to its registration in
|
325 |
|
|
main. Running f2 causes f1 to be newly registered during the exit
|
326 |
|
|
processing. Is this a valid program? If so, what are its
|
327 |
|
|
semantics?</p>
|
328 |
|
|
|
329 |
|
|
<p>
|
330 |
|
|
Interestingly, neither the C standard, nor the C++ draft standard nor
|
331 |
|
|
the forthcoming C9X Committee Draft says directly whether you can
|
332 |
|
|
register a function with atexit during exit processing.</p>
|
333 |
|
|
|
334 |
|
|
<p>
|
335 |
|
|
All 3 standards say that functions are run in reverse order of their
|
336 |
|
|
registration. Since f1 is registered last, it ought to be run first,
|
337 |
|
|
but by the time it is registered, it is too late to be first.</p>
|
338 |
|
|
|
339 |
|
|
<p>If the program is valid, the standards are self-contradictory about
|
340 |
|
|
its semantics.</p>
|
341 |
|
|
|
342 |
|
|
<p>Example 2: (C++ only)</p>
|
343 |
|
|
|
344 |
|
|
<pre>
|
345 |
|
|
void F() { static T t; } // type T has a destructor
|
346 |
|
|
|
347 |
|
|
int main()
|
348 |
|
|
{
|
349 |
|
|
atexit(F); // the only use of F
|
350 |
|
|
}
|
351 |
|
|
</pre>
|
352 |
|
|
|
353 |
|
|
<p>Function F registered with atexit has a local static variable t,
|
354 |
|
|
and F is called for the first time during exit processing. A local
|
355 |
|
|
static object is initialized the first time control flow passes
|
356 |
|
|
through its definition, and all static objects are destroyed during
|
357 |
|
|
exit processing. Is the code valid? If so, what are its semantics?</p>
|
358 |
|
|
|
359 |
|
|
<p>
|
360 |
|
|
Section 18.3 "Start and termination" says that if a function
|
361 |
|
|
F is registered with atexit before a static object t is initialized, F
|
362 |
|
|
will not be called until after t's destructor completes.</p>
|
363 |
|
|
|
364 |
|
|
<p>
|
365 |
|
|
In example 2, function F is registered with atexit before its local
|
366 |
|
|
static object O could possibly be initialized. On that basis, it must
|
367 |
|
|
not be called by exit processing until after O's destructor
|
368 |
|
|
completes. But the destructor cannot be run until after F is called,
|
369 |
|
|
since otherwise the object could not be constructed in the first
|
370 |
|
|
place.</p>
|
371 |
|
|
|
372 |
|
|
<p>If the program is valid, the standard is self-contradictory about
|
373 |
|
|
its semantics.</p>
|
374 |
|
|
|
375 |
|
|
<p>I plan to submit Example 1 as a public comment on the C9X CD, with
|
376 |
|
|
a recommendation that the results be undefined. (Alternative: make it
|
377 |
|
|
unspecified. I don't think it is worthwhile to specify the case where
|
378 |
|
|
f1 itself registers additional functions, each of which registers
|
379 |
|
|
still more functions.)</p>
|
380 |
|
|
|
381 |
|
|
<p>I think we should resolve the situation in the whatever way the C
|
382 |
|
|
committee decides. </p>
|
383 |
|
|
|
384 |
|
|
<p>For Example 2, I recommend we declare the results undefined.</p>
|
385 |
|
|
|
386 |
|
|
<p><i>[See reflector message lib-6500 for further discussion.]</i></p>
|
387 |
|
|
|
388 |
|
|
<p><b>Proposed resolution:</b></p>
|
389 |
|
|
<p>Change section 18.3/8 from:</p>
|
390 |
|
|
<blockquote>
|
391 |
|
|
First, objects with static storage duration are destroyed and
|
392 |
|
|
functions registered by calling atexit are called. Objects with
|
393 |
|
|
static storage duration are destroyed in the reverse order of the
|
394 |
|
|
completion of their constructor. (Automatic objects are not
|
395 |
|
|
destroyed as a result of calling exit().) Functions registered with
|
396 |
|
|
atexit are called in the reverse order of their registration. A
|
397 |
|
|
function registered with atexit before an object obj1 of static
|
398 |
|
|
storage duration is initialized will not be called until obj1's
|
399 |
|
|
destruction has completed. A function registered with atexit after
|
400 |
|
|
an object obj2 of static storage duration is initialized will be
|
401 |
|
|
called before obj2's destruction starts.
|
402 |
|
|
</blockquote>
|
403 |
|
|
<p>to:</p>
|
404 |
|
|
<blockquote>
|
405 |
|
|
First, objects with static storage duration are destroyed and
|
406 |
|
|
functions registered by calling atexit are called. Non-local objects
|
407 |
|
|
with static storage duration are destroyed in the reverse order of
|
408 |
|
|
the completion of their constructor. (Automatic objects are not
|
409 |
|
|
destroyed as a result of calling exit().) Functions registered with
|
410 |
|
|
atexit are called in the reverse order of their registration, except
|
411 |
|
|
that a function is called after any previously registered functions
|
412 |
|
|
that had already been called at the time it was registered. A
|
413 |
|
|
function registered with atexit before a non-local object obj1 of
|
414 |
|
|
static storage duration is initialized will not be called until
|
415 |
|
|
obj1's destruction has completed. A function registered with atexit
|
416 |
|
|
after a non-local object obj2 of static storage duration is
|
417 |
|
|
initialized will be called before obj2's destruction starts. A local
|
418 |
|
|
static object obj3 is destroyed at the same time it would be if a
|
419 |
|
|
function calling the obj3 destructor were registered with atexit at
|
420 |
|
|
the completion of the obj3 constructor.
|
421 |
|
|
</blockquote>
|
422 |
|
|
<p><b>Rationale:</b></p>
|
423 |
|
|
<p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
|
424 |
|
|
supporting to the proposed resolution.</p>
|
425 |
|
|
<hr>
|
426 |
|
|
<a name="5"><h3>5. String::compare specification questionable</h3></a><p><b>Section:</b> 21.3.6.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::compare"> [lib.string::compare]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Jack Reeves <b>Date:</b> 11 Dec 1997</p>
|
427 |
|
|
<p>At the very end of the basic_string class definition is the signature: int
|
428 |
|
|
compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
|
429 |
|
|
following text this is defined as: returns
|
430 |
|
|
basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
|
431 |
|
|
basic_string<charT,traits,Allocator>(s,n2); </p>
|
432 |
|
|
|
433 |
|
|
<p>Since the constructor basic_string(const charT* s, size_type n, const Allocator& a
|
434 |
|
|
= Allocator()) clearly requires that s != NULL and n < npos and further states that it
|
435 |
|
|
throws length_error if n == npos, it appears the compare() signature above should always
|
436 |
|
|
throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
|
437 |
|
|
null terminated character array. </p>
|
438 |
|
|
|
439 |
|
|
<p>This appears to be a typo since the obvious intent is to allow either the call above or
|
440 |
|
|
something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
|
441 |
|
|
|
442 |
|
|
<p>This would imply that what was really intended was two signatures int compare(size_type
|
443 |
|
|
pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
|
444 |
|
|
charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
|
445 |
|
|
<p><b>Proposed resolution:</b></p>
|
446 |
|
|
<p>Replace the compare signature in 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>
|
447 |
|
|
(at the very end of the basic_string synopsis) which reads:</p>
|
448 |
|
|
|
449 |
|
|
<blockquote>
|
450 |
|
|
<p><tt>int compare(size_type pos1, size_type n1,<br>
|
451 |
|
|
const charT* s,
|
452 |
|
|
size_type n2 = npos) const;</tt></p>
|
453 |
|
|
</blockquote>
|
454 |
|
|
|
455 |
|
|
<p>with:</p>
|
456 |
|
|
|
457 |
|
|
<blockquote>
|
458 |
|
|
<p><tt>int compare(size_type pos1, size_type n1,<br>
|
459 |
|
|
const charT* s) const;<br>
|
460 |
|
|
int compare(size_type pos1, size_type n1,<br>
|
461 |
|
|
const charT* s,
|
462 |
|
|
size_type n2) const;</tt></p>
|
463 |
|
|
</blockquote>
|
464 |
|
|
|
465 |
|
|
<p>Replace the portion of 21.3.6.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::compare"> [lib.string::compare]</a>
|
466 |
|
|
paragraphs 5 and 6 which read:</p>
|
467 |
|
|
|
468 |
|
|
<blockquote>
|
469 |
|
|
<p><tt>int compare(size_type pos, size_type n1,<br>
|
470 |
|
|
charT * s, size_type n2
|
471 |
|
|
= npos) const;<br>
|
472 |
|
|
</tt>Returns:<tt><br>
|
473 |
|
|
basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
|
474 |
|
|
|
475 |
|
|
basic_string<charT,traits,Allocator>( s, n2))</tt></p>
|
476 |
|
|
</blockquote>
|
477 |
|
|
|
478 |
|
|
<p>with:</p>
|
479 |
|
|
|
480 |
|
|
<blockquote>
|
481 |
|
|
<p><tt>int compare(size_type pos, size_type n1,<br>
|
482 |
|
|
const charT * s) const;<br>
|
483 |
|
|
</tt>Returns:<tt><br>
|
484 |
|
|
basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
|
485 |
|
|
|
486 |
|
|
basic_string<charT,traits,Allocator>( s ))<br>
|
487 |
|
|
<br>
|
488 |
|
|
int compare(size_type pos, size_type n1,<br>
|
489 |
|
|
const charT * s,
|
490 |
|
|
size_type n2) const;<br>
|
491 |
|
|
</tt>Returns:<tt><br>
|
492 |
|
|
basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br>
|
493 |
|
|
|
494 |
|
|
basic_string<charT,traits,Allocator>( s, n2))</tt></p>
|
495 |
|
|
</blockquote>
|
496 |
|
|
|
497 |
|
|
<p>Editors please note that in addition to splitting the signature, the third argument
|
498 |
|
|
becomes const, matching the existing synopsis.</p>
|
499 |
|
|
<p><b>Rationale:</b></p>
|
500 |
|
|
<p>While the LWG dislikes adding signatures, this is a clear defect in
|
501 |
|
|
the Standard which must be fixed. The same problem was also
|
502 |
|
|
identified in issues 7 (item 5) and 87.</p>
|
503 |
|
|
<hr>
|
504 |
|
|
<a name="7"><h3>7. String clause minor problems</h3></a><p><b>Section:</b> 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Dec 1997</p>
|
505 |
|
|
<p>(1) In 21.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, the description of template
|
506 |
|
|
<class InputIterator> insert(iterator, InputIterator,
|
507 |
|
|
InputIterator) makes no sense. It refers to a member function that
|
508 |
|
|
doesn't exist. It also talks about the return value of a void
|
509 |
|
|
function. </p>
|
510 |
|
|
|
511 |
|
|
<p>(2) Several versions of basic_string::replace don't appear in the
|
512 |
|
|
class synopsis. </p>
|
513 |
|
|
|
514 |
|
|
<p>(3) basic_string::push_back appears in the synopsis, but is never
|
515 |
|
|
described elsewhere. In the synopsis its argument is const charT,
|
516 |
|
|
which doesn't makes much sense; it should probably be charT, or
|
517 |
|
|
possible const charT&. </p>
|
518 |
|
|
|
519 |
|
|
<p>(4) basic_string::pop_back is missing. </p>
|
520 |
|
|
|
521 |
|
|
<p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
|
522 |
|
|
= npos) make no sense. First, it's const charT* in the synopsis and
|
523 |
|
|
charT* in the description. Second, given what it says in RETURNS,
|
524 |
|
|
leaving out the final argument will always result in an exception
|
525 |
|
|
getting thrown. This is paragraphs 5 and 6 of
|
526 |
|
|
21.3.6.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::compare"> [lib.string::compare]</a></p>
|
527 |
|
|
|
528 |
|
|
<p>(6) In table 37, in section 21.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>,
|
529 |
|
|
there's a note for X::move(s, p, n). It says "Copies correctly
|
530 |
|
|
even where p is in [s, s+n)". This is correct as far as it goes,
|
531 |
|
|
but it doesn't go far enough; it should also guarantee that the copy
|
532 |
|
|
is correct even where s in in [p, p+n). These are two orthogonal
|
533 |
|
|
guarantees, and neither one follows from the other. Both guarantees
|
534 |
|
|
are necessary if X::move is supposed to have the same sort of
|
535 |
|
|
semantics as memmove (which was clearly the intent), and both
|
536 |
|
|
guarantees are necessary if X::move is actually supposed to be
|
537 |
|
|
useful. </p>
|
538 |
|
|
<p><b>Proposed resolution:</b></p>
|
539 |
|
|
<p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
|
540 |
|
|
<br>
|
541 |
|
|
EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
|
542 |
|
|
<br>
|
543 |
|
|
ITEM 2: Not a defect; the Standard is clear.. There are ten versions of replace() in
|
544 |
|
|
the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
|
545 |
|
|
<br>
|
546 |
|
|
ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
|
547 |
|
|
[lib.basic.string]) from:</p>
|
548 |
|
|
|
549 |
|
|
<p> void push_back(const charT)<br>
|
550 |
|
|
<br>
|
551 |
|
|
to<br>
|
552 |
|
|
<br>
|
553 |
|
|
void push_back(charT)<br>
|
554 |
|
|
<br>
|
555 |
|
|
Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
|
556 |
|
|
<br>
|
557 |
|
|
void basic_string::push_back(charT c);<br>
|
558 |
|
|
EFFECTS: Equivalent to append(static_cast<size_type>(1), c);<br>
|
559 |
|
|
<br>
|
560 |
|
|
ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
|
561 |
|
|
<br>
|
562 |
|
|
ITEM 5: Duplicate; see issue 5 (and 87).<br>
|
563 |
|
|
<br>
|
564 |
|
|
ITEM 6: In table 37, Replace:<br>
|
565 |
|
|
<br>
|
566 |
|
|
"Copies correctly even where p is in [s, s+n)."<br>
|
567 |
|
|
<br>
|
568 |
|
|
with:<br>
|
569 |
|
|
<br>
|
570 |
|
|
"Copies correctly even where the ranges [p, p+n) and [s,
|
571 |
|
|
s+n) overlap."</p>
|
572 |
|
|
<hr>
|
573 |
|
|
<a name="8"><h3>8. Locale::global lacks guarantee</h3></a><p><b>Section:</b> 22.1.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 24 Dec 1997</p>
|
574 |
|
|
<p>It appears there's an important guarantee missing from clause
|
575 |
|
|
22. We're told that invoking locale::global(L) sets the C locale if L
|
576 |
|
|
has a name. However, we're not told whether or not invoking
|
577 |
|
|
setlocale(s) sets the global C++ locale. </p>
|
578 |
|
|
|
579 |
|
|
<p>The intent, I think, is that it should not, but I can't find any
|
580 |
|
|
such words anywhere. </p>
|
581 |
|
|
<p><b>Proposed resolution:</b></p>
|
582 |
|
|
<p>Add a sentence at the end of 22.1.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>,
|
583 |
|
|
paragraph 2: </p>
|
584 |
|
|
|
585 |
|
|
<blockquote>
|
586 |
|
|
<p>No library function other than <tt>locale::global()</tt> shall affect
|
587 |
|
|
the value returned by <tt>locale()</tt>. </p>
|
588 |
|
|
|
589 |
|
|
</blockquote>
|
590 |
|
|
<hr>
|
591 |
|
|
<a name="9"><h3>9. Operator new(0) calls should not yield the same pointer</h3></a><p><b>Section:</b> 18.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 4 Jan 1998</p>
|
592 |
|
|
<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
|
593 |
|
|
section 3.7.3.1 of CD2 seems to allow for the possibility that all
|
594 |
|
|
calls to operator new(0) yield the same pointer, an implementation
|
595 |
|
|
technique specifically prohibited by ARM 5.3.3.Was this prohibition
|
596 |
|
|
really lifted? Does the FDIS agree with CD2 in the regard? [Issues
|
597 |
|
|
list maintainer's note: the IS is the same.]</p>
|
598 |
|
|
<p><b>Proposed resolution:</b></p>
|
599 |
|
|
<p>Change the last paragraph of 3.7.3 from:</p>
|
600 |
|
|
<blockquote>
|
601 |
|
|
<p>Any allocation and/or deallocation functions defined in a C++ program shall
|
602 |
|
|
conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
|
603 |
|
|
</blockquote>
|
604 |
|
|
<p>to:</p>
|
605 |
|
|
<blockquote>
|
606 |
|
|
<p>Any allocation and/or deallocation functions defined in a C++ program,
|
607 |
|
|
including the default versions in the library, shall conform to the semantics
|
608 |
|
|
specified in 3.7.3.1 and 3.7.3.2.</p>
|
609 |
|
|
</blockquote>
|
610 |
|
|
<p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
|
611 |
|
|
<blockquote>
|
612 |
|
|
<p>If the size of the space requested is zero, the value returned shall not be
|
613 |
|
|
a null pointer value (4.10).</p>
|
614 |
|
|
</blockquote>
|
615 |
|
|
<p>to:</p>
|
616 |
|
|
<blockquote>
|
617 |
|
|
<p>Even if the size of the space requested is zero, the request can fail. If
|
618 |
|
|
the request succeeds, the value returned shall be a non-null pointer value
|
619 |
|
|
(4.10) p0 different from any previously returned value p1, unless that value
|
620 |
|
|
p1 was since passed to an operator delete.</p>
|
621 |
|
|
</blockquote>
|
622 |
|
|
<p>5.3.4/7 currently reads:</p>
|
623 |
|
|
<blockquote>
|
624 |
|
|
<p>When the value of the expression in a direct-new-declarator is zero, the
|
625 |
|
|
allocation function is called to allocate an array with no elements. The
|
626 |
|
|
pointer returned by the new-expression is non-null. [Note: If the library
|
627 |
|
|
allocation function is called, the pointer returned is distinct from the
|
628 |
|
|
pointer to any other object.]</p>
|
629 |
|
|
</blockquote>
|
630 |
|
|
<p>Retain the first sentence, and delete the remainder.</p>
|
631 |
|
|
<p>18.4.1 currently has no text. Add the following:</p>
|
632 |
|
|
<blockquote>
|
633 |
|
|
<p>Except where otherwise specified, the provisions of 3.7.3 apply to the
|
634 |
|
|
library versions of operator new and operator delete.</p>
|
635 |
|
|
</blockquote>
|
636 |
|
|
<p>To 18.4.1.3, add the following text:</p>
|
637 |
|
|
<blockquote>
|
638 |
|
|
<p>The provisions of 3.7.3 do not apply to these reserved placement forms of
|
639 |
|
|
operator new and operator delete.</p>
|
640 |
|
|
</blockquote>
|
641 |
|
|
<p><b>Rationale:</b></p>
|
642 |
|
|
<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
|
643 |
|
|
supporting to the proposed resolution.</p>
|
644 |
|
|
<hr>
|
645 |
|
|
<a name="11"><h3>11. Bitset minor problems</h3></a><p><b>Section:</b> 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p>
|
646 |
|
|
<p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is
|
647 |
|
|
not documented in 23.3.5.2. </p>
|
648 |
|
|
|
649 |
|
|
<p>(2) The class synopsis only gives a single signature for bitset<>::operator[],
|
650 |
|
|
reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
|
651 |
|
|
on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
|
652 |
|
|
|
653 |
|
|
<p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
|
654 |
|
|
trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
|
655 |
|
|
go in the Effects clause.</p>
|
656 |
|
|
<p><b>Proposed resolution:</b></p>
|
657 |
|
|
<p>ITEMS 1 AND 2:<br>
|
658 |
|
|
<br>
|
659 |
|
|
In the bitset synopsis (23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>),
|
660 |
|
|
replace the member function <br>
|
661 |
|
|
<br>
|
662 |
|
|
<tt> reference operator[](size_t pos);<br>
|
663 |
|
|
</tt><br>
|
664 |
|
|
with the two member functions<br>
|
665 |
|
|
<br>
|
666 |
|
|
<tt> bool operator[](size_t pos) const; <br>
|
667 |
|
|
reference operator[](size_t pos); <br>
|
668 |
|
|
</tt><br>
|
669 |
|
|
Add the following text at the end of 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>,
|
670 |
|
|
immediately after paragraph 45:</p>
|
671 |
|
|
|
672 |
|
|
<blockquote>
|
673 |
|
|
<p><tt>bool operator[](size_t pos) const;</tt><br>
|
674 |
|
|
Requires: pos is valid<br>
|
675 |
|
|
Throws: nothing<br>
|
676 |
|
|
Returns: <tt>test(pos)</tt><br>
|
677 |
|
|
<br>
|
678 |
|
|
<tt>bitset<N>::reference operator[](size_t pos);</tt> <br>
|
679 |
|
|
Requires: pos is valid<br>
|
680 |
|
|
Throws: nothing<br>
|
681 |
|
|
Returns: An object of type <tt>bitset<N>::reference</tt> such that <tt>(*this)[pos]
|
682 |
|
|
== this->test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this->set(pos,
|
683 |
|
|
val);</tt></p>
|
684 |
|
|
</blockquote>
|
685 |
|
|
<p><b>Rationale:</b></p>
|
686 |
|
|
<p>The LWG believes Item 3 is not a defect. "Formatted
|
687 |
|
|
input" implies the desired semantics. See 27.6.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a>.
|
688 |
|
|
</p>
|
689 |
|
|
<hr>
|
690 |
|
|
<a name="13"><h3>13. Eos refuses to die</h3></a><p><b>Section:</b> 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> William M. Miller <b>Date:</b> 3 Mar 1998</p>
|
691 |
|
|
<p>In 27.6.1.2.3, there is a reference to "eos", which is
|
692 |
|
|
the only one in the whole draft (at least using Acrobat search), so
|
693 |
|
|
it's undefined. </p>
|
694 |
|
|
<p><b>Proposed resolution:</b></p>
|
695 |
|
|
<p>In 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, replace "eos" with
|
696 |
|
|
"charT()"</p>
|
697 |
|
|
<hr>
|
698 |
|
|
<a name="14"><h3>14. Locale::combine should be const</h3></a><p><b>Section:</b> 22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
699 |
|
|
<p>locale::combine is the only member function of locale (other than constructors and
|
700 |
|
|
destructor) that is not const. There is no reason for it not to be const, and good reasons
|
701 |
|
|
why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
|
702 |
|
|
paragraph 6: "An instance of a locale is immutable." </p>
|
703 |
|
|
|
704 |
|
|
<p>History: this member function originally was a constructor. it happened that the
|
705 |
|
|
interface it specified had no corresponding language syntax, so it was changed to a member
|
706 |
|
|
function. As constructors are never const, there was no "const" in the interface
|
707 |
|
|
which was transformed into member "combine". It should have been added at that
|
708 |
|
|
time, but the omission was not noticed. </p>
|
709 |
|
|
<p><b>Proposed resolution:</b></p>
|
710 |
|
|
<p>In 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> and also in 22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, add
|
711 |
|
|
"const" to the declaration of member combine: </p>
|
712 |
|
|
<blockquote>
|
713 |
|
|
<pre>template <class Facet> locale combine(const locale& other) const; </pre>
|
714 |
|
|
</blockquote>
|
715 |
|
|
<hr>
|
716 |
|
|
<a name="15"><h3>15. Locale::name requirement inconsistent</h3></a><p><b>Section:</b> 22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
717 |
|
|
<p>locale::name() is described as returning a string that can be passed to a locale
|
718 |
|
|
constructor, but there is no matching constructor. </p>
|
719 |
|
|
<p><b>Proposed resolution:</b></p>
|
720 |
|
|
<p>In 22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>, paragraph 5, replace
|
721 |
|
|
"<tt>locale(name())</tt>" with
|
722 |
|
|
"<tt>locale(name().c_str())</tt>".
|
723 |
|
|
</p>
|
724 |
|
|
<hr>
|
725 |
|
|
<a name="16"><h3>16. Bad ctype_byname<char> decl</h3></a><p><b>Section:</b> 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
726 |
|
|
<p>The new virtual members ctype_byname<char>::do_widen and do_narrow did not get
|
727 |
|
|
edited in properly. Instead, the member do_widen appears four times, with wrong argument
|
728 |
|
|
lists. </p>
|
729 |
|
|
<p><b>Proposed resolution:</b></p>
|
730 |
|
|
<p>The correct declarations for the overloaded members
|
731 |
|
|
<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
|
732 |
|
|
from 22.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>.</p>
|
733 |
|
|
<hr>
|
734 |
|
|
<a name="17"><h3>17. Bad bool parsing</h3></a><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
735 |
|
|
<p>This section describes the process of parsing a text boolean value from the input
|
736 |
|
|
stream. It does not say it recognizes either of the sequences "true" or
|
737 |
|
|
"false" and returns the corresponding bool value; instead, it says it recognizes
|
738 |
|
|
only one of those sequences, and chooses which according to the received value of a
|
739 |
|
|
reference argument intended for returning the result, and reports an error if the other
|
740 |
|
|
sequence is found. (!) Furthermore, it claims to get the names from the ctype<>
|
741 |
|
|
facet rather than the numpunct<> facet, and it examines the "boolalpha"
|
742 |
|
|
flag wrongly; it doesn't define the value "loc"; and finally, it computes
|
743 |
|
|
wrongly whether to use numeric or "alpha" parsing.<br>
|
744 |
|
|
<br>
|
745 |
|
|
I believe the correct algorithm is "as if": </p>
|
746 |
|
|
|
747 |
|
|
<pre> // in, err, val, and str are arguments.
|
748 |
|
|
err = 0;
|
749 |
|
|
const numpunct<charT>& np = use_facet<numpunct<charT> >(str.getloc());
|
750 |
|
|
const string_type t = np.truename(), f = np.falsename();
|
751 |
|
|
bool tm = true, fm = true;
|
752 |
|
|
size_t pos = 0;
|
753 |
|
|
while (tm && pos < t.size() || fm && pos < f.size()) {
|
754 |
|
|
if (in == end) { err = str.eofbit; }
|
755 |
|
|
bool matched = false;
|
756 |
|
|
if (tm && pos < t.size()) {
|
757 |
|
|
if (!err && t[pos] == *in) matched = true;
|
758 |
|
|
else tm = false;
|
759 |
|
|
}
|
760 |
|
|
if (fm && pos < f.size()) {
|
761 |
|
|
if (!err && f[pos] == *in) matched = true;
|
762 |
|
|
else fm = false;
|
763 |
|
|
}
|
764 |
|
|
if (matched) { ++in; ++pos; }
|
765 |
|
|
if (pos > t.size()) tm = false;
|
766 |
|
|
if (pos > f.size()) fm = false;
|
767 |
|
|
}
|
768 |
|
|
if (tm == fm || pos == 0) { err |= str.failbit; }
|
769 |
|
|
else { val = tm; }
|
770 |
|
|
return in;</pre>
|
771 |
|
|
|
772 |
|
|
<p>Notice this works reasonably when the candidate strings are both empty, or equal, or
|
773 |
|
|
when one is a substring of the other. The proposed text below captures the logic of the
|
774 |
|
|
code above.</p>
|
775 |
|
|
<p><b>Proposed resolution:</b></p>
|
776 |
|
|
<p>In 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, in the first line of paragraph 14,
|
777 |
|
|
change "&&" to "&".</p>
|
778 |
|
|
|
779 |
|
|
<p>Then, replace paragraphs 15 and 16 as follows:</p>
|
780 |
|
|
|
781 |
|
|
<blockquote>
|
782 |
|
|
|
783 |
|
|
<p>Otherwise target sequences are determined "as if" by
|
784 |
|
|
calling the members <tt>falsename()</tt> and
|
785 |
|
|
<tt>truename()</tt> of the facet obtained by
|
786 |
|
|
<tt>use_facet<numpunct<charT> >(str.getloc())</tt>.
|
787 |
|
|
Successive characters in the range <tt>[in,end)</tt> (see
|
788 |
|
|
[lib.sequence.reqmts]) are obtained and matched against
|
789 |
|
|
corresponding positions in the target sequences only as necessary to
|
790 |
|
|
identify a unique match. The input iterator <tt>in</tt> is
|
791 |
|
|
compared to <tt>end</tt> only when necessary to obtain a
|
792 |
|
|
character. If and only if a target sequence is uniquely matched,
|
793 |
|
|
<tt>val</tt> is set to the corresponding value.</p>
|
794 |
|
|
|
795 |
|
|
</blockquote>
|
796 |
|
|
|
797 |
|
|
<blockquote>
|
798 |
|
|
<p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
|
799 |
|
|
successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
|
800 |
|
|
<tt>str.eofbit</tt> if, when seeking another character to match, it is found that
|
801 |
|
|
<tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
|
802 |
|
|
<tt>(str.failbit|str.eofbit)</tt>if
|
803 |
|
|
the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
|
804 |
|
|
<tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
|
805 |
|
|
<tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
|
806 |
|
|
<tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
|
807 |
|
|
<tt>true</tt>:"1"
|
808 |
|
|
and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
|
809 |
|
|
and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
|
810 |
|
|
<tt>err==str.failbit</tt>. --end example]</p>
|
811 |
|
|
</blockquote>
|
812 |
|
|
<hr>
|
813 |
|
|
<a name="18"><h3>18. Get(...bool&) omitted</h3></a><p><b>Section:</b> 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
814 |
|
|
<p>In the list of num_get<> non-virtual members on page 22-23, the member
|
815 |
|
|
that parses bool values was omitted from the list of definitions of non-virtual
|
816 |
|
|
members, though it is listed in the class definition and the corresponding
|
817 |
|
|
virtual is listed everywhere appropriate. </p>
|
818 |
|
|
<p><b>Proposed resolution:</b></p>
|
819 |
|
|
<p>Add at the beginning of 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>
|
820 |
|
|
another get member for bool&, copied from the entry in
|
821 |
|
|
22.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p>
|
822 |
|
|
<hr>
|
823 |
|
|
<a name="19"><h3>19. "Noconv" definition too vague</h3></a><p><b>Section:</b> 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
824 |
|
|
<p>
|
825 |
|
|
In the definitions of codecvt<>::do_out and do_in, they are
|
826 |
|
|
specified to return noconv if "no conversion is
|
827 |
|
|
needed". This definition is too vague, and does not say
|
828 |
|
|
normatively what is done with the buffers.
|
829 |
|
|
</p>
|
830 |
|
|
<p><b>Proposed resolution:</b></p>
|
831 |
|
|
<p>
|
832 |
|
|
Change the entry for noconv in the table under paragraph 4 in section
|
833 |
|
|
22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> to read:
|
834 |
|
|
</p>
|
835 |
|
|
<blockquote>
|
836 |
|
|
<p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
|
837 |
|
|
and input sequence is identical to converted sequence.</p>
|
838 |
|
|
</blockquote>
|
839 |
|
|
<p>Change the Note in paragraph 2 to normative text as follows:</p>
|
840 |
|
|
<blockquote>
|
841 |
|
|
<p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
|
842 |
|
|
same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
|
843 |
|
|
<tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
|
844 |
|
|
unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
|
845 |
|
|
</blockquote>
|
846 |
|
|
<hr>
|
847 |
|
|
<a name="20"><h3>20. Thousands_sep returns wrong type</h3></a><p><b>Section:</b> 22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
848 |
|
|
<p>The synopsis for numpunct<>::do_thousands_sep, and the
|
849 |
|
|
definition of numpunct<>::thousands_sep which calls it, specify
|
850 |
|
|
that it returns a value of type char_type. Here it is erroneously
|
851 |
|
|
described as returning a "string_type". </p>
|
852 |
|
|
<p><b>Proposed resolution:</b></p>
|
853 |
|
|
<p>In 22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>, above paragraph 2, change
|
854 |
|
|
"string_type" to "char_type". </p>
|
855 |
|
|
<hr>
|
856 |
|
|
<a name="21"><h3>21. Codecvt_byname<> instantiations</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
857 |
|
|
<p>In the second table in the section, captioned "Required
|
858 |
|
|
instantiations", the instantiations for codecvt_byname<>
|
859 |
|
|
have been omitted. These are necessary to allow users to construct a
|
860 |
|
|
locale by name from facets. </p>
|
861 |
|
|
<p><b>Proposed resolution:</b></p>
|
862 |
|
|
<p>Add in 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> to the table captioned
|
863 |
|
|
"Required instantiations", in the category "ctype"
|
864 |
|
|
the lines </p>
|
865 |
|
|
|
866 |
|
|
<blockquote>
|
867 |
|
|
<pre>codecvt_byname<char,char,mbstate_t>,
|
868 |
|
|
codecvt_byname<wchar_t,char,mbstate_t> </pre>
|
869 |
|
|
</blockquote>
|
870 |
|
|
<hr>
|
871 |
|
|
<a name="22"><h3>22. Member open vs. flags</h3></a><p><b>Section:</b> 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
872 |
|
|
<p>The description of basic_istream<>::open leaves unanswered questions about how it
|
873 |
|
|
responds to or changes flags in the error status for the stream. A strict reading
|
874 |
|
|
indicates that it ignores the bits and does not change them, which confuses users who do
|
875 |
|
|
not expect eofbit and failbit to remain set after a successful open. There are three
|
876 |
|
|
reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
|
877 |
|
|
and eofbit on call to open(). </p>
|
878 |
|
|
<p><b>Proposed resolution:</b></p>
|
879 |
|
|
<p>In 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> paragraph 3, <i>and</i> in 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> paragraph 3, under open() effects, add a footnote:
|
880 |
|
|
</p>
|
881 |
|
|
|
882 |
|
|
<blockquote>
|
883 |
|
|
<p>A successful open does not change the error state.</p>
|
884 |
|
|
</blockquote>
|
885 |
|
|
<p><b>Rationale:</b></p>
|
886 |
|
|
<p>This may seem surprising to some users, but it's just an instance
|
887 |
|
|
of a general rule: error flags are never cleared by the
|
888 |
|
|
implementation. The only way error flags are are ever cleared is if
|
889 |
|
|
the user explicitly clears them by hand.</p>
|
890 |
|
|
|
891 |
|
|
<p>The LWG believed that preserving this general rule was
|
892 |
|
|
important enough so that an exception shouldn't be made just for this
|
893 |
|
|
one case. The resolution of this issue clarifies what the LWG
|
894 |
|
|
believes to have been the original intent.</p>
|
895 |
|
|
|
896 |
|
|
<hr>
|
897 |
|
|
<a name="24"></a><h3><a name="24">24. "do_convert" doesn't exist</a></h3><p><b>Section:</b> 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
898 |
|
|
<p>The description of codecvt<>::do_out and do_in mentions a
|
899 |
|
|
symbol "do_convert" which is not defined in the
|
900 |
|
|
standard. This is a leftover from an edit, and should be "do_in
|
901 |
|
|
and do_out". </p>
|
902 |
|
|
<p><b>Proposed resolution:</b></p>
|
903 |
|
|
<p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, paragraph 3, change
|
904 |
|
|
"do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, change "do_convert()" to "do_in
|
905 |
|
|
or do_out". </p>
|
906 |
|
|
<hr>
|
907 |
|
|
<a name="25"><h3>25. String operator<< uses width() value wrong</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
908 |
|
|
<p>In the description of operator<< applied to strings, the standard says that uses
|
909 |
|
|
the smaller of os.width() and str.size(), to pad "as described in stage 3"
|
910 |
|
|
elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
|
911 |
|
|
<p><b>Proposed resolution:</b></p>
|
912 |
|
|
<p>Change 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 4 from:<br>
|
913 |
|
|
<br>
|
914 |
|
|
"... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
|
915 |
|
|
..."<br>
|
916 |
|
|
<br>
|
917 |
|
|
to: <br>
|
918 |
|
|
<br>
|
919 |
|
|
"... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
|
920 |
|
|
..."</p>
|
921 |
|
|
<hr>
|
922 |
|
|
<a name="26"><h3>26. Bad sentry example</h3></a><p><b>Section:</b> 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
923 |
|
|
<p>In paragraph 6, the code in the example: </p>
|
924 |
|
|
|
925 |
|
|
<pre> template <class charT, class traits = char_traits<charT> >
|
926 |
|
|
basic_istream<charT,traits>::sentry(
|
927 |
|
|
basic_istream<charT,traits>& is, bool noskipws = false) {
|
928 |
|
|
...
|
929 |
|
|
int_type c;
|
930 |
|
|
typedef ctype<charT> ctype_type;
|
931 |
|
|
const ctype_type& ctype = use_facet<ctype_type>(is.getloc());
|
932 |
|
|
while ((c = is.rdbuf()->snextc()) != traits::eof()) {
|
933 |
|
|
if (ctype.is(ctype.space,c)==0) {
|
934 |
|
|
is.rdbuf()->sputbackc (c);
|
935 |
|
|
break;
|
936 |
|
|
}
|
937 |
|
|
}
|
938 |
|
|
...
|
939 |
|
|
}</pre>
|
940 |
|
|
|
941 |
|
|
<p>fails to demonstrate correct use of the facilities described. In
|
942 |
|
|
particular, it fails to use traits operators, and specifies incorrect
|
943 |
|
|
semantics. (E.g. it specifies skipping over the first character in the
|
944 |
|
|
sequence without examining it.) </p>
|
945 |
|
|
<p><b>Proposed resolution:</b></p>
|
946 |
|
|
<p>Remove the example above from 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>
|
947 |
|
|
paragraph 6.</p>
|
948 |
|
|
<p><b>Rationale:</b></p>
|
949 |
|
|
<p>The originally proposed replacement code for the example was not
|
950 |
|
|
correct. The LWG tried in Kona and again in Tokyo to correct it
|
951 |
|
|
without success. In Tokyo, an implementor reported that actual working
|
952 |
|
|
code ran over one page in length and was quite complicated. The LWG
|
953 |
|
|
decided that it would be counter-productive to include such a lengthy
|
954 |
|
|
example, which might well still contain errors.</p>
|
955 |
|
|
<hr>
|
956 |
|
|
<a name="27"><h3>27. String::erase(range) yields wrong iterator</h3></a><p><b>Section:</b> 21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::erase"> [lib.string::erase]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
957 |
|
|
<p>The string::erase(iterator first, iterator last) is specified to return an element one
|
958 |
|
|
place beyond the next element after the last one erased. E.g. for the string
|
959 |
|
|
"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
|
960 |
|
|
while 'd' has not been erased. </p>
|
961 |
|
|
<p><b>Proposed resolution:</b></p>
|
962 |
|
|
<p>In 21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::erase"> [lib.string::erase]</a>, paragraph 10, change: </p>
|
963 |
|
|
|
964 |
|
|
<blockquote>
|
965 |
|
|
<p>Returns: an iterator which points to the element immediately following _last_ prior to
|
966 |
|
|
the element being erased. </p>
|
967 |
|
|
</blockquote>
|
968 |
|
|
|
969 |
|
|
<p>to read </p>
|
970 |
|
|
|
971 |
|
|
<blockquote>
|
972 |
|
|
<p>Returns: an iterator which points to the element pointed to by _last_ prior to the
|
973 |
|
|
other elements being erased. </p>
|
974 |
|
|
</blockquote>
|
975 |
|
|
<hr>
|
976 |
|
|
<a name="28"><h3>28. Ctype<char>is ambiguous</h3></a><p><b>Section:</b> 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
977 |
|
|
<p>The description of the vector form of ctype<char>::is can be interpreted to mean
|
978 |
|
|
something very different from what was intended. Paragraph 4 says </p>
|
979 |
|
|
|
980 |
|
|
<blockquote>
|
981 |
|
|
<p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
|
982 |
|
|
table()[(unsigned char)*p]. </p>
|
983 |
|
|
</blockquote>
|
984 |
|
|
|
985 |
|
|
<p>This is intended to copy the value indexed from table()[] into the place identified in
|
986 |
|
|
vec[]. </p>
|
987 |
|
|
<p><b>Proposed resolution:</b></p>
|
988 |
|
|
<p>Change 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>, paragraph 4, to read </p>
|
989 |
|
|
|
990 |
|
|
<blockquote>
|
991 |
|
|
<p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
|
992 |
|
|
the value table()[(unsigned char)*p]. </p>
|
993 |
|
|
</blockquote>
|
994 |
|
|
<hr>
|
995 |
|
|
<a name="29"><h3>29. Ios_base::init doesn't exist</h3></a><p><b>Section:</b> 27.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
996 |
|
|
<p>Sections 27.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> and 27.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> mention
|
997 |
|
|
a function ios_base::init, which is not defined. Probably they mean
|
998 |
|
|
basic_ios<>::init, defined in 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>,
|
999 |
|
|
paragraph 3. </p>
|
1000 |
|
|
<p><b>Proposed resolution:</b></p>
|
1001 |
|
|
<p>[R12: modified to include paragraph 5.]</p>
|
1002 |
|
|
|
1003 |
|
|
<p>In 27.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> paragraph 2 and 5, change </p>
|
1004 |
|
|
|
1005 |
|
|
<blockquote>
|
1006 |
|
|
<p>ios_base::init </p>
|
1007 |
|
|
</blockquote>
|
1008 |
|
|
|
1009 |
|
|
<p>to </p>
|
1010 |
|
|
|
1011 |
|
|
<blockquote>
|
1012 |
|
|
<p>basic_ios<char>::init </p>
|
1013 |
|
|
</blockquote>
|
1014 |
|
|
|
1015 |
|
|
<p>Also, make a similar change in 27.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> except it
|
1016 |
|
|
should read </p>
|
1017 |
|
|
|
1018 |
|
|
<blockquote>
|
1019 |
|
|
<p>basic_ios<wchar_t>::init </p>
|
1020 |
|
|
</blockquote>
|
1021 |
|
|
<hr>
|
1022 |
|
|
<a name="30"><h3>30. Wrong header for LC_*</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1023 |
|
|
<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>,
|
1024 |
|
|
where they are in fact defined elsewhere to appear in <clocale>. </p>
|
1025 |
|
|
<p><b>Proposed resolution:</b></p>
|
1026 |
|
|
<p>In 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 2, change
|
1027 |
|
|
"<cctype>" to read "<clocale>". </p>
|
1028 |
|
|
<hr>
|
1029 |
|
|
<a name="31"><h3>31. Immutable locale values</h3></a><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1030 |
|
|
<p>Paragraph 6, says "An instance of <tt>locale</tt> is
|
1031 |
|
|
<i>immutable</i>; once a facet reference is obtained from it,
|
1032 |
|
|
...". This has caused some confusion, because locale variables
|
1033 |
|
|
are manifestly assignable. </p>
|
1034 |
|
|
<p><b>Proposed resolution:</b></p>
|
1035 |
|
|
<p>In 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> replace paragraph 6</p>
|
1036 |
|
|
|
1037 |
|
|
<blockquote>
|
1038 |
|
|
<p>An instance of <tt>locale</tt> is immutable; once a facet
|
1039 |
|
|
reference is obtained from it, that reference remains usable as long
|
1040 |
|
|
as the locale value itself exists.</p>
|
1041 |
|
|
</blockquote>
|
1042 |
|
|
|
1043 |
|
|
<p>with</p>
|
1044 |
|
|
|
1045 |
|
|
<blockquote>
|
1046 |
|
|
<p>Once a facet reference is obtained from a locale object by
|
1047 |
|
|
calling use_facet<>, that reference remains usable, and the
|
1048 |
|
|
results from member functions of it may be cached and re-used, as
|
1049 |
|
|
long as some locale object refers to that facet.</p>
|
1050 |
|
|
</blockquote>
|
1051 |
|
|
<hr>
|
1052 |
|
|
<a name="32"><h3>32. Pbackfail description inconsistent</h3></a><p><b>Section:</b> 27.5.2.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1053 |
|
|
<p>The description of the required state before calling virtual member
|
1054 |
|
|
basic_streambuf<>::pbackfail requirements is inconsistent with the conditions
|
1055 |
|
|
described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
|
1056 |
|
|
Specifically, the latter says it calls pbackfail if: </p>
|
1057 |
|
|
|
1058 |
|
|
<p> traits::eq(c,gptr()[-1]) is false </p>
|
1059 |
|
|
|
1060 |
|
|
<p>where pbackfail claims to require: </p>
|
1061 |
|
|
|
1062 |
|
|
<p> traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
|
1063 |
|
|
|
1064 |
|
|
<p>It appears that the pbackfail description is wrong. </p>
|
1065 |
|
|
<p><b>Proposed resolution:</b></p>
|
1066 |
|
|
<p>In 27.5.2.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>, paragraph 1, change:</p>
|
1067 |
|
|
|
1068 |
|
|
<blockquote>
|
1069 |
|
|
<p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
|
1070 |
|
|
</blockquote>
|
1071 |
|
|
|
1072 |
|
|
<p>to </p>
|
1073 |
|
|
|
1074 |
|
|
<blockquote>
|
1075 |
|
|
<p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
|
1076 |
|
|
</p>
|
1077 |
|
|
</blockquote>
|
1078 |
|
|
<p><b>Rationale:</b></p>
|
1079 |
|
|
<p>Note deliberate reordering of arguments for clarity in addition to the correction of
|
1080 |
|
|
the argument value.</p>
|
1081 |
|
|
<hr>
|
1082 |
|
|
<a name="33"><h3>33. Codecvt<> mentions from_type</h3></a><p><b>Section:</b> 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1083 |
|
|
<p>In the table defining the results from do_out and do_in, the specification for the
|
1084 |
|
|
result <i>error</i> says </p>
|
1085 |
|
|
|
1086 |
|
|
<blockquote>
|
1087 |
|
|
<p>encountered a from_type character it could not convert </p>
|
1088 |
|
|
</blockquote>
|
1089 |
|
|
|
1090 |
|
|
<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
|
1091 |
|
|
an internT for do_out. </p>
|
1092 |
|
|
<p><b>Proposed resolution:</b></p>
|
1093 |
|
|
<p>In 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 4, replace the definition
|
1094 |
|
|
in the table for the case of _error_ with </p>
|
1095 |
|
|
|
1096 |
|
|
<blockquote>
|
1097 |
|
|
<p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
|
1098 |
|
|
</blockquote>
|
1099 |
|
|
<hr>
|
1100 |
|
|
<a name="34"><h3>34. True/falsename() not in ctype<></h3></a><p><b>Section:</b> 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1101 |
|
|
<p>In paragraph 19, Effects:, members truename() and falsename are used from facet
|
1102 |
|
|
ctype<charT>, but it has no such members. Note that this is also a problem in
|
1103 |
|
|
22.2.2.1.2, addressed in (4). </p>
|
1104 |
|
|
<p><b>Proposed resolution:</b></p>
|
1105 |
|
|
<p>In 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 19, in the Effects:
|
1106 |
|
|
clause for member put(...., bool), replace the initialization of the
|
1107 |
|
|
string_type value s as follows: </p>
|
1108 |
|
|
|
1109 |
|
|
<blockquote>
|
1110 |
|
|
<pre>const numpunct& np = use_facet<numpunct<charT> >(loc);
|
1111 |
|
|
string_type s = val ? np.truename() : np.falsename(); </pre>
|
1112 |
|
|
</blockquote>
|
1113 |
|
|
<hr>
|
1114 |
|
|
<a name="35"><h3>35. No manipulator unitbuf in synopsis</h3></a><p><b>Section:</b> 27.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1115 |
|
|
<p>In 27.4.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fmtflags.manip"> [lib.fmtflags.manip]</a>, we have a definition for a manipulator
|
1116 |
|
|
named "unitbuf". Unlike other manipulators, it's not listed
|
1117 |
|
|
in synopsis. Similarly for "nounitbuf". </p>
|
1118 |
|
|
<p><b>Proposed resolution:</b></p>
|
1119 |
|
|
<p>Add to the synopsis for <ios> in 27.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>, after
|
1120 |
|
|
the entry for "nouppercase", the prototypes: </p>
|
1121 |
|
|
|
1122 |
|
|
<blockquote>
|
1123 |
|
|
<pre>ios_base& unitbuf(ios_base& str);
|
1124 |
|
|
ios_base& nounitbuf(ios_base& str); </pre>
|
1125 |
|
|
</blockquote>
|
1126 |
|
|
<hr>
|
1127 |
|
|
<a name="36"><h3>36. Iword & pword storage lifetime omitted</h3></a><p><b>Section:</b> 27.4.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1128 |
|
|
<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
|
1129 |
|
|
specified badly, so that an implementation which only keeps the last value stored appears
|
1130 |
|
|
to conform. In particular, it says: </p>
|
1131 |
|
|
|
1132 |
|
|
<p>The reference returned may become invalid after another call to the object's iword
|
1133 |
|
|
member with a different index ... </p>
|
1134 |
|
|
|
1135 |
|
|
<p>This is not idle speculation; at least one implementation was done this way. </p>
|
1136 |
|
|
<p><b>Proposed resolution:</b></p>
|
1137 |
|
|
<p>Add in 27.4.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>, in both paragraph 2 and also in
|
1138 |
|
|
paragraph 4, replace the sentence: </p>
|
1139 |
|
|
|
1140 |
|
|
<blockquote>
|
1141 |
|
|
<p>The reference returned may become invalid after another call to the object's iword
|
1142 |
|
|
[pword] member with a different index, after a call to its copyfmt member, or when the
|
1143 |
|
|
object is destroyed. </p>
|
1144 |
|
|
</blockquote>
|
1145 |
|
|
|
1146 |
|
|
<p>with: </p>
|
1147 |
|
|
|
1148 |
|
|
<blockquote>
|
1149 |
|
|
<p>The reference returned is invalid after any other operations on the object. However,
|
1150 |
|
|
the value of the storage referred to is retained, so that until the next call to copyfmt,
|
1151 |
|
|
calling iword [pword] with the same index yields another reference to the same value. </p>
|
1152 |
|
|
</blockquote>
|
1153 |
|
|
|
1154 |
|
|
<p>substituting "iword" or "pword" as appropriate. </p>
|
1155 |
|
|
<hr>
|
1156 |
|
|
<a name="37"><h3>37. Leftover "global" reference</h3></a><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1157 |
|
|
<p>In the overview of locale semantics, paragraph 4, is the sentence </p>
|
1158 |
|
|
|
1159 |
|
|
<blockquote>
|
1160 |
|
|
<p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
|
1161 |
|
|
the standard exception bad_cast. </p>
|
1162 |
|
|
</blockquote>
|
1163 |
|
|
|
1164 |
|
|
<p>This is not supported by the definition of use_facet<>, and represents semantics
|
1165 |
|
|
from an old draft. </p>
|
1166 |
|
|
<p><b>Proposed resolution:</b></p>
|
1167 |
|
|
<p>In 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>, paragraph 4, delete the parenthesized
|
1168 |
|
|
expression </p>
|
1169 |
|
|
|
1170 |
|
|
<blockquote>
|
1171 |
|
|
<p>(or, failing that, in the global locale) </p>
|
1172 |
|
|
</blockquote>
|
1173 |
|
|
<hr>
|
1174 |
|
|
<a name="38"><h3>38. Facet definition incomplete</h3></a><p><b>Section:</b> 22.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1175 |
|
|
<p>It has been noticed by Esa Pulkkinen that the definition of
|
1176 |
|
|
"facet" is incomplete. In particular, a class derived from
|
1177 |
|
|
another facet, but which does not define a member <i>id</i>, cannot
|
1178 |
|
|
safely serve as the argument <i>F</i> to use_facet<F>(loc),
|
1179 |
|
|
because there is no guarantee that a reference to the facet instance
|
1180 |
|
|
stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
|
1181 |
|
|
<p><b>Proposed resolution:</b></p>
|
1182 |
|
|
<p>In the definition of std::use_facet<>(), replace the text in paragraph 1 which
|
1183 |
|
|
reads: </p>
|
1184 |
|
|
|
1185 |
|
|
<blockquote>
|
1186 |
|
|
<p>Get a reference to a facet of a locale. </p>
|
1187 |
|
|
</blockquote>
|
1188 |
|
|
|
1189 |
|
|
<p>with: </p>
|
1190 |
|
|
|
1191 |
|
|
<blockquote>
|
1192 |
|
|
<p>Requires: <tt>Facet</tt> is a facet class whose definition
|
1193 |
|
|
contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.facet"> [lib.locale.facet]</a>. </p>
|
1194 |
|
|
</blockquote>
|
1195 |
|
|
|
1196 |
|
|
<p><i>[
|
1197 |
|
|
Kona: strike as overspecification the text "(not inherits)"
|
1198 |
|
|
from the original resolution, which read "... whose definition
|
1199 |
|
|
contains (not inherits) the public static member
|
1200 |
|
|
<tt>id</tt>..."
|
1201 |
|
|
]</i></p>
|
1202 |
|
|
|
1203 |
|
|
<hr>
|
1204 |
|
|
<a name="39"><h3>39. istreambuf_iterator<>::operator++(int) definition garbled</h3></a><p><b>Section:</b> 24.5.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1205 |
|
|
<p>Following the definition of istreambuf_iterator<>::operator++(int) in paragraph
|
1206 |
|
|
3, the standard contains three lines of garbage text left over from a previous edit. </p>
|
1207 |
|
|
|
1208 |
|
|
<blockquote>
|
1209 |
|
|
<pre>istreambuf_iterator<charT,traits> tmp = *this;
|
1210 |
|
|
sbuf_->sbumpc();
|
1211 |
|
|
return(tmp); </pre>
|
1212 |
|
|
</blockquote>
|
1213 |
|
|
<p><b>Proposed resolution:</b></p>
|
1214 |
|
|
<p>In 24.5.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the
|
1215 |
|
|
end of paragraph 3. </p>
|
1216 |
|
|
<hr>
|
1217 |
|
|
<a name="40"><h3>40. Meaningless normative paragraph in examples</h3></a><p><b>Section:</b> 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1218 |
|
|
<p>Paragraph 3 of the locale examples is a description of part of an
|
1219 |
|
|
implementation technique that has lost its referent, and doesn't mean
|
1220 |
|
|
anything. </p>
|
1221 |
|
|
<p><b>Proposed resolution:</b></p>
|
1222 |
|
|
<p>Delete 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 3 which begins "This
|
1223 |
|
|
initialization/identification system depends...", or (at the
|
1224 |
|
|
editor's option) replace it with a place-holder to keep the paragraph
|
1225 |
|
|
numbering the same. </p>
|
1226 |
|
|
<hr>
|
1227 |
|
|
<a name="41"><h3>41. Ios_base needs clear(), exceptions()</h3></a><p><b>Section:</b> 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1228 |
|
|
<p>The description of ios_base::iword() and pword() in 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, say that if they fail, they "set badbit,
|
1229 |
|
|
which may throw an exception". However, ios_base offers no
|
1230 |
|
|
interface to set or to test badbit; those interfaces are defined in
|
1231 |
|
|
basic_ios<>. </p>
|
1232 |
|
|
<p><b>Proposed resolution:</b></p>
|
1233 |
|
|
<p>Change the description in 27.4.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> in
|
1234 |
|
|
paragraph 2, and also in paragraph 4, as follows. Replace</p>
|
1235 |
|
|
|
1236 |
|
|
<blockquote>
|
1237 |
|
|
<p>If the function fails it sets badbit, which may throw an exception.</p>
|
1238 |
|
|
</blockquote>
|
1239 |
|
|
|
1240 |
|
|
<p>with</p>
|
1241 |
|
|
|
1242 |
|
|
<blockquote>
|
1243 |
|
|
<p>If the function fails, and <tt>*this</tt> is a base sub-object of
|
1244 |
|
|
a <tt>basic_ios<></tt> object or sub-object, the effect is
|
1245 |
|
|
equivalent to calling <tt>basic_ios<>::setstate(badbit)</tt>
|
1246 |
|
|
on the derived object (which may throw <tt>failure</tt>).</p>
|
1247 |
|
|
</blockquote>
|
1248 |
|
|
|
1249 |
|
|
<p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
|
1250 |
|
|
setstate(badbit).]</i></p>
|
1251 |
|
|
|
1252 |
|
|
<hr>
|
1253 |
|
|
<a name="42"><h3>42. String ctors specify wrong default allocator</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1254 |
|
|
<p>The basic_string<> copy constructor: </p>
|
1255 |
|
|
|
1256 |
|
|
<pre>basic_string(const basic_string& str, size_type pos = 0,
|
1257 |
|
|
size_type n = npos, const Allocator& a = Allocator()); </pre>
|
1258 |
|
|
|
1259 |
|
|
<p>specifies an Allocator argument default value that is
|
1260 |
|
|
counter-intuitive. The natural choice for a the allocator to copy from
|
1261 |
|
|
is str.get_allocator(). Though this cannot be expressed in
|
1262 |
|
|
default-argument notation, overloading suffices. </p>
|
1263 |
|
|
|
1264 |
|
|
<p>Alternatively, the other containers in Clause 23 (deque, list,
|
1265 |
|
|
vector) do not have this form of constructor, so it is inconsistent,
|
1266 |
|
|
and an evident source of confusion, for basic_string<> to have
|
1267 |
|
|
it, so it might better be removed. </p>
|
1268 |
|
|
<p><b>Proposed resolution:</b></p>
|
1269 |
|
|
<p> In 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
|
1270 |
|
|
constructor as follows: </p>
|
1271 |
|
|
|
1272 |
|
|
<blockquote>
|
1273 |
|
|
<pre>basic_string(const basic_string& str);
|
1274 |
|
|
basic_string(const basic_string& str, size_type pos, size_type n = npos,
|
1275 |
|
|
const Allocator& a = Allocator());</pre>
|
1276 |
|
|
</blockquote>
|
1277 |
|
|
|
1278 |
|
|
<p>In 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
|
1279 |
|
|
as above. Add to paragraph 5, Effects:</p>
|
1280 |
|
|
|
1281 |
|
|
<blockquote>
|
1282 |
|
|
<p>In the first form, the Allocator value used is copied from
|
1283 |
|
|
<tt>str.get_allocator()</tt>.</p>
|
1284 |
|
|
</blockquote>
|
1285 |
|
|
<p><b>Rationale:</b></p>
|
1286 |
|
|
<p>The LWG believes the constructor is actually broken, rather than
|
1287 |
|
|
just an unfortunate design choice.</p>
|
1288 |
|
|
|
1289 |
|
|
<p>The LWG considered two other possible resolutions:</p>
|
1290 |
|
|
|
1291 |
|
|
<p>A. In 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
|
1292 |
|
|
constructor as follows:</p>
|
1293 |
|
|
|
1294 |
|
|
<blockquote>
|
1295 |
|
|
<pre>basic_string(const basic_string& str, size_type pos = 0,
|
1296 |
|
|
size_type n = npos);
|
1297 |
|
|
basic_string(const basic_string& str, size_type pos,
|
1298 |
|
|
size_type n, const Allocator& a); </pre>
|
1299 |
|
|
</blockquote>
|
1300 |
|
|
|
1301 |
|
|
<p>In 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
|
1302 |
|
|
as above. Add to paragraph 5, Effects: </p>
|
1303 |
|
|
|
1304 |
|
|
<blockquote>
|
1305 |
|
|
<p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
|
1306 |
|
|
value <tt>str.get_allocator()</tt>. </p>
|
1307 |
|
|
</blockquote>
|
1308 |
|
|
|
1309 |
|
|
<p>B. In 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, and also in 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace
|
1310 |
|
|
the declaration of the copy constructor as follows: </p>
|
1311 |
|
|
|
1312 |
|
|
<blockquote>
|
1313 |
|
|
<pre>basic_string(const basic_string& str, size_type pos = 0,
|
1314 |
|
|
size_type n = npos); </pre>
|
1315 |
|
|
</blockquote>
|
1316 |
|
|
|
1317 |
|
|
<p>The proposed resolution reflects the original intent of the LWG. It
|
1318 |
|
|
was also noted by Pete Becker that this fix "will cause
|
1319 |
|
|
a small amount of existing code to now work correctly."</p>
|
1320 |
|
|
|
1321 |
|
|
<p><i>[
|
1322 |
|
|
Kona: issue editing snafu fixed - the proposed resolution now correctly
|
1323 |
|
|
reflects the LWG consensus.
|
1324 |
|
|
]</i></p>
|
1325 |
|
|
<hr>
|
1326 |
|
|
<a name="44"><h3>44. Iostreams use operator== on int_type values</h3></a><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
1327 |
|
|
<p>Many of the specifications for iostreams specify that character
|
1328 |
|
|
values or their int_type equivalents are compared using operators ==
|
1329 |
|
|
or !=, though in other places traits::eq() or traits::eq_int_type is
|
1330 |
|
|
specified to be used throughout. This is an inconsistency; we should
|
1331 |
|
|
change uses of == and != to use the traits members instead. </p>
|
1332 |
|
|
<p><b>Proposed resolution:</b></p>
|
1333 |
|
|
|
1334 |
|
|
<p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
|
1335 |
|
|
|
1336 |
|
|
<p>List of changes to clause 27:</p>
|
1337 |
|
|
<ol>
|
1338 |
|
|
<li>
|
1339 |
|
|
In lib.basic.ios.members paragraph 13 (postcondition clause for
|
1340 |
|
|
'fill(cT)') change
|
1341 |
|
|
|
1342 |
|
|
<blockquote>
|
1343 |
|
|
fillch == fill()
|
1344 |
|
|
</blockquote>
|
1345 |
|
|
|
1346 |
|
|
to
|
1347 |
|
|
|
1348 |
|
|
<blockquote>
|
1349 |
|
|
traits::eq(fillch, fill())
|
1350 |
|
|
</blockquote>
|
1351 |
|
|
|
1352 |
|
|
|
1353 |
|
|
</li>
|
1354 |
|
|
<li>
|
1355 |
|
|
In lib.istream.unformatted paragraph 7 (effects clause for
|
1356 |
|
|
'get(cT,streamsize,cT)'), third bullet, change
|
1357 |
|
|
|
1358 |
|
|
<blockquote>
|
1359 |
|
|
c == delim for the next available input character c
|
1360 |
|
|
</blockquote>
|
1361 |
|
|
|
1362 |
|
|
to
|
1363 |
|
|
|
1364 |
|
|
<blockquote>
|
1365 |
|
|
traits::eq(c, delim) for the next available input character c
|
1366 |
|
|
</blockquote>
|
1367 |
|
|
|
1368 |
|
|
</li>
|
1369 |
|
|
<li>
|
1370 |
|
|
In lib.istream.unformatted paragraph 12 (effects clause for
|
1371 |
|
|
'get(basic_streambuf<cT,Tr>&,cT)'), third bullet, change
|
1372 |
|
|
|
1373 |
|
|
<blockquote>
|
1374 |
|
|
c == delim for the next available input character c
|
1375 |
|
|
</blockquote>
|
1376 |
|
|
|
1377 |
|
|
to
|
1378 |
|
|
|
1379 |
|
|
<blockquote>
|
1380 |
|
|
traits::eq(c, delim) for the next available input character c
|
1381 |
|
|
</blockquote>
|
1382 |
|
|
|
1383 |
|
|
</li>
|
1384 |
|
|
<li>
|
1385 |
|
|
In lib.istream.unformatted paragraph 17 (effects clause for
|
1386 |
|
|
'getline(cT,streamsize,cT)'), second bullet, change
|
1387 |
|
|
|
1388 |
|
|
<blockquote>
|
1389 |
|
|
c == delim for the next available input character c
|
1390 |
|
|
</blockquote>
|
1391 |
|
|
|
1392 |
|
|
to
|
1393 |
|
|
|
1394 |
|
|
<blockquote>
|
1395 |
|
|
traits::eq(c, delim) for the next available input character c
|
1396 |
|
|
</blockquote>
|
1397 |
|
|
|
1398 |
|
|
</li>
|
1399 |
|
|
<li>
|
1400 |
|
|
In lib.istream.unformatted paragraph 24 (effects clause for
|
1401 |
|
|
'ignore(int,int_type)'), second bullet, change
|
1402 |
|
|
|
1403 |
|
|
<blockquote>
|
1404 |
|
|
c == delim for the next available input character c
|
1405 |
|
|
</blockquote>
|
1406 |
|
|
|
1407 |
|
|
to
|
1408 |
|
|
|
1409 |
|
|
<blockquote>
|
1410 |
|
|
traits::eq_int_type(c, delim) for the next available input
|
1411 |
|
|
character c
|
1412 |
|
|
</blockquote>
|
1413 |
|
|
|
1414 |
|
|
</li>
|
1415 |
|
|
<li>
|
1416 |
|
|
In lib.istream.unformatted paragraph 25 (notes clause for
|
1417 |
|
|
'ignore(int,int_type)'), second bullet, change
|
1418 |
|
|
|
1419 |
|
|
<blockquote>
|
1420 |
|
|
The last condition will never occur if delim == traits::eof()
|
1421 |
|
|
</blockquote>
|
1422 |
|
|
|
1423 |
|
|
to
|
1424 |
|
|
|
1425 |
|
|
<blockquote>
|
1426 |
|
|
The last condition will never occur if
|
1427 |
|
|
traits::eq_int_type(delim, traits::eof()).
|
1428 |
|
|
</blockquote>
|
1429 |
|
|
|
1430 |
|
|
</li>
|
1431 |
|
|
<li>
|
1432 |
|
|
In lib.istream.sentry paragraph 6 (example implementation for the
|
1433 |
|
|
sentry constructor) change
|
1434 |
|
|
|
1435 |
|
|
<blockquote>
|
1436 |
|
|
while ((c = is.rdbuf()->snextc()) != traits::eof()) {
|
1437 |
|
|
</blockquote>
|
1438 |
|
|
|
1439 |
|
|
to
|
1440 |
|
|
|
1441 |
|
|
<blockquote>
|
1442 |
|
|
while (!traits::eq_int_type(c = is.rdbuf()->snextc(), traits::eof())) {
|
1443 |
|
|
</blockquote>
|
1444 |
|
|
|
1445 |
|
|
</li>
|
1446 |
|
|
</ol>
|
1447 |
|
|
|
1448 |
|
|
<p>List of changes to Chapter 21:</p>
|
1449 |
|
|
|
1450 |
|
|
<ol>
|
1451 |
|
|
<li>
|
1452 |
|
|
In lib.string::find paragraph 1 (effects clause for find()),
|
1453 |
|
|
second bullet, change
|
1454 |
|
|
|
1455 |
|
|
<blockquote>
|
1456 |
|
|
at(xpos+I) == str.at(I) for all elements ...
|
1457 |
|
|
</blockquote>
|
1458 |
|
|
|
1459 |
|
|
to
|
1460 |
|
|
|
1461 |
|
|
<blockquote>
|
1462 |
|
|
traits::eq(at(xpos+I), str.at(I)) for all elements ...
|
1463 |
|
|
</blockquote>
|
1464 |
|
|
|
1465 |
|
|
</li>
|
1466 |
|
|
<li>
|
1467 |
|
|
In lib.string::rfind paragraph 1 (effects clause for rfind()),
|
1468 |
|
|
second bullet, change
|
1469 |
|
|
|
1470 |
|
|
<blockquote>
|
1471 |
|
|
at(xpos+I) == str.at(I) for all elements ...
|
1472 |
|
|
</blockquote>
|
1473 |
|
|
|
1474 |
|
|
to
|
1475 |
|
|
|
1476 |
|
|
<blockquote>
|
1477 |
|
|
traits::eq(at(xpos+I), str.at(I)) for all elements ...
|
1478 |
|
|
</blockquote>
|
1479 |
|
|
|
1480 |
|
|
</li>
|
1481 |
|
|
<li>
|
1482 |
|
|
In lib.string::find.first.of paragraph 1 (effects clause for
|
1483 |
|
|
find_first_of()), second bullet, change
|
1484 |
|
|
|
1485 |
|
|
<blockquote>
|
1486 |
|
|
at(xpos+I) == str.at(I) for all elements ...
|
1487 |
|
|
</blockquote>
|
1488 |
|
|
|
1489 |
|
|
to
|
1490 |
|
|
|
1491 |
|
|
<blockquote>
|
1492 |
|
|
traits::eq(at(xpos+I), str.at(I)) for all elements ...
|
1493 |
|
|
</blockquote>
|
1494 |
|
|
|
1495 |
|
|
</li>
|
1496 |
|
|
<li>
|
1497 |
|
|
In lib.string::find.last.of paragraph 1 (effects clause for
|
1498 |
|
|
find_last_of()), second bullet, change
|
1499 |
|
|
|
1500 |
|
|
<blockquote>
|
1501 |
|
|
at(xpos+I) == str.at(I) for all elements ...
|
1502 |
|
|
</blockquote>
|
1503 |
|
|
|
1504 |
|
|
to
|
1505 |
|
|
|
1506 |
|
|
<blockquote>
|
1507 |
|
|
traits::eq(at(xpos+I), str.at(I)) for all elements ...
|
1508 |
|
|
</blockquote>
|
1509 |
|
|
|
1510 |
|
|
</li>
|
1511 |
|
|
<li>
|
1512 |
|
|
In lib.string::find.first.not.of paragraph 1 (effects clause for
|
1513 |
|
|
find_first_not_of()), second bullet, change
|
1514 |
|
|
|
1515 |
|
|
<blockquote>
|
1516 |
|
|
at(xpos+I) == str.at(I) for all elements ...
|
1517 |
|
|
</blockquote>
|
1518 |
|
|
|
1519 |
|
|
to
|
1520 |
|
|
|
1521 |
|
|
<blockquote>
|
1522 |
|
|
traits::eq(at(xpos+I), str.at(I)) for all elements ...
|
1523 |
|
|
</blockquote>
|
1524 |
|
|
</li>
|
1525 |
|
|
|
1526 |
|
|
<li>
|
1527 |
|
|
In lib.string::find.last.not.of paragraph 1 (effects clause for
|
1528 |
|
|
find_last_not_of()), second bullet, change
|
1529 |
|
|
|
1530 |
|
|
<blockquote>
|
1531 |
|
|
at(xpos+I) == str.at(I) for all elements ...
|
1532 |
|
|
</blockquote>
|
1533 |
|
|
|
1534 |
|
|
to
|
1535 |
|
|
|
1536 |
|
|
<blockquote>
|
1537 |
|
|
traits::eq(at(xpos+I), str.at(I)) for all elements ...
|
1538 |
|
|
</blockquote>
|
1539 |
|
|
</li>
|
1540 |
|
|
|
1541 |
|
|
<li>
|
1542 |
|
|
In lib.string.ios paragraph 5 (effects clause for getline()),
|
1543 |
|
|
second bullet, change
|
1544 |
|
|
|
1545 |
|
|
<blockquote>
|
1546 |
|
|
c == delim for the next available input character c
|
1547 |
|
|
</blockquote>
|
1548 |
|
|
|
1549 |
|
|
to
|
1550 |
|
|
|
1551 |
|
|
<blockquote>
|
1552 |
|
|
traits::eq(c, delim) for the next available input character c
|
1553 |
|
|
</blockquote>
|
1554 |
|
|
</li>
|
1555 |
|
|
|
1556 |
|
|
</ol>
|
1557 |
|
|
|
1558 |
|
|
<p>Notes:</p>
|
1559 |
|
|
<ul>
|
1560 |
|
|
<li>
|
1561 |
|
|
Fixing this issue highlights another sloppyness in
|
1562 |
|
|
lib.istream.unformatted paragraph 24: this clause mentions a "character"
|
1563 |
|
|
which is then compared to an 'int_type' (see item 5. in the list
|
1564 |
|
|
below). It is not clear whether this requires explicit words and
|
1565 |
|
|
if so what these words are supposed to be. A similar issue exists,
|
1566 |
|
|
BTW, for operator*() of istreambuf_iterator which returns the result
|
1567 |
|
|
of sgetc() as a character type (see lib.istreambuf.iterator::op*
|
1568 |
|
|
paragraph 1), and for operator++() of istreambuf_iterator which
|
1569 |
|
|
passes the result of sbumpc() to a constructor taking a char_type
|
1570 |
|
|
(see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
|
1571 |
|
|
assignment operator ostreambuf_iterator passes a char_type to a function
|
1572 |
|
|
taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
|
1573 |
|
|
</li>
|
1574 |
|
|
<li>
|
1575 |
|
|
It is inconsistent to use comparisons using the traits functions in
|
1576 |
|
|
Chapter 27 while not using them in Chapter 21, especially as some
|
1577 |
|
|
of the inconsistent uses actually involve streams (eg. getline() on
|
1578 |
|
|
streams). To avoid leaving this issue open still longer due to this
|
1579 |
|
|
inconsistency (it is open since 1998), a list of changes to Chapter
|
1580 |
|
|
21 is below.
|
1581 |
|
|
</li>
|
1582 |
|
|
<li>
|
1583 |
|
|
In Chapter 24 there are several places with statements like "the end
|
1584 |
|
|
of stream is reached (streambuf_type::sgetc() returns traits::eof())"
|
1585 |
|
|
(lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
|
1586 |
|
|
paragraph 5). It is unclear whether these should be clarified to use
|
1587 |
|
|
traits::eq_int_type() for detecting traits::eof().
|
1588 |
|
|
</li>
|
1589 |
|
|
</ul>
|
1590 |
|
|
|
1591 |
|
|
<hr>
|
1592 |
|
|
<a name="46"><h3>46. Minor Annex D errors</h3></a><p><b>Section:</b> D.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.str.strstreams"> [depr.str.strstreams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1 Jun 1998</p>
|
1593 |
|
|
<p>See lib-6522 and edit-814.</p>
|
1594 |
|
|
<p><b>Proposed resolution:</b></p>
|
1595 |
|
|
<p>Change D.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf"> [depr.strstreambuf]</a> (since streambuf is a typedef of
|
1596 |
|
|
basic_streambuf<char>) from:</p>
|
1597 |
|
|
|
1598 |
|
|
<pre> virtual streambuf<char>* setbuf(char* s, streamsize n);</pre>
|
1599 |
|
|
|
1600 |
|
|
<p>to:</p>
|
1601 |
|
|
|
1602 |
|
|
<pre> virtual streambuf* setbuf(char* s, streamsize n);</pre>
|
1603 |
|
|
|
1604 |
|
|
<p>In D.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstream"> [depr.strstream]</a> insert the semicolon now missing after
|
1605 |
|
|
int_type:</p>
|
1606 |
|
|
|
1607 |
|
|
<pre> namespace std {
|
1608 |
|
|
class strstream
|
1609 |
|
|
: public basic_iostream<char> {
|
1610 |
|
|
public:
|
1611 |
|
|
// Types
|
1612 |
|
|
typedef char char_type;
|
1613 |
|
|
typedef typename char_traits<char>::int_type int_type
|
1614 |
|
|
typedef typename char_traits<char>::pos_type pos_type;</pre>
|
1615 |
|
|
<hr>
|
1616 |
|
|
<a name="47"><h3>47. Imbue() and getloc() Returns clauses swapped</h3></a><p><b>Section:</b> 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
1617 |
|
|
<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
|
1618 |
|
|
section has two RETURNS clauses, and they make no sense as
|
1619 |
|
|
stated. They make perfect sense, though, if you swap them. Am I
|
1620 |
|
|
correct in thinking that paragraphs 2 and 4 just got mixed up by
|
1621 |
|
|
accident?</p>
|
1622 |
|
|
<p><b>Proposed resolution:</b></p>
|
1623 |
|
|
<p>In 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> swap paragraphs 2 and 4.</p>
|
1624 |
|
|
<hr>
|
1625 |
|
|
<a name="48"><h3>48. Use of non-existent exception constructor</h3></a><p><b>Section:</b> 27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
1626 |
|
|
<p>27.4.2.1.1, paragraph 2, says that class failure initializes the
|
1627 |
|
|
base class, exception, with exception(msg). Class exception (see
|
1628 |
|
|
18.6.1) has no such constructor.</p>
|
1629 |
|
|
<p><b>Proposed resolution:</b></p>
|
1630 |
|
|
<p>Replace 27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>, paragraph 2, with</p>
|
1631 |
|
|
|
1632 |
|
|
<blockquote>
|
1633 |
|
|
<p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
|
1634 |
|
|
</blockquote>
|
1635 |
|
|
<hr>
|
1636 |
|
|
<a name="49"><h3>49. Underspecification of ios_base::sync_with_stdio</h3></a><p><b>Section:</b> 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
1637 |
|
|
<p>Two problems</p>
|
1638 |
|
|
|
1639 |
|
|
<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
|
1640 |
|
|
returns. Does it return f, or does it return the previous
|
1641 |
|
|
synchronization state? My guess is the latter, but the standard
|
1642 |
|
|
doesn't say so.</p>
|
1643 |
|
|
|
1644 |
|
|
<p>(2) 27.4.2.4 doesn't say what it means for streams to be
|
1645 |
|
|
synchronized with stdio. Again, of course, I can make some
|
1646 |
|
|
guesses. (And I'm unhappy about the performance implications of those
|
1647 |
|
|
guesses, but that's another matter.)</p>
|
1648 |
|
|
<p><b>Proposed resolution:</b></p>
|
1649 |
|
|
<p>Change the following sentence in 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>
|
1650 |
|
|
returns clause from:</p>
|
1651 |
|
|
|
1652 |
|
|
<blockquote>
|
1653 |
|
|
<p><tt>true</tt> if the standard iostream objects (27.3) are
|
1654 |
|
|
synchronized and otherwise returns <tt>false</tt>.</p>
|
1655 |
|
|
</blockquote>
|
1656 |
|
|
|
1657 |
|
|
<p>to:</p>
|
1658 |
|
|
|
1659 |
|
|
<blockquote>
|
1660 |
|
|
<p><tt>true</tt> if the previous state of the standard iostream
|
1661 |
|
|
objects (27.3) was synchronized and otherwise returns
|
1662 |
|
|
<tt>false</tt>.</p>
|
1663 |
|
|
</blockquote>
|
1664 |
|
|
|
1665 |
|
|
<p>Add the following immediately after 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>,
|
1666 |
|
|
paragraph 2:</p>
|
1667 |
|
|
|
1668 |
|
|
<blockquote>
|
1669 |
|
|
<p>When a standard iostream object str is <i>synchronized</i> with a
|
1670 |
|
|
standard stdio stream f, the effect of inserting a character c by</p>
|
1671 |
|
|
<pre> fputc(f, c);
|
1672 |
|
|
</pre>
|
1673 |
|
|
|
1674 |
|
|
<p>is the same as the effect of</p>
|
1675 |
|
|
<pre> str.rdbuf()->sputc(c);
|
1676 |
|
|
</pre>
|
1677 |
|
|
|
1678 |
|
|
<p>for any sequence of characters; the effect of extracting a
|
1679 |
|
|
character c by</p>
|
1680 |
|
|
<pre> c = fgetc(f);
|
1681 |
|
|
</pre>
|
1682 |
|
|
|
1683 |
|
|
<p>is the same as the effect of:</p>
|
1684 |
|
|
<pre> c = str.rdbuf()->sbumpc(c);
|
1685 |
|
|
</pre>
|
1686 |
|
|
|
1687 |
|
|
<p>for any sequences of characters; and the effect of pushing
|
1688 |
|
|
back a character c by</p>
|
1689 |
|
|
<pre> ungetc(c, f);
|
1690 |
|
|
</pre>
|
1691 |
|
|
|
1692 |
|
|
<p>is the same as the effect of</p>
|
1693 |
|
|
<pre> str.rdbuf()->sputbackc(c);
|
1694 |
|
|
</pre>
|
1695 |
|
|
|
1696 |
|
|
<p>for any sequence of characters. [<i>Footnote</i>: This implies
|
1697 |
|
|
that operations on a standard iostream object can be mixed arbitrarily
|
1698 |
|
|
with operations on the corresponding stdio stream. In practical
|
1699 |
|
|
terms, synchronization usually means that a standard iostream object
|
1700 |
|
|
and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
|
1701 |
|
|
</blockquote>
|
1702 |
|
|
|
1703 |
|
|
<p><i>[pre-Copenhagen: PJP and Matt contributed the definition
|
1704 |
|
|
of "synchronization"]</i></p>
|
1705 |
|
|
|
1706 |
|
|
<p><i>[post-Copenhagen: proposed resolution was revised slightly:
|
1707 |
|
|
text was added in the non-normative footnote to say that operations
|
1708 |
|
|
on the two streams can be mixed arbitrarily.]</i></p>
|
1709 |
|
|
<hr>
|
1710 |
|
|
<a name="50"><h3>50. Copy constructor and assignment operator of ios_base</h3></a><p><b>Section:</b> 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
1711 |
|
|
<p>As written, ios_base has a copy constructor and an assignment
|
1712 |
|
|
operator. (Nothing in the standard says it doesn't have one, and all
|
1713 |
|
|
classes have copy constructors and assignment operators unless you
|
1714 |
|
|
take specific steps to avoid them.) However, nothing in 27.4.2 says
|
1715 |
|
|
what the copy constructor and assignment operator do. </p>
|
1716 |
|
|
|
1717 |
|
|
<p>My guess is that this was an oversight, that ios_base is, like
|
1718 |
|
|
basic_ios, not supposed to have a copy constructor or an assignment
|
1719 |
|
|
operator.</p>
|
1720 |
|
|
|
1721 |
|
|
<p>
|
1722 |
|
|
Jerry Schwarz comments: Yes, its an oversight, but in the opposite
|
1723 |
|
|
sense to what you're suggesting. At one point there was a definite
|
1724 |
|
|
intention that you could copy ios_base. It's an easy way to save the
|
1725 |
|
|
entire state of a stream for future use. As you note, to carry out
|
1726 |
|
|
that intention would have required a explicit description of the
|
1727 |
|
|
semantics (e.g. what happens to the iarray and parray stuff).
|
1728 |
|
|
</p>
|
1729 |
|
|
<p><b>Proposed resolution:</b></p>
|
1730 |
|
|
<p>In 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>, class ios_base, specify the copy
|
1731 |
|
|
constructor and operator= members as being private.</p>
|
1732 |
|
|
<p><b>Rationale:</b></p>
|
1733 |
|
|
<p>The LWG believes the difficulty of specifying correct semantics
|
1734 |
|
|
outweighs any benefit of allowing ios_base objects to be copyable.</p>
|
1735 |
|
|
<hr>
|
1736 |
|
|
<a name="51"><h3>51. Requirement to not invalidate iterators missing</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> David Vandevoorde <b>Date:</b> 23 Jun 1998</p>
|
1737 |
|
|
<p>The std::sort algorithm can in general only sort a given sequence
|
1738 |
|
|
by moving around values. The list<>::sort() member on the other
|
1739 |
|
|
hand could move around values or just update internal pointers. Either
|
1740 |
|
|
method can leave iterators into the list<> dereferencable, but
|
1741 |
|
|
they would point to different things. </p>
|
1742 |
|
|
|
1743 |
|
|
<p>Does the FDIS mandate anywhere which method should be used for
|
1744 |
|
|
list<>::sort()?</p>
|
1745 |
|
|
|
1746 |
|
|
<p>Matt Austern comments:</p>
|
1747 |
|
|
|
1748 |
|
|
<p>I think you've found an omission in the standard. </p>
|
1749 |
|
|
|
1750 |
|
|
<p>The library working group discussed this point, and there was
|
1751 |
|
|
supposed to be a general requirement saying that list, set, map,
|
1752 |
|
|
multiset, and multimap may not invalidate iterators, or change the
|
1753 |
|
|
values that iterators point to, except when an operation does it
|
1754 |
|
|
explicitly. So, for example, insert() doesn't invalidate any iterators
|
1755 |
|
|
and erase() and remove() only invalidate iterators pointing to the
|
1756 |
|
|
elements that are being erased. </p>
|
1757 |
|
|
|
1758 |
|
|
<p>I looked for that general requirement in the FDIS, and, while I
|
1759 |
|
|
found a limited form of it for the sorted associative containers, I
|
1760 |
|
|
didn't find it for list. It looks like it just got omitted. </p>
|
1761 |
|
|
|
1762 |
|
|
<p>The intention, though, is that list<>::sort does not
|
1763 |
|
|
invalidate any iterators and does not change the values that any
|
1764 |
|
|
iterator points to. There would be no reason to have the member
|
1765 |
|
|
function otherwise.</p>
|
1766 |
|
|
<p><b>Proposed resolution:</b></p>
|
1767 |
|
|
<p>Add a new paragraph at the end of 23.1:</p>
|
1768 |
|
|
|
1769 |
|
|
<blockquote>
|
1770 |
|
|
<p>Unless otherwise specified (either explicitly or by defining a function in terms of
|
1771 |
|
|
other functions), invoking a container member function or passing a container as an
|
1772 |
|
|
argument to a library function shall not invalidate iterators to, or change the values of,
|
1773 |
|
|
objects within that container. </p>
|
1774 |
|
|
</blockquote>
|
1775 |
|
|
<p><b>Rationale:</b></p>
|
1776 |
|
|
<p>This was US issue CD2-23-011; it was accepted in London but the
|
1777 |
|
|
change was not made due to an editing oversight. The wording in the
|
1778 |
|
|
proposed resolution below is somewhat updated from CD2-23-011,
|
1779 |
|
|
particularly the addition of the phrase "or change the values
|
1780 |
|
|
of"</p>
|
1781 |
|
|
<hr>
|
1782 |
|
|
<a name="52"><h3>52. Small I/O problems</h3></a><p><b>Section:</b> 27.4.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
|
1783 |
|
|
<p>First, 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, table 89. This is pretty obvious:
|
1784 |
|
|
it should be titled "basic_ios<>() effects", not
|
1785 |
|
|
"ios_base() effects". </p>
|
1786 |
|
|
|
1787 |
|
|
<p>[The second item is a duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#6">6</a> for
|
1788 |
|
|
resolution.]</p>
|
1789 |
|
|
|
1790 |
|
|
<p>Second, 27.4.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> table 88 . There are a couple
|
1791 |
|
|
different things wrong with it, some of which I've already discussed
|
1792 |
|
|
with Jerry, but the most obvious mechanical sort of error is that it
|
1793 |
|
|
uses expressions like P(i) and p(i), without ever defining what sort
|
1794 |
|
|
of thing "i" is.
|
1795 |
|
|
</p>
|
1796 |
|
|
|
1797 |
|
|
<p>(The other problem is that it requires support for streampos
|
1798 |
|
|
arithmetic. This is impossible on some systems, i.e. ones where file
|
1799 |
|
|
position is a complicated structure rather than just a number. Jerry
|
1800 |
|
|
tells me that the intention was to require syntactic support for
|
1801 |
|
|
streampos arithmetic, but that it wasn't actually supposed to do
|
1802 |
|
|
anything meaningful except on platforms, like Unix, where genuine
|
1803 |
|
|
arithmetic is possible.) </p>
|
1804 |
|
|
<p><b>Proposed resolution:</b></p>
|
1805 |
|
|
<p>Change 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> table 89 title from
|
1806 |
|
|
"ios_base() effects" to "basic_ios<>()
|
1807 |
|
|
effects". </p>
|
1808 |
|
|
<hr>
|
1809 |
|
|
<a name="53"><h3>53. Basic_ios destructor unspecified</h3></a><p><b>Section:</b> 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
|
1810 |
|
|
<p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
|
1811 |
|
|
The important question is whether basic_ios::~basic_ios() destroys
|
1812 |
|
|
rdbuf().</p>
|
1813 |
|
|
<p><b>Proposed resolution:</b></p>
|
1814 |
|
|
<p>Add after 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> paragraph 2:</p>
|
1815 |
|
|
|
1816 |
|
|
<blockquote>
|
1817 |
|
|
<p><tt>virtual ~basic_ios();</tt></p>
|
1818 |
|
|
<p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
|
1819 |
|
|
</blockquote>
|
1820 |
|
|
<p><b>Rationale:</b></p>
|
1821 |
|
|
<p>The LWG reviewed the additional question of whether or not
|
1822 |
|
|
<tt>rdbuf(0)</tt> may set <tt>badbit</tt>. The answer is
|
1823 |
|
|
clearly yes; it may be set via <tt>clear()</tt>. See 27.4.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>, paragraph 6. This issue was reviewed at length
|
1824 |
|
|
by the LWG, which removed from the original proposed resolution a
|
1825 |
|
|
footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
|
1826 |
|
|
<tt>badbit</tt>".</p>
|
1827 |
|
|
<hr>
|
1828 |
|
|
<a name="54"><h3>54. Basic_streambuf's destructor</h3></a><p><b>Section:</b> 27.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Jun 1998</p>
|
1829 |
|
|
<p>The class synopsis for basic_streambuf shows a (virtual)
|
1830 |
|
|
destructor, but the standard doesn't say what that destructor does. My
|
1831 |
|
|
assumption is that it does nothing, but the standard should say so
|
1832 |
|
|
explicitly. </p>
|
1833 |
|
|
<p><b>Proposed resolution:</b></p>
|
1834 |
|
|
<p>Add after 27.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> paragraph 2:</p>
|
1835 |
|
|
|
1836 |
|
|
<blockquote>
|
1837 |
|
|
<p><tt>virtual ~basic_streambuf();</tt></p>
|
1838 |
|
|
<p><b>Effects</b>: None.</p>
|
1839 |
|
|
</blockquote>
|
1840 |
|
|
<hr>
|
1841 |
|
|
<a name="55"><h3>55. Invalid stream position is undefined</h3></a><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 26 Jun 1998</p>
|
1842 |
|
|
<p>Several member functions in clause 27 are defined in certain
|
1843 |
|
|
circumstances to return an "invalid stream position", a term
|
1844 |
|
|
that is defined nowhere in the standard. Two places (27.5.2.4.2,
|
1845 |
|
|
paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
|
1846 |
|
|
a definition in _lib.iostreams.definitions_, a nonexistent
|
1847 |
|
|
section. </p>
|
1848 |
|
|
|
1849 |
|
|
<p>I suspect that the invalid stream position is just supposed to be
|
1850 |
|
|
pos_type(-1). Probably best to say explicitly in (for example)
|
1851 |
|
|
27.5.2.4.2 that the return value is pos_type(-1), rather than to use
|
1852 |
|
|
the term "invalid stream position", define that term
|
1853 |
|
|
somewhere, and then put in a cross-reference. </p>
|
1854 |
|
|
|
1855 |
|
|
<p>The phrase "invalid stream position" appears ten times in
|
1856 |
|
|
the C++ Standard. In seven places it refers to a return value, and it
|
1857 |
|
|
should be changed. In three places it refers to an argument, and it
|
1858 |
|
|
should not be changed. Here are the three places where "invalid
|
1859 |
|
|
stream position" should not be changed:</p>
|
1860 |
|
|
|
1861 |
|
|
<blockquote>
|
1862 |
|
|
<p>27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 14<br>
|
1863 |
|
|
27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 14<br>
|
1864 |
|
|
D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 17
|
1865 |
|
|
</p>
|
1866 |
|
|
</blockquote>
|
1867 |
|
|
<p><b>Proposed resolution:</b></p>
|
1868 |
|
|
<p>In 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 4, change "Returns an
|
1869 |
|
|
object of class pos_type that stores an invalid stream position
|
1870 |
|
|
(_lib.iostreams.definitions_)" to "Returns
|
1871 |
|
|
<tt>pos_type(off_type(-1))</tt>".
|
1872 |
|
|
</p>
|
1873 |
|
|
|
1874 |
|
|
<p>In 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 6, change "Returns
|
1875 |
|
|
an object of class pos_type that stores an invalid stream
|
1876 |
|
|
position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
|
1877 |
|
|
|
1878 |
|
|
<p>In 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 13, change "the object
|
1879 |
|
|
stores an invalid stream position" to "the return value is
|
1880 |
|
|
<tt>pos_type(off_type(-1))</tt>". </p>
|
1881 |
|
|
|
1882 |
|
|
<p>In 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 13, change "returns an
|
1883 |
|
|
invalid stream position (27.4.3)" to "returns
|
1884 |
|
|
<tt>pos_type(off_type(-1))</tt>" </p>
|
1885 |
|
|
|
1886 |
|
|
<p>In 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 15, change "Otherwise
|
1887 |
|
|
returns an invalid stream position (_lib.iostreams.definitions_)"
|
1888 |
|
|
to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
|
1889 |
|
|
</p>
|
1890 |
|
|
|
1891 |
|
|
<p>In D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 15, change "the object
|
1892 |
|
|
stores an invalid stream position" to "the return value is
|
1893 |
|
|
<tt>pos_type(off_type(-1))</tt>" </p>
|
1894 |
|
|
|
1895 |
|
|
<p>In D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 18, change "the object
|
1896 |
|
|
stores an invalid stream position" to "the return value is
|
1897 |
|
|
<tt>pos_type(off_type(-1))</tt>"</p>
|
1898 |
|
|
<hr>
|
1899 |
|
|
<a name="56"><h3>56. Showmanyc's return type</h3></a><p><b>Section:</b> 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 29 Jun 1998</p>
|
1900 |
|
|
<p>The class summary for basic_streambuf<>, in 27.5.2, says that
|
1901 |
|
|
showmanyc has return type int. However, 27.5.2.4.3 says that its
|
1902 |
|
|
return type is streamsize. </p>
|
1903 |
|
|
<p><b>Proposed resolution:</b></p>
|
1904 |
|
|
<p>Change <tt>showmanyc</tt>'s return type in the
|
1905 |
|
|
27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> class summary to <tt>streamsize</tt>.</p>
|
1906 |
|
|
<hr>
|
1907 |
|
|
<a name="57"><h3>57. Mistake in char_traits</h3></a><p><b>Section:</b> 21.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1 Jul 1998</p>
|
1908 |
|
|
<p>21.1.3.2, paragraph 3, says "The types streampos and
|
1909 |
|
|
wstreampos may be different if the implementation supports no shift
|
1910 |
|
|
encoding in narrow-oriented iostreams but supports one or more shift
|
1911 |
|
|
encodings in wide-oriented streams". </p>
|
1912 |
|
|
|
1913 |
|
|
<p>That's wrong: the two are the same type. The <iosfwd> summary
|
1914 |
|
|
in 27.2 says that streampos and wstreampos are, respectively, synonyms
|
1915 |
|
|
for fpos<char_traits<char>::state_type> and
|
1916 |
|
|
fpos<char_traits<wchar_t>::state_type>, and, flipping back
|
1917 |
|
|
to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
|
1918 |
|
|
char_traits<char>::state_type and
|
1919 |
|
|
char_traits<wchar_t>::state_type must both be mbstate_t. </p>
|
1920 |
|
|
<p><b>Proposed resolution:</b></p>
|
1921 |
|
|
<p>Remove the sentence in 21.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> paragraph 3 which
|
1922 |
|
|
begins "The types streampos and wstreampos may be
|
1923 |
|
|
different..." . </p>
|
1924 |
|
|
<hr>
|
1925 |
|
|
<a name="59"><h3>59. Ambiguity in specification of gbump</h3></a><p><b>Section:</b> 27.5.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 28 Jul 1998</p>
|
1926 |
|
|
<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
|
1927 |
|
|
next pointer for the input sequence by n." </p>
|
1928 |
|
|
|
1929 |
|
|
<p>The straightforward interpretation is that it is just gptr() +=
|
1930 |
|
|
n. An alternative interpretation, though, is that it behaves as if it
|
1931 |
|
|
calls sbumpc n times. (The issue, of course, is whether it might ever
|
1932 |
|
|
call underflow.) There is a similar ambiguity in the case of
|
1933 |
|
|
pbump. </p>
|
1934 |
|
|
|
1935 |
|
|
<p>(The "classic" AT&T implementation used the
|
1936 |
|
|
former interpretation.)</p>
|
1937 |
|
|
<p><b>Proposed resolution:</b></p>
|
1938 |
|
|
<p>Change 27.5.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> paragraph 4 gbump effects from:</p>
|
1939 |
|
|
|
1940 |
|
|
<blockquote>
|
1941 |
|
|
<p>Effects: Advances the next pointer for the input sequence by n.</p>
|
1942 |
|
|
</blockquote>
|
1943 |
|
|
|
1944 |
|
|
<p>to:</p>
|
1945 |
|
|
|
1946 |
|
|
<blockquote>
|
1947 |
|
|
<p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
|
1948 |
|
|
</blockquote>
|
1949 |
|
|
|
1950 |
|
|
<p>Make the same change to 27.5.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.put.area"> [lib.streambuf.put.area]</a> paragraph 4 pbump
|
1951 |
|
|
effects.</p>
|
1952 |
|
|
<hr>
|
1953 |
|
|
<a name="60"><h3>60. What is a formatted input function?</h3></a><p><b>Section:</b> 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 3 Aug 1998</p>
|
1954 |
|
|
<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
|
1955 |
|
|
formatted input functions. Some of the functions defined in section
|
1956 |
|
|
27.6.1.2 explicitly say that those requirements apply ("Behaves
|
1957 |
|
|
like a formatted input member (as described in 27.6.1.2.1)"), but
|
1958 |
|
|
others don't. The question: is 27.6.1.2.1 supposed to apply to
|
1959 |
|
|
everything in 27.6.1.2, or only to those member functions that
|
1960 |
|
|
explicitly say "behaves like a formatted input member"? Or
|
1961 |
|
|
to put it differently: are we to assume that everything that appears
|
1962 |
|
|
in a section called "Formatted input functions" really is a
|
1963 |
|
|
formatted input function? I assume that 27.6.1.2.1 is intended to
|
1964 |
|
|
apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
|
1965 |
|
|
is not intended to apply to extractors like </p>
|
1966 |
|
|
|
1967 |
|
|
<pre> basic_istream& operator>>(basic_istream& (*pf)(basic_istream&));</pre>
|
1968 |
|
|
|
1969 |
|
|
<p>and </p>
|
1970 |
|
|
|
1971 |
|
|
<pre> basic_istream& operator>>(basic_streammbuf*);</pre>
|
1972 |
|
|
|
1973 |
|
|
<p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
|
1974 |
|
|
output. </p>
|
1975 |
|
|
|
1976 |
|
|
<p>Comments from Judy Ward: It seems like the problem is that the
|
1977 |
|
|
basic_istream and basic_ostream operator <<()'s that are used
|
1978 |
|
|
for the manipulators and streambuf* are in the wrong section and
|
1979 |
|
|
should have their own separate section or be modified to make it clear
|
1980 |
|
|
that the "Common requirements" listed in section 27.6.1.2.1
|
1981 |
|
|
(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
|
1982 |
|
|
apply to them. </p>
|
1983 |
|
|
|
1984 |
|
|
<p>Additional comments from Dietmar Kühl: It appears to be somewhat
|
1985 |
|
|
nonsensical to consider the functions defined in 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> paragraphs 1 to 5 to be "Formatted input
|
1986 |
|
|
function" but since these functions are defined in a section
|
1987 |
|
|
labeled "Formatted input functions" it is unclear to me
|
1988 |
|
|
whether these operators are considered formatted input functions which
|
1989 |
|
|
have to conform to the "common requirements" from 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>: If this is the case, all manipulators, not
|
1990 |
|
|
just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
|
1991 |
|
|
set (... but setting <tt>noskipws</tt> using the manipulator syntax
|
1992 |
|
|
would also skip whitespace :-)</p> <p>It is not clear which functions
|
1993 |
|
|
are to be considered unformatted input functions. As written, it seems
|
1994 |
|
|
that all functions in 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> are unformatted input
|
1995 |
|
|
functions. However, it does not really make much sense to construct a
|
1996 |
|
|
sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
|
1997 |
|
|
unclear what happens to the <tt>gcount()</tt> if
|
1998 |
|
|
eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
|
1999 |
|
|
<tt>sync()</tt> is called: These functions don't extract characters,
|
2000 |
|
|
some of them even "unextract" a character. Should this still
|
2001 |
|
|
be reflected in <tt>gcount()</tt>? Of course, it could be read as if
|
2002 |
|
|
after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
|
2003 |
|
|
(the last unformatted input function, <tt>gcount()</tt>, didn't
|
2004 |
|
|
extract any character) and after a call to <tt>putback()</tt>
|
2005 |
|
|
<tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
|
2006 |
|
|
function <tt>putback()</tt> did "extract" back into the
|
2007 |
|
|
stream). Correspondingly for <tt>unget()</tt>. Is this what is
|
2008 |
|
|
intended? If so, this should be clarified. Otherwise, a corresponding
|
2009 |
|
|
clarification should be used.</p>
|
2010 |
|
|
<p><b>Proposed resolution:</b></p>
|
2011 |
|
|
<p>
|
2012 |
|
|
In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
|
2013 |
|
|
Change the beginning of the second sentence from "The conversion
|
2014 |
|
|
occurs" to "These extractors behave as formatted input functions (as
|
2015 |
|
|
described in 27.6.1.2.1). After a sentry object is constructed,
|
2016 |
|
|
the conversion occurs"
|
2017 |
|
|
</p>
|
2018 |
|
|
|
2019 |
|
|
<p>
|
2020 |
|
|
In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
|
2021 |
|
|
Add an effects clause. "Effects: None. This extractor does
|
2022 |
|
|
not behave as a formatted input function (as described in
|
2023 |
|
|
27.6.1.2.1).
|
2024 |
|
|
</p>
|
2025 |
|
|
|
2026 |
|
|
<p>
|
2027 |
|
|
In 27.6.1.2.3, [lib.istream::extractors], paragraph 2. Change the
|
2028 |
|
|
effects clause to "Effects: Calls pf(*this). This extractor does not
|
2029 |
|
|
behave as a formatted input function (as described in 27.6.1.2.1).
|
2030 |
|
|
</p>
|
2031 |
|
|
|
2032 |
|
|
<p>
|
2033 |
|
|
In 27.6.1.2.3, [lib.istream::extractors], paragraph 4. Change the
|
2034 |
|
|
effects clause to "Effects: Calls pf(*this). This extractor does not
|
2035 |
|
|
behave as a formatted input function (as described in 27.6.1.2.1).
|
2036 |
|
|
</p>
|
2037 |
|
|
|
2038 |
|
|
<p>
|
2039 |
|
|
In 27.6.1.2.3, [lib.istream::extractors], paragraph 12. Change the
|
2040 |
|
|
first two sentences from "If sb is null, calls setstate(failbit),
|
2041 |
|
|
which may throw ios_base::failure (27.4.4.3). Extracts characters
|
2042 |
|
|
from *this..." to "Behaves as a formatted input function (as described
|
2043 |
|
|
in 27.6.1.2.1). If sb is null, calls setstate(failbit), which may
|
2044 |
|
|
throw ios_base::failure (27.4.4.3). After a sentry object is
|
2045 |
|
|
constructed, extracts characters from *this...".
|
2046 |
|
|
</p>
|
2047 |
|
|
|
2048 |
|
|
<p>
|
2049 |
|
|
In 27.6.1.3, [lib.istream.unformatted], before paragraph 2. Add an
|
2050 |
|
|
effects clause. "Effects: none. This member function does not behave
|
2051 |
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
|
2052 |
|
|
</p>
|
2053 |
|
|
|
2054 |
|
|
<p>
|
2055 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 3. Change the
|
2056 |
|
|
beginning of the first sentence of the effects clause from "Extracts a
|
2057 |
|
|
character" to "Behaves as an unformatted input function (as described
|
2058 |
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
|
2059 |
|
|
character"
|
2060 |
|
|
</p>
|
2061 |
|
|
|
2062 |
|
|
<p>
|
2063 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the
|
2064 |
|
|
beginning of the first sentence of the effects clause from "Extracts a
|
2065 |
|
|
character" to "Behaves as an unformatted input function (as described
|
2066 |
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
|
2067 |
|
|
character"
|
2068 |
|
|
</p>
|
2069 |
|
|
|
2070 |
|
|
<p>
|
2071 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the
|
2072 |
|
|
beginning of the first sentence of the effects clause from "Extracts
|
2073 |
|
|
characters" to "Behaves as an unformatted input function (as described
|
2074 |
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
2075 |
|
|
characters"
|
2076 |
|
|
</p>
|
2077 |
|
|
|
2078 |
|
|
<p>
|
2079 |
|
|
[No change needed in paragraph 10, because it refers to paragraph 7.]
|
2080 |
|
|
</p>
|
2081 |
|
|
|
2082 |
|
|
<p>
|
2083 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 12. Change the
|
2084 |
|
|
beginning of the first sentence of the effects clause from "Extracts
|
2085 |
|
|
characters" to "Behaves as an unformatted input function (as described
|
2086 |
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
2087 |
|
|
characters"
|
2088 |
|
|
</p>
|
2089 |
|
|
|
2090 |
|
|
<p>
|
2091 |
|
|
[No change needed in paragraph 15.]
|
2092 |
|
|
</p>
|
2093 |
|
|
|
2094 |
|
|
<p>
|
2095 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 17. Change the
|
2096 |
|
|
beginning of the first sentence of the effects clause from "Extracts
|
2097 |
|
|
characters" to "Behaves as an unformatted input function (as described
|
2098 |
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
2099 |
|
|
characters"
|
2100 |
|
|
</p>
|
2101 |
|
|
|
2102 |
|
|
<p>
|
2103 |
|
|
[No change needed in paragraph 23.]
|
2104 |
|
|
</p>
|
2105 |
|
|
|
2106 |
|
|
<p>
|
2107 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 24. Change the
|
2108 |
|
|
beginning of the first sentence of the effects clause from "Extracts
|
2109 |
|
|
characters" to "Behaves as an unformatted input function (as described
|
2110 |
|
|
in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
|
2111 |
|
|
characters"
|
2112 |
|
|
</p>
|
2113 |
|
|
|
2114 |
|
|
<p>
|
2115 |
|
|
In 27.6.1.3, [lib.istream.unformatted], before paragraph 27. Add an
|
2116 |
|
|
Effects clause: "Effects: Behaves as an unformatted input function (as
|
2117 |
|
|
described in 27.6.1.3, paragraph 1). After constructing a sentry
|
2118 |
|
|
object, reads but does not extract the current input character."
|
2119 |
|
|
</p>
|
2120 |
|
|
|
2121 |
|
|
<p>
|
2122 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 28. Change the
|
2123 |
|
|
first sentence of the Effects clause from "If !good() calls" to
|
2124 |
|
|
Behaves as an unformatted input function (as described in 27.6.1.3,
|
2125 |
|
|
paragraph 1). After constructing a sentry object, if !good() calls"
|
2126 |
|
|
</p>
|
2127 |
|
|
|
2128 |
|
|
<p>
|
2129 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 30. Change the
|
2130 |
|
|
first sentence of the Effects clause from "If !good() calls" to
|
2131 |
|
|
"Behaves as an unformatted input function (as described in 27.6.1.3,
|
2132 |
|
|
paragraph 1). After constructing a sentry object, if !good() calls"
|
2133 |
|
|
</p>
|
2134 |
|
|
|
2135 |
|
|
<p>
|
2136 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 32. Change the
|
2137 |
|
|
first sentence of the Effects clause from "If !good() calls..." to
|
2138 |
|
|
"Behaves as an unformatted input function (as described in 27.6.1.3,
|
2139 |
|
|
paragraph 1). After constructing a sentry object, if !good()
|
2140 |
|
|
calls..." Add a new sentence to the end of the Effects clause:
|
2141 |
|
|
"[Note: this function extracts no characters, so the value returned
|
2142 |
|
|
by the next call to gcount() is 0.]"
|
2143 |
|
|
</p>
|
2144 |
|
|
|
2145 |
|
|
<p>
|
2146 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 34. Change the
|
2147 |
|
|
first sentence of the Effects clause from "If !good() calls" to
|
2148 |
|
|
"Behaves as an unformatted input function (as described in 27.6.1.3,
|
2149 |
|
|
paragraph 1). After constructing a sentry object, if !good() calls".
|
2150 |
|
|
Add a new sentence to the end of the Effects clause: "[Note: this
|
2151 |
|
|
function extracts no characters, so the value returned by the next
|
2152 |
|
|
call to gcount() is 0.]"
|
2153 |
|
|
</p>
|
2154 |
|
|
|
2155 |
|
|
<p>
|
2156 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 36. Change the
|
2157 |
|
|
first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
|
2158 |
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph
|
2159 |
|
|
1), except that it does not count the number of characters extracted
|
2160 |
|
|
and does not affect the value returned by subsequent calls to
|
2161 |
|
|
gcount(). After constructing a sentry object, if rdbuf() is"
|
2162 |
|
|
</p>
|
2163 |
|
|
|
2164 |
|
|
<p>
|
2165 |
|
|
In 27.6.1.3, [lib.istream.unformatted], before paragraph 37. Add an
|
2166 |
|
|
Effects clause: "Effects: Behaves as an unformatted input function (as
|
2167 |
|
|
described in 27.6.1.3, paragraph 1), except that it does not count the
|
2168 |
|
|
number of characters extracted and does not affect the value returned
|
2169 |
|
|
by subsequent calls to gcount()." Change the first sentence of
|
2170 |
|
|
paragraph 37 from "if fail()" to "after constructing a sentry object,
|
2171 |
|
|
if fail()".
|
2172 |
|
|
</p>
|
2173 |
|
|
|
2174 |
|
|
<p>
|
2175 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 38. Change the
|
2176 |
|
|
first sentence of the Effects clause from "If fail()" to "Behaves
|
2177 |
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph
|
2178 |
|
|
1), except that it does not count the number of characters extracted
|
2179 |
|
|
and does not affect the value returned by subsequent calls to
|
2180 |
|
|
gcount(). After constructing a sentry object, if fail()
|
2181 |
|
|
</p>
|
2182 |
|
|
|
2183 |
|
|
<p>
|
2184 |
|
|
In 27.6.1.3, [lib.istream.unformatted], paragraph 40. Change the
|
2185 |
|
|
first sentence of the Effects clause from "If fail()" to "Behaves
|
2186 |
|
|
as an unformatted input function (as described in 27.6.1.3, paragraph
|
2187 |
|
|
1), except that it does not count the number of characters extracted
|
2188 |
|
|
and does not affect the value returned by subsequent calls to
|
2189 |
|
|
gcount(). After constructing a sentry object, if fail()
|
2190 |
|
|
</p>
|
2191 |
|
|
|
2192 |
|
|
<p>
|
2193 |
|
|
In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1. Change
|
2194 |
|
|
the beginning of the third sentence from "The formatting conversion"
|
2195 |
|
|
to "These extractors behave as formatted output functions (as
|
2196 |
|
|
described in 27.6.2.5.1). After the sentry object is constructed, the
|
2197 |
|
|
conversion occurs".
|
2198 |
|
|
</p>
|
2199 |
|
|
|
2200 |
|
|
<p>
|
2201 |
|
|
In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1. Add an
|
2202 |
|
|
effects clause: "Effects: None. Does not behave as a formatted output
|
2203 |
|
|
function (as described in 27.6.2.5.1).".
|
2204 |
|
|
</p>
|
2205 |
|
|
|
2206 |
|
|
<p>
|
2207 |
|
|
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2. Change the
|
2208 |
|
|
effects clause to "Effects: calls pf(*this). This extractor does not
|
2209 |
|
|
behave as a formatted output function (as described in 27.6.2.5.1).".
|
2210 |
|
|
</p>
|
2211 |
|
|
|
2212 |
|
|
<p>
|
2213 |
|
|
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4. Change the
|
2214 |
|
|
effects clause to "Effects: calls pf(*this). This extractor does not
|
2215 |
|
|
behave as a formatted output function (as described in 27.6.2.5.1).".
|
2216 |
|
|
</p>
|
2217 |
|
|
|
2218 |
|
|
<p>
|
2219 |
|
|
In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6. Change the first
|
2220 |
|
|
sentence from "If sb" to "Behaves as a formatted output function (as
|
2221 |
|
|
described in 27.6.2.5.1). After the sentry object is constructed, if
|
2222 |
|
|
sb".
|
2223 |
|
|
</p>
|
2224 |
|
|
|
2225 |
|
|
<p>
|
2226 |
|
|
In 27.6.2.6 [lib.ostream.unformatted], paragraph 2. Change the first
|
2227 |
|
|
sentence from "Inserts the character" to "Behaves as an unformatted
|
2228 |
|
|
output function (as described in 27.6.2.6, paragraph 1). After
|
2229 |
|
|
constructing a sentry object, inserts the character".
|
2230 |
|
|
</p>
|
2231 |
|
|
|
2232 |
|
|
<p>
|
2233 |
|
|
In 27.6.2.6 [lib.ostream.unformatted], paragraph 5. Change the first
|
2234 |
|
|
sentence from "Obtains characters" to "Behaves as an unformatted
|
2235 |
|
|
output function (as described in 27.6.2.6, paragraph 1). After
|
2236 |
|
|
constructing a sentry object, obtains characters".
|
2237 |
|
|
</p>
|
2238 |
|
|
|
2239 |
|
|
<p>
|
2240 |
|
|
In 27.6.2.6 [lib.ostream.unformatted], paragraph 7. Add a new
|
2241 |
|
|
sentence at the end of the paragraph: "Does not behave as an
|
2242 |
|
|
unformatted output function (as described in 27.6.2.6, paragraph 1)."
|
2243 |
|
|
</p>
|
2244 |
|
|
<p><b>Rationale:</b></p>
|
2245 |
|
|
<p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
|
2246 |
|
|
by Judy Ward and Matt Austern. This proposed resolution is section
|
2247 |
|
|
VI of that paper.</p>
|
2248 |
|
|
<hr>
|
2249 |
|
|
<a name="61"><h3>61. Ambiguity in iostreams exception policy</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p>
|
2250 |
|
|
<p>The introduction to the section on unformatted input (27.6.1.3)
|
2251 |
|
|
says that every unformatted input function catches all exceptions that
|
2252 |
|
|
were thrown during input, sets badbit, and then conditionally rethrows
|
2253 |
|
|
the exception. That seems clear enough. Several of the specific
|
2254 |
|
|
functions, however, such as get() and read(), are documented in some
|
2255 |
|
|
circumstances as setting eofbit and/or failbit. (The standard notes,
|
2256 |
|
|
correctly, that setting eofbit or failbit can sometimes result in an
|
2257 |
|
|
exception being thrown.) The question: if one of these functions
|
2258 |
|
|
throws an exception triggered by setting failbit, is this an exception
|
2259 |
|
|
"thrown during input" and hence covered by 27.6.1.3, or does
|
2260 |
|
|
27.6.1.3 only refer to a limited class of exceptions? Just to make
|
2261 |
|
|
this concrete, suppose you have the following snippet. </p>
|
2262 |
|
|
|
2263 |
|
|
<pre>
|
2264 |
|
|
char buffer[N];
|
2265 |
|
|
istream is;
|
2266 |
|
|
...
|
2267 |
|
|
is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
|
2268 |
|
|
is.read(buffer, N);</pre>
|
2269 |
|
|
|
2270 |
|
|
<p>Now suppose we reach EOF before we've read N characters. What
|
2271 |
|
|
iostate bits can we expect to be set, and what exception (if any) will
|
2272 |
|
|
be thrown? </p>
|
2273 |
|
|
<p><b>Proposed resolution:</b></p>
|
2274 |
|
|
<p>
|
2275 |
|
|
In 27.6.1.3, paragraph 1, after the sentence that begins
|
2276 |
|
|
"If an exception is thrown...", add the following
|
2277 |
|
|
parenthetical comment: "(Exceptions thrown from
|
2278 |
|
|
<tt>basic_ios<>::clear()</tt> are not caught or rethrown.)"
|
2279 |
|
|
</p>
|
2280 |
|
|
<p><b>Rationale:</b></p>
|
2281 |
|
|
<p>The LWG looked to two alternative wordings, and choose the proposed
|
2282 |
|
|
resolution as better standardese.</p>
|
2283 |
|
|
<hr>
|
2284 |
|
|
<a name="62"><h3>62. <tt>Sync</tt>'s return value</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p>
|
2285 |
|
|
<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
|
2286 |
|
|
"calls rdbuf()->pubsync() and, if that function returns -1
|
2287 |
|
|
... returns traits::eof()." </p>
|
2288 |
|
|
|
2289 |
|
|
<p>That looks suspicious, because traits::eof() is of type
|
2290 |
|
|
traits::int_type while the return type of sync() is int. </p>
|
2291 |
|
|
<p><b>Proposed resolution:</b></p>
|
2292 |
|
|
<p>In 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 36, change "returns
|
2293 |
|
|
<tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
|
2294 |
|
|
</p>
|
2295 |
|
|
<hr>
|
2296 |
|
|
<a name="63"><h3>63. Exception-handling policy for unformatted output</h3></a><p><b>Section:</b> 27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998</p>
|
2297 |
|
|
<p>Clause 27 details an exception-handling policy for formatted input,
|
2298 |
|
|
unformatted input, and formatted output. It says nothing for
|
2299 |
|
|
unformatted output (27.6.2.6). 27.6.2.6 should either include the same
|
2300 |
|
|
kind of exception-handling policy as in the other three places, or
|
2301 |
|
|
else it should have a footnote saying that the omission is
|
2302 |
|
|
deliberate. </p>
|
2303 |
|
|
<p><b>Proposed resolution:</b></p>
|
2304 |
|
|
<p>
|
2305 |
|
|
In 27.6.2.6, paragraph 1, replace the last sentence ("In any
|
2306 |
|
|
case, the unformatted output function ends by destroying the sentry
|
2307 |
|
|
object, then returning the value specified for the formatted output
|
2308 |
|
|
function.") with the following text:
|
2309 |
|
|
</p>
|
2310 |
|
|
<blockquote>
|
2311 |
|
|
If an exception is thrown during output, then <tt>ios::badbit</tt> is
|
2312 |
|
|
turned on [Footnote: without causing an <tt>ios::failure</tt> to be
|
2313 |
|
|
thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &
|
2314 |
|
|
badbit) != 0</tt> then the exception is rethrown. In any case, the
|
2315 |
|
|
unformatted output function ends by destroying the sentry object,
|
2316 |
|
|
then, if no exception was thrown, returning the value specified for
|
2317 |
|
|
the formatted output function.
|
2318 |
|
|
</blockquote>
|
2319 |
|
|
<p><b>Rationale:</b></p>
|
2320 |
|
|
<p>
|
2321 |
|
|
This exception-handling policy is consistent with that of formatted
|
2322 |
|
|
input, unformatted input, and formatted output.
|
2323 |
|
|
</p>
|
2324 |
|
|
<hr>
|
2325 |
|
|
<a name="64"><h3>64. Exception handling in <tt>basic_istream::operator>>(basic_streambuf*)</tt>
|
2326 |
|
|
</h3></a><p><b>Section:</b> 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998 </p>
|
2327 |
|
|
<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
|
2328 |
|
|
different ways, depending on whether the second sentence is read as an
|
2329 |
|
|
elaboration of the first. </p>
|
2330 |
|
|
<p><b>Proposed resolution:</b></p>
|
2331 |
|
|
<p>Replace 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 13, which begins
|
2332 |
|
|
"If the function inserts no characters ..." with:</p>
|
2333 |
|
|
|
2334 |
|
|
<blockquote>
|
2335 |
|
|
<p>If the function inserts no characters, it calls
|
2336 |
|
|
<tt>setstate(failbit)</tt>, which may throw
|
2337 |
|
|
<tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
|
2338 |
|
|
because it caught an exception thrown while extracting characters
|
2339 |
|
|
from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
|
2340 |
|
|
(27.4.4.3), then the caught exception is rethrown. </p>
|
2341 |
|
|
</blockquote>
|
2342 |
|
|
<hr>
|
2343 |
|
|
<a name="66"><h3>66. Strstreambuf::setbuf</h3></a><p><b>Section:</b> D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Aug 1998</p>
|
2344 |
|
|
<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
|
2345 |
|
|
"Performs an operation that is defined separately for each class
|
2346 |
|
|
derived from strstreambuf". This is obviously an incorrect
|
2347 |
|
|
cut-and-paste from basic_streambuf. There are no classes derived from
|
2348 |
|
|
strstreambuf. </p>
|
2349 |
|
|
<p><b>Proposed resolution:</b></p>
|
2350 |
|
|
<p>D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 19, replace the setbuf effects
|
2351 |
|
|
clause which currently says "Performs an operation that is
|
2352 |
|
|
defined separately for each class derived from strstreambuf"
|
2353 |
|
|
with:</p>
|
2354 |
|
|
|
2355 |
|
|
<blockquote>
|
2356 |
|
|
<p><b>Effects</b>: implementation defined, except that
|
2357 |
|
|
<tt>setbuf(0,0)</tt> has no effect.</p>
|
2358 |
|
|
</blockquote>
|
2359 |
|
|
<hr>
|
2360 |
|
|
<a name="68"><h3>68. Extractors for char* should store null at end</h3></a><p><b>Section:</b> 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 14 Jul 1998</p>
|
2361 |
|
|
<p>Extractors for char* (27.6.1.2.3) do not store a null character
|
2362 |
|
|
after the extracted character sequence whereas the unformatted
|
2363 |
|
|
functions like get() do. Why is this?</p>
|
2364 |
|
|
|
2365 |
|
|
<p>Comment from Jerry Schwarz: There is apparently an editing
|
2366 |
|
|
glitch. You'll notice that the last item of the list of what stops
|
2367 |
|
|
extraction doesn't make any sense. It was supposed to be the line that
|
2368 |
|
|
said a null is stored.</p>
|
2369 |
|
|
<p><b>Proposed resolution:</b></p>
|
2370 |
|
|
<p>27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, paragraph 7, change the last list
|
2371 |
|
|
item from:</p>
|
2372 |
|
|
|
2373 |
|
|
<blockquote>
|
2374 |
|
|
A null byte (<tt>charT()</tt>) in the next position, which may be
|
2375 |
|
|
the first position if no characters were extracted.
|
2376 |
|
|
</blockquote>
|
2377 |
|
|
|
2378 |
|
|
<p>to become a new paragraph which reads:</p>
|
2379 |
|
|
|
2380 |
|
|
<blockquote>
|
2381 |
|
|
Operator>> then stores a null byte (<tt>charT()</tt>) in the
|
2382 |
|
|
next position, which may be the first position if no characters were
|
2383 |
|
|
extracted.
|
2384 |
|
|
</blockquote>
|
2385 |
|
|
<hr>
|
2386 |
|
|
<a name="69"><h3>69. Must elements of a vector be contiguous?</h3></a><p><b>Section:</b> 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 29 Jul 1998</p>
|
2387 |
|
|
<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
|
2388 |
|
|
|
2389 |
|
|
<p>(Please note that this is entirely separate from the question of
|
2390 |
|
|
whether a vector iterator is required to be a pointer; the answer to
|
2391 |
|
|
that question is clearly "no," as it would rule out
|
2392 |
|
|
debugging implementations)</p>
|
2393 |
|
|
<p><b>Proposed resolution:</b></p>
|
2394 |
|
|
<p>Add the following text to the end of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>,
|
2395 |
|
|
paragraph 1. </p>
|
2396 |
|
|
|
2397 |
|
|
<blockquote>
|
2398 |
|
|
<p>The elements of a vector are stored contiguously, meaning that if
|
2399 |
|
|
v is a <tt>vector<T, Allocator></tt> where T is some type
|
2400 |
|
|
other than <tt>bool</tt>, then it obeys the identity <tt>&v[n]
|
2401 |
|
|
== &v[0] + n</tt> for all <tt>0 <= n < v.size()</tt>.</p>
|
2402 |
|
|
</blockquote>
|
2403 |
|
|
<p><b>Rationale:</b></p>
|
2404 |
|
|
<p>The LWG feels that as a practical matter the answer is clearly
|
2405 |
|
|
"yes". There was considerable discussion as to the best way
|
2406 |
|
|
to express the concept of "contiguous", which is not
|
2407 |
|
|
directly defined in the standard. Discussion included:</p>
|
2408 |
|
|
|
2409 |
|
|
<ul>
|
2410 |
|
|
<li>An operational definition similar to the above proposed resolution is
|
2411 |
|
|
already used for valarray (26.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a>).</li>
|
2412 |
|
|
<li>There is no need to explicitly consider a user-defined operator&
|
2413 |
|
|
because elements must be copyconstructible (23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> para 3)
|
2414 |
|
|
and copyconstructible (20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>) specifies
|
2415 |
|
|
requirements for operator&.</li>
|
2416 |
|
|
<li>There is no issue of one-past-the-end because of language rules.</li>
|
2417 |
|
|
</ul>
|
2418 |
|
|
<hr>
|
2419 |
|
|
<a name="70"><h3>70. Uncaught_exception() missing throw() specification</h3></a><p><b>Section:</b> 18.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> Unknown</p>
|
2420 |
|
|
<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
|
2421 |
|
|
|
2422 |
|
|
<p>uncaught_exception() doesn't have a throw specification.</p>
|
2423 |
|
|
|
2424 |
|
|
<p>It is intentional ? Does it means that one should be prepared to
|
2425 |
|
|
handle exceptions thrown from uncaught_exception() ?</p>
|
2426 |
|
|
|
2427 |
|
|
<p>uncaught_exception() is called in exception handling contexts where
|
2428 |
|
|
exception safety is very important.</p>
|
2429 |
|
|
<p><b>Proposed resolution:</b></p>
|
2430 |
|
|
<p>In 15.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add "throw()" to uncaught_exception().</p>
|
2431 |
|
|
<hr>
|
2432 |
|
|
<a name="71"><h3>71. Do_get_monthname synopsis missing argument</h3></a><p><b>Section:</b> 22.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 13 Aug 1998</p>
|
2433 |
|
|
<p>The locale facet member <tt>time_get<>::do_get_monthname</tt>
|
2434 |
|
|
is described in 22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> with five arguments,
|
2435 |
|
|
consistent with do_get_weekday and with its specified use by member
|
2436 |
|
|
get_monthname. However, in the synopsis, it is specified instead with
|
2437 |
|
|
four arguments. The missing argument is the "end" iterator
|
2438 |
|
|
value.</p>
|
2439 |
|
|
<p><b>Proposed resolution:</b></p>
|
2440 |
|
|
<p>In 22.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>, add an "end" argument to
|
2441 |
|
|
the declaration of member do_monthname as follows:</p>
|
2442 |
|
|
|
2443 |
|
|
<pre> virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&,
|
2444 |
|
|
ios_base::iostate& err, tm* t) const;</pre>
|
2445 |
|
|
<hr>
|
2446 |
|
|
<a name="74"><h3>74. Garbled text for <tt>codecvt::do_max_length</tt>
|
2447 |
|
|
</h3></a><p><b>Section:</b> 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 8 Sep 1998</p>
|
2448 |
|
|
<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
|
2449 |
|
|
clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
|
2450 |
|
|
parentheses and a spurious <b>n</b>.</p>
|
2451 |
|
|
<p><b>Proposed resolution:</b></p>
|
2452 |
|
|
<p>Replace 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 11 with the
|
2453 |
|
|
following:</p>
|
2454 |
|
|
|
2455 |
|
|
<blockquote>
|
2456 |
|
|
<b>Returns</b>: The maximum value that
|
2457 |
|
|
<tt>do_length(state, from, from_end, 1)</tt> can return for any
|
2458 |
|
|
valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
|
2459 |
|
|
<tt>state</tt>. The specialization <tt>codecvt<char, char,
|
2460 |
|
|
mbstate_t>::do_max_length()</tt> returns 1.
|
2461 |
|
|
</blockquote>
|
2462 |
|
|
<hr>
|
2463 |
|
|
<a name="75"><h3>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt
|
2464 |
|
|
Austern <b>Date:</b> 18 Sep 1998</p>
|
2465 |
|
|
<p>The class synopses for classes <tt>codecvt<></tt> (22.2.1.5)
|
2466 |
|
|
and <tt>codecvt_byname<></tt> (22.2.1.6) say that the first
|
2467 |
|
|
parameter of the member functions <tt>length</tt> and
|
2468 |
|
|
<tt>do_length</tt> is of type <tt>const stateT&</tt>. The member
|
2469 |
|
|
function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
|
2470 |
|
|
paragraph 9) say that the type is <tt>stateT&</tt>. Either the
|
2471 |
|
|
synopsis or the summary must be changed. </p>
|
2472 |
|
|
|
2473 |
|
|
<p>If (as I believe) the member function descriptions are correct,
|
2474 |
|
|
then we must also add text saying how <tt>do_length</tt> changes its
|
2475 |
|
|
<tt>stateT</tt> argument. </p>
|
2476 |
|
|
<p><b>Proposed resolution:</b></p>
|
2477 |
|
|
<p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>, and also in 22.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>,
|
2478 |
|
|
change the <tt>stateT</tt> argument type on both member
|
2479 |
|
|
<tt>length()</tt> and member <tt>do_length()</tt> from </p>
|
2480 |
|
|
|
2481 |
|
|
<blockquote>
|
2482 |
|
|
<p><tt>const stateT&</tt></p>
|
2483 |
|
|
</blockquote>
|
2484 |
|
|
|
2485 |
|
|
<p>to</p>
|
2486 |
|
|
|
2487 |
|
|
<blockquote>
|
2488 |
|
|
<p><tt>stateT&</tt></p>
|
2489 |
|
|
</blockquote>
|
2490 |
|
|
|
2491 |
|
|
<p>In 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, add to the definition for member
|
2492 |
|
|
<tt>do_length</tt> a paragraph:</p>
|
2493 |
|
|
|
2494 |
|
|
<blockquote>
|
2495 |
|
|
<p>Effects: The effect on the <tt>state</tt> argument is ``as if''
|
2496 |
|
|
it called <tt>do_in(state, from, from_end, from, to, to+max,
|
2497 |
|
|
to)</tt> for <tt>to</tt> pointing to a buffer of at least
|
2498 |
|
|
<tt>max</tt> elements.</p>
|
2499 |
|
|
</blockquote>
|
2500 |
|
|
<hr>
|
2501 |
|
|
<a name="76"><h3>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Sep 1998</p>
|
2502 |
|
|
<p>This issue concerns the requirements on classes derived from
|
2503 |
|
|
<tt>codecvt</tt>, including user-defined classes. What are the
|
2504 |
|
|
restrictions on the conversion from external characters
|
2505 |
|
|
(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
|
2506 |
|
|
Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
|
2507 |
|
|
the I/O library make? </p>
|
2508 |
|
|
|
2509 |
|
|
<p>The question is whether it's possible to convert from internal
|
2510 |
|
|
characters to external characters one internal character at a time,
|
2511 |
|
|
and whether, given a valid sequence of external characters, it's
|
2512 |
|
|
possible to pick off internal characters one at a time. Or, to put it
|
2513 |
|
|
differently: given a sequence of external characters and the
|
2514 |
|
|
corresponding sequence of internal characters, does a position in the
|
2515 |
|
|
internal sequence correspond to some position in the external
|
2516 |
|
|
sequence? </p>
|
2517 |
|
|
|
2518 |
|
|
<p>To make this concrete, suppose that <tt>[first, last)</tt> is a
|
2519 |
|
|
sequence of <i>M</i> external characters and that <tt>[ifirst,
|
2520 |
|
|
ilast)</tt> is the corresponding sequence of <i>N</i> internal
|
2521 |
|
|
characters, where <i>N > 1</i>. That is, <tt>my_encoding.in()</tt>,
|
2522 |
|
|
applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
|
2523 |
|
|
ilast)</tt>. Now the question: does there necessarily exist a
|
2524 |
|
|
subsequence of external characters, <tt>[first, last_1)</tt>, such
|
2525 |
|
|
that the corresponding sequence of internal characters is the single
|
2526 |
|
|
character <tt>*ifirst</tt>?
|
2527 |
|
|
</p>
|
2528 |
|
|
|
2529 |
|
|
<p>(What a "no" answer would mean is that
|
2530 |
|
|
<tt>my_encoding</tt> translates sequences only as blocks. There's a
|
2531 |
|
|
sequence of <i>M</i> external characters that maps to a sequence of
|
2532 |
|
|
<i>N</i> internal characters, but that external sequence has no
|
2533 |
|
|
subsequence that maps to <i>N-1</i> internal characters.) </p>
|
2534 |
|
|
|
2535 |
|
|
<p>Some of the wording in the standard, such as the description of
|
2536 |
|
|
<tt>codecvt::do_max_length</tt> (22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>,
|
2537 |
|
|
paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 3) suggests that it must always be
|
2538 |
|
|
possible to pick off internal characters one at a time from a sequence
|
2539 |
|
|
of external characters. However, this is never explicitly stated one
|
2540 |
|
|
way or the other. </p>
|
2541 |
|
|
|
2542 |
|
|
<p>This issue seems (and is) quite technical, but it is important if
|
2543 |
|
|
we expect users to provide their own encoding facets. This is an area
|
2544 |
|
|
where the standard library calls user-supplied code, so a well-defined
|
2545 |
|
|
set of requirements for the user-supplied code is crucial. Users must
|
2546 |
|
|
be aware of the assumptions that the library makes. This issue affects
|
2547 |
|
|
positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
|
2548 |
|
|
and several of <tt>codecvt</tt>'s member functions. </p>
|
2549 |
|
|
<p><b>Proposed resolution:</b></p>
|
2550 |
|
|
<p>Add the following text as a new paragraph, following 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> paragraph 2:</p>
|
2551 |
|
|
|
2552 |
|
|
<blockquote>
|
2553 |
|
|
<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
|
2554 |
|
|
(27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>) must have the property that if</p>
|
2555 |
|
|
<pre> do_out(state, from, from_end, from_next, to, to_lim, to_next)
|
2556 |
|
|
</pre>
|
2557 |
|
|
would return <tt>ok</tt>, where <tt>from != from_end</tt>, then
|
2558 |
|
|
<pre> do_out(state, from, from + 1, from_next, to, to_end, to_next)
|
2559 |
|
|
</pre>
|
2560 |
|
|
must also return <tt>ok</tt>, and that if
|
2561 |
|
|
<pre> do_in(state, from, from_end, from_next, to, to_lim, to_next)
|
2562 |
|
|
</pre>
|
2563 |
|
|
would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
|
2564 |
|
|
<pre> do_in(state, from, from_end, from_next, to, to + 1, to_next)
|
2565 |
|
|
</pre>
|
2566 |
|
|
<p>must also return <tt>ok</tt>. [<i>Footnote:</i> Informally, this
|
2567 |
|
|
means that <tt>basic_filebuf</tt> assumes that the mapping from
|
2568 |
|
|
internal to external characters is 1 to N: a <tt>codecvt</tt> that is
|
2569 |
|
|
used by <tt>basic_filebuf</tt> must be able to translate characters
|
2570 |
|
|
one internal character at a time. <i>--End Footnote</i>]</p>
|
2571 |
|
|
</blockquote>
|
2572 |
|
|
|
2573 |
|
|
<p><i>[Redmond: Minor change in proposed resolution. Original
|
2574 |
|
|
proposed resolution talked about "success", with a parenthetical
|
2575 |
|
|
comment that success meant returning <tt>ok</tt>. New wording
|
2576 |
|
|
removes all talk about "success", and just talks about the
|
2577 |
|
|
return value.]</i></p>
|
2578 |
|
|
|
2579 |
|
|
<p><b>Rationale:</b></p>
|
2580 |
|
|
|
2581 |
|
|
<p>The proposed resoluion says that conversions can be performed one
|
2582 |
|
|
internal character at a time. This rules out some encodings that
|
2583 |
|
|
would otherwise be legal. The alternative answer would mean there
|
2584 |
|
|
would be some internal positions that do not correspond to any
|
2585 |
|
|
external file position.</p>
|
2586 |
|
|
<p>
|
2587 |
|
|
An example of an encoding that this rules out is one where the
|
2588 |
|
|
<tt>internT</tt> and <tt>externT</tt> are of the same type, and
|
2589 |
|
|
where the internal sequence <tt>c1 c2</tt> corresponds to the
|
2590 |
|
|
external sequence <tt>c2 c1</tt>.
|
2591 |
|
|
</p>
|
2592 |
|
|
<p>It was generally agreed that <tt>basic_filebuf</tt> relies
|
2593 |
|
|
on this property: it was designed under the assumption that
|
2594 |
|
|
the external-to-internal mapping is N-to-1, and it is not clear
|
2595 |
|
|
that <tt>basic_filebuf</tt> is implementable without that
|
2596 |
|
|
restriction.
|
2597 |
|
|
</p>
|
2598 |
|
|
<p>
|
2599 |
|
|
The proposed resolution is expressed as a restriction on
|
2600 |
|
|
<tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
|
2601 |
|
|
than a blanket restriction on all <tt>codecvt</tt> facets,
|
2602 |
|
|
because <tt>basic_filebuf</tt> is the only other part of the
|
2603 |
|
|
library that uses <tt>codecvt</tt>. If a user wants to define
|
2604 |
|
|
a <tt>codecvt</tt> facet that implements a more general N-to-M
|
2605 |
|
|
mapping, there is no reason to prohibit it, so long as the user
|
2606 |
|
|
does not expect <tt>basic_filebuf</tt> to be able to use it.
|
2607 |
|
|
</p>
|
2608 |
|
|
<hr>
|
2609 |
|
|
<a name="78"><h3>78. Typo: event_call_back</h3></a><p><b>Section:</b> 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
2610 |
|
|
<p>typo: event_call_back should be event_callback </p>
|
2611 |
|
|
<p><b>Proposed resolution:</b></p>
|
2612 |
|
|
<p>In the 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change
|
2613 |
|
|
"event_call_back" to "event_callback". </p>
|
2614 |
|
|
<hr>
|
2615 |
|
|
<a name="79"><h3>79. Inconsistent declaration of polar()</h3></a><p><b>Section:</b> 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
2616 |
|
|
<p>In 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p>
|
2617 |
|
|
<pre> template<class T> complex<T> polar(const T&, const T&); </pre>
|
2618 |
|
|
|
2619 |
|
|
<p>In 26.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> it is declared as follows:</p>
|
2620 |
|
|
<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
|
2621 |
|
|
|
2622 |
|
|
<p>Thus whether the second parameter is optional is not clear. </p>
|
2623 |
|
|
<p><b>Proposed resolution:</b></p>
|
2624 |
|
|
<p>In 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p>
|
2625 |
|
|
<pre> template<class T> complex<T> polar(const T&, const T&);</pre>
|
2626 |
|
|
|
2627 |
|
|
<p>to:</p>
|
2628 |
|
|
<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
|
2629 |
|
|
<hr>
|
2630 |
|
|
<a name="80"><h3>80. Global Operators of complex declared twice</h3></a><p><b>Section:</b> 26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
2631 |
|
|
<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
|
2632 |
|
|
class complex. This redundancy should be removed.</p>
|
2633 |
|
|
<p><b>Proposed resolution:</b></p>
|
2634 |
|
|
<p>Reduce redundancy according to the general style of the standard. </p>
|
2635 |
|
|
<hr>
|
2636 |
|
|
<a name="83"><h3>83. String::npos vs. string::max_size()</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
2637 |
|
|
<p>Many string member functions throw if size is getting or exceeding
|
2638 |
|
|
npos. However, I wonder why they don't throw if size is getting or
|
2639 |
|
|
exceeding max_size() instead of npos. May be npos is known at compile
|
2640 |
|
|
time, while max_size() is known at runtime. However, what happens if
|
2641 |
|
|
size exceeds max_size() but not npos, then? It seems the standard
|
2642 |
|
|
lacks some clarifications here.</p>
|
2643 |
|
|
<p><b>Proposed resolution:</b></p>
|
2644 |
|
|
<p>After 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 4 ("The functions
|
2645 |
|
|
described in this clause...") add a new paragraph:</p>
|
2646 |
|
|
|
2647 |
|
|
<blockquote>
|
2648 |
|
|
<p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
|
2649 |
|
|
<tt> max_size()</tt> then
|
2650 |
|
|
the operation throws <tt>length_error</tt>.</p>
|
2651 |
|
|
</blockquote>
|
2652 |
|
|
<p><b>Rationale:</b></p>
|
2653 |
|
|
<p>The LWG believes length_error is the correct exception to throw.</p>
|
2654 |
|
|
<hr>
|
2655 |
|
|
<a name="86"><h3>86. String constructors don't describe exceptions</h3></a><p><b>Section:</b> 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
2656 |
|
|
<p>The constructor from a range:</p>
|
2657 |
|
|
|
2658 |
|
|
<pre>template<class InputIterator>
|
2659 |
|
|
basic_string(InputIterator begin, InputIterator end,
|
2660 |
|
|
const Allocator& a = Allocator());</pre>
|
2661 |
|
|
|
2662 |
|
|
<p>lacks a throws clause. However, I would expect that it throws
|
2663 |
|
|
according to the other constructors if the numbers of characters in
|
2664 |
|
|
the range equals npos (or exceeds max_size(), see above). </p>
|
2665 |
|
|
<p><b>Proposed resolution:</b></p>
|
2666 |
|
|
<p>In 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, Strike throws paragraphs for
|
2667 |
|
|
constructors which say "Throws: length_error if n ==
|
2668 |
|
|
npos."</p>
|
2669 |
|
|
<p><b>Rationale:</b></p>
|
2670 |
|
|
<p>Throws clauses for length_error if n == npos are no longer needed
|
2671 |
|
|
because they are subsumed by the general wording added by the
|
2672 |
|
|
resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
|
2673 |
|
|
<hr>
|
2674 |
|
|
<a name="90"><h3>90. Incorrect description of operator >> for strings</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
2675 |
|
|
<p>The effect of operator >> for strings contain the following item:</p>
|
2676 |
|
|
|
2677 |
|
|
<p> <tt>isspace(c,getloc())</tt> is true for the next available input
|
2678 |
|
|
character c.</p>
|
2679 |
|
|
|
2680 |
|
|
<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
|
2681 |
|
|
<p><b>Proposed resolution:</b></p>
|
2682 |
|
|
<p>In 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 1 Effects clause replace:</p>
|
2683 |
|
|
|
2684 |
|
|
<blockquote>
|
2685 |
|
|
<p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
|
2686 |
|
|
</blockquote>
|
2687 |
|
|
|
2688 |
|
|
<p>with:</p>
|
2689 |
|
|
|
2690 |
|
|
<blockquote>
|
2691 |
|
|
<p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
|
2692 |
|
|
</blockquote>
|
2693 |
|
|
<hr>
|
2694 |
|
|
<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
2695 |
|
|
<p>Operator >> and getline() for strings read until eof()
|
2696 |
|
|
in the input stream is true. However, this might never happen, if the
|
2697 |
|
|
stream can't read anymore without reaching EOF. So shouldn't it be
|
2698 |
|
|
changed into that it reads until !good() ? </p>
|
2699 |
|
|
<p><b>Proposed resolution:</b></p>
|
2700 |
|
|
<p>In 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 1, replace:</p>
|
2701 |
|
|
<blockquote>
|
2702 |
|
|
Effects: Begins by constructing a sentry object k as if k were
|
2703 |
|
|
constructed by typename basic_istream<charT,traits>::sentry k( is). If
|
2704 |
|
|
bool( k) is true, it calls str.erase() and then extracts characters
|
2705 |
|
|
from is and appends them to str as if by calling str.append(1, c). If
|
2706 |
|
|
is.width() is greater than zero, the maximum number n of characters
|
2707 |
|
|
appended is is.width(); otherwise n is str.max_size(). Characters are
|
2708 |
|
|
extracted and appended until any of the following occurs:
|
2709 |
|
|
</blockquote>
|
2710 |
|
|
<p>with:</p>
|
2711 |
|
|
<blockquote>
|
2712 |
|
|
Effects: Behaves as a formatted input function (27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>). After constructing a sentry object, if the
|
2713 |
|
|
sentry converts to true, calls str.erase() and then extracts
|
2714 |
|
|
characters from is and appends them to str as if by calling
|
2715 |
|
|
str.append(1,c). If is.width() is greater than zero, the maximum
|
2716 |
|
|
number n of characters appended is is.width(); otherwise n is
|
2717 |
|
|
str.max_size(). Characters are extracted and appended until any of the
|
2718 |
|
|
following occurs:
|
2719 |
|
|
</blockquote>
|
2720 |
|
|
|
2721 |
|
|
<p>In 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>, paragraph 6, replace</p>
|
2722 |
|
|
<blockquote>
|
2723 |
|
|
Effects: Begins by constructing a sentry object k as if by typename
|
2724 |
|
|
basic_istream<charT,traits>::sentry k( is, true). If bool( k) is true,
|
2725 |
|
|
it calls str.erase() and then extracts characters from is and appends
|
2726 |
|
|
them to str as if by calling str.append(1, c) until any of the
|
2727 |
|
|
following occurs:
|
2728 |
|
|
</blockquote>
|
2729 |
|
|
<p>with:</p>
|
2730 |
|
|
<blockquote>
|
2731 |
|
|
Effects: Behaves as an unformatted input function (27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), except that it does not affect the value returned
|
2732 |
|
|
by subsequent calls to basic_istream<>::gcount(). After
|
2733 |
|
|
constructing a sentry object, if the sentry converts to true, calls
|
2734 |
|
|
str.erase() and then extracts characters from is and appends them to
|
2735 |
|
|
str as if by calling str.append(1,c) until any of the following
|
2736 |
|
|
occurs:
|
2737 |
|
|
</blockquote>
|
2738 |
|
|
|
2739 |
|
|
<p><i>[Redmond: Made changes in proposed resolution. <tt>operator>></tt>
|
2740 |
|
|
should be a formatted input function, not an unformatted input function.
|
2741 |
|
|
<tt>getline</tt> should not be required to set <tt>gcount</tt>, since
|
2742 |
|
|
there is no mechanism for <tt>gcount</tt> to be set except by one of
|
2743 |
|
|
<tt>basic_istream</tt>'s member functions.]</i></p>
|
2744 |
|
|
|
2745 |
|
|
<p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
|
2746 |
|
|
|
2747 |
|
|
<p><b>Rationale:</b></p>
|
2748 |
|
|
<p>The real issue here is whether or not these string input functions
|
2749 |
|
|
get their characters from a streambuf, rather than by calling an
|
2750 |
|
|
istream's member functions, a streambuf signals failure either by
|
2751 |
|
|
returning eof or by throwing an exception; there are no other
|
2752 |
|
|
possibilities. The proposed resolution makes it clear that these two
|
2753 |
|
|
functions do get characters from a streambuf.</p>
|
2754 |
|
|
<hr>
|
2755 |
|
|
<a name="92"></a><h3><a name="92">92. Incomplete Algorithm Requirements</a></h3><p><b>Section:</b> 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
2756 |
|
|
<p>The standard does not state, how often a function object is copied,
|
2757 |
|
|
called, or the order of calls inside an algorithm. This may lead to
|
2758 |
|
|
surprising/buggy behavior. Consider the following example: </p>
|
2759 |
|
|
|
2760 |
|
|
<pre>class Nth { // function object that returns true for the nth element
|
2761 |
|
|
private:
|
2762 |
|
|
int nth; // element to return true for
|
2763 |
|
|
int count; // element counter
|
2764 |
|
|
public:
|
2765 |
|
|
Nth (int n) : nth(n), count(0) {
|
2766 |
|
|
}
|
2767 |
|
|
bool operator() (int) {
|
2768 |
|
|
return ++count == nth;
|
2769 |
|
|
}
|
2770 |
|
|
};
|
2771 |
|
|
....
|
2772 |
|
|
// remove third element
|
2773 |
|
|
list<int>::iterator pos;
|
2774 |
|
|
pos = remove_if(coll.begin(),coll.end(), // range
|
2775 |
|
|
Nth(3)), // remove criterion
|
2776 |
|
|
coll.erase(pos,coll.end()); </pre>
|
2777 |
|
|
|
2778 |
|
|
<p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
|
2779 |
|
|
happens because the usual implementation of the algorithm copies the
|
2780 |
|
|
function object internally: </p>
|
2781 |
|
|
|
2782 |
|
|
<pre>template <class ForwIter, class Predicate>
|
2783 |
|
|
ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
|
2784 |
|
|
{
|
2785 |
|
|
beg = find_if(beg, end, op);
|
2786 |
|
|
if (beg == end) {
|
2787 |
|
|
return beg;
|
2788 |
|
|
}
|
2789 |
|
|
else {
|
2790 |
|
|
ForwIter next = beg;
|
2791 |
|
|
return remove_copy_if(++next, end, beg, op);
|
2792 |
|
|
}
|
2793 |
|
|
} </pre>
|
2794 |
|
|
|
2795 |
|
|
<p>The algorithm uses find_if() to find the first element that should
|
2796 |
|
|
be removed. However, it then uses a copy of the passed function object
|
2797 |
|
|
to process the resulting elements (if any). Here, Nth is used again
|
2798 |
|
|
and removes also the sixth element. This behavior compromises the
|
2799 |
|
|
advantage of function objects being able to have a state. Without any
|
2800 |
|
|
cost it could be avoided (just implement it directly instead of
|
2801 |
|
|
calling find_if()). </p>
|
2802 |
|
|
<p><b>Proposed resolution:</b></p>
|
2803 |
|
|
|
2804 |
|
|
<p>Add a new paragraph following 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> paragraph 8:</p>
|
2805 |
|
|
<blockquote>
|
2806 |
|
|
[Note: Unless otherwise specified, algorithms that take function
|
2807 |
|
|
objects as arguments are permitted to copy those function objects
|
2808 |
|
|
freely. Programmers for whom object identity is important should
|
2809 |
|
|
consider using a wrapper class that points to a noncopied
|
2810 |
|
|
implementation object, or some equivalent solution.]
|
2811 |
|
|
</blockquote>
|
2812 |
|
|
|
2813 |
|
|
<p><i>[Dublin: Pete Becker felt that this may not be a defect,
|
2814 |
|
|
but rather something that programmers need to be educated about.
|
2815 |
|
|
There was discussion of adding wording to the effect that the number
|
2816 |
|
|
and order of calls to function objects, including predicates, not
|
2817 |
|
|
affect the behavior of the function object.]</i></p>
|
2818 |
|
|
|
2819 |
|
|
<p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
|
2820 |
|
|
have a clear statement of "predicate" in the
|
2821 |
|
|
standard. People including me seemed to think "a function
|
2822 |
|
|
returning a Boolean value and being able to be called by an STL
|
2823 |
|
|
algorithm or be used as sorting criterion or ... is a
|
2824 |
|
|
predicate". But a predicate has more requirements: It should
|
2825 |
|
|
never change its behavior due to a call or being copied. IMHO we have
|
2826 |
|
|
to state this in the standard. If you like, see section 8.1.4 of my
|
2827 |
|
|
library book for a detailed discussion.]</i></p>
|
2828 |
|
|
|
2829 |
|
|
<p><i>[Kona: Nico will provide wording to the effect that "unless
|
2830 |
|
|
otherwise specified, the number of copies of and calls to function
|
2831 |
|
|
objects by algorithms is unspecified". Consider placing in
|
2832 |
|
|
25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> after paragraph 9.]</i></p>
|
2833 |
|
|
|
2834 |
|
|
<p><i>[Santa Cruz: The standard doesn't currently guarantee that
|
2835 |
|
|
functions object won't be copied, and what isn't forbidden is
|
2836 |
|
|
allowed. It is believed (especially since implementations that were
|
2837 |
|
|
written in concert with the standard do make copies of function
|
2838 |
|
|
objects) that this was intentional. Thus, no normative change is
|
2839 |
|
|
needed. What we should put in is a non-normative note suggesting to
|
2840 |
|
|
programmers that if they want to guarantee the lack of copying they
|
2841 |
|
|
should use something like the <tt>ref</tt> wrapper.]</i></p>
|
2842 |
|
|
|
2843 |
|
|
<p><i>[Oxford: Matt provided wording.]</i></p>
|
2844 |
|
|
|
2845 |
|
|
|
2846 |
|
|
<hr>
|
2847 |
|
|
<a name="98"><h3>98. Input iterator requirements are badly written</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
2848 |
|
|
<p>Table 72 in 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> specifies semantics for
|
2849 |
|
|
<tt>*r++</tt> of:</p>
|
2850 |
|
|
|
2851 |
|
|
<p> <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
|
2852 |
|
|
|
2853 |
|
|
<p>There are two problems with this. First, the return type is
|
2854 |
|
|
specified to be "T", as opposed to something like "convertible to T".
|
2855 |
|
|
This is too specific: we want to allow *r++ to return an lvalue.</p>
|
2856 |
|
|
|
2857 |
|
|
<p>Second, writing the semantics in terms of code misleadingly
|
2858 |
|
|
suggests that the effects *r++ should precisely replicate the behavior
|
2859 |
|
|
of this code, including side effects. (Does this mean that *r++
|
2860 |
|
|
should invoke the copy constructor exactly as many times as the sample
|
2861 |
|
|
code above would?) See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a> for a similar
|
2862 |
|
|
problem.</p>
|
2863 |
|
|
|
2864 |
|
|
<p><b>Proposed resolution:</b></p>
|
2865 |
|
|
In Table 72 in 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>, change the return type
|
2866 |
|
|
for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".
|
2867 |
|
|
<p><b>Rationale:</b></p>
|
2868 |
|
|
<p>This issue has two parts: the return type, and the number of times
|
2869 |
|
|
the copy constructor is invoked.</p>
|
2870 |
|
|
|
2871 |
|
|
<p>The LWG believes the the first part is a real issue. It's
|
2872 |
|
|
inappropriate for the return type to be specified so much more
|
2873 |
|
|
precisely for *r++ than it is for *r. In particular, if r is of
|
2874 |
|
|
(say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
|
2875 |
|
|
but <tt>int&</tt>.</p>
|
2876 |
|
|
|
2877 |
|
|
<p>The LWG does not believe that the number of times the copy
|
2878 |
|
|
constructor is invoked is a real issue. This can vary in any case,
|
2879 |
|
|
because of language rules on copy constructor elision. That's too
|
2880 |
|
|
much to read into these semantics clauses.</p>
|
2881 |
|
|
|
2882 |
|
|
<p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
|
2883 |
|
|
we're told (24.1/3) that forward iterators satisfy all the requirements
|
2884 |
|
|
of input iterators, we can't impose any requirements in the Input
|
2885 |
|
|
Iterator requirements table that forward iterators don't satisfy.</p>
|
2886 |
|
|
<hr>
|
2887 |
|
|
<a name="103"><h3>103. set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
2888 |
|
|
<p>Set::iterator is described as implementation-defined with a
|
2889 |
|
|
reference to the container requirement; the container requirement says
|
2890 |
|
|
that const_iterator is an iterator pointing to const T and iterator an
|
2891 |
|
|
iterator pointing to T.</p>
|
2892 |
|
|
|
2893 |
|
|
<p>23.1.2 paragraph 2 implies that the keys should not be modified to
|
2894 |
|
|
break the ordering of elements. But that is not clearly
|
2895 |
|
|
specified. Especially considering that the current standard requires
|
2896 |
|
|
that iterator for associative containers be different from
|
2897 |
|
|
const_iterator. Set, for example, has the following: </p>
|
2898 |
|
|
|
2899 |
|
|
<p><tt>typedef implementation defined iterator;<br>
|
2900 |
|
|
// See _lib.container.requirements_</tt></p>
|
2901 |
|
|
|
2902 |
|
|
<p>23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> actually requires that iterator type pointing
|
2903 |
|
|
to T (table 65). Disallowing user modification of keys by changing the
|
2904 |
|
|
standard to require an iterator for associative container to be the
|
2905 |
|
|
same as const_iterator would be overkill since that will unnecessarily
|
2906 |
|
|
significantly restrict the usage of associative container. A class to
|
2907 |
|
|
be used as elements of set, for example, can no longer be modified
|
2908 |
|
|
easily without either redesigning the class (using mutable on fields
|
2909 |
|
|
that have nothing to do with ordering), or using const_cast, which
|
2910 |
|
|
defeats requiring iterator to be const_iterator. The proposed solution
|
2911 |
|
|
goes in line with trusting user knows what he is doing. </p>
|
2912 |
|
|
|
2913 |
|
|
<p><b>Other Options Evaluated:</b> </p>
|
2914 |
|
|
|
2915 |
|
|
<p>Option A. In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 2, after
|
2916 |
|
|
first sentence, and before "In addition,...", add one line:
|
2917 |
|
|
</p>
|
2918 |
|
|
|
2919 |
|
|
<blockquote>
|
2920 |
|
|
<p>Modification of keys shall not change their strict weak ordering. </p>
|
2921 |
|
|
</blockquote>
|
2922 |
|
|
|
2923 |
|
|
<p>Option B. Add three new sentences to 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>:</p>
|
2924 |
|
|
|
2925 |
|
|
<blockquote>
|
2926 |
|
|
<p>At the end of paragraph 5: "Keys in an associative container
|
2927 |
|
|
are immutable." At the end of paragraph 6: "For
|
2928 |
|
|
associative containers where the value type is the same as the key
|
2929 |
|
|
type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
|
2930 |
|
|
constant iterators. It is unspecified whether or not
|
2931 |
|
|
<tt>iterator</tt> and <tt>const_iterator</tt> are the same
|
2932 |
|
|
type."</p>
|
2933 |
|
|
</blockquote>
|
2934 |
|
|
|
2935 |
|
|
<p>Option C. To 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, paragraph 3, which
|
2936 |
|
|
currently reads:</p>
|
2937 |
|
|
|
2938 |
|
|
<blockquote>
|
2939 |
|
|
<p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
|
2940 |
|
|
comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
|
2941 |
|
|
container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
|
2942 |
|
|
== false && comp(k2, k1) == false.</p>
|
2943 |
|
|
</blockquote>
|
2944 |
|
|
|
2945 |
|
|
<p> add the following:</p>
|
2946 |
|
|
|
2947 |
|
|
<blockquote>
|
2948 |
|
|
<p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
|
2949 |
|
|
value whenever it is evaluated. [Note: If k2 is removed from the container and later
|
2950 |
|
|
reinserted, comp(k1, k2) must still return a consistent value but this value may be
|
2951 |
|
|
different than it was the first time k1 and k2 were in the same container. This is
|
2952 |
|
|
intended to allow usage like a string key that contains a filename, where comp compares
|
2953 |
|
|
file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
|
2954 |
|
|
reinserted, comp(k1, k2) must again return a consistent value but this value may be
|
2955 |
|
|
different than it was the previous time k2 was in the container.]</p>
|
2956 |
|
|
</blockquote>
|
2957 |
|
|
<p><b>Proposed resolution:</b></p>
|
2958 |
|
|
<p>Add the following to 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> at
|
2959 |
|
|
the indicated location:</p>
|
2960 |
|
|
|
2961 |
|
|
<blockquote>
|
2962 |
|
|
<p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
|
2963 |
|
|
calling comp(k1, k2) shall always return the same
|
2964 |
|
|
value."</p>
|
2965 |
|
|
<p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
|
2966 |
|
|
<p>At the end of paragraph 6: "For associative containers where the value type is the
|
2967 |
|
|
same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
|
2968 |
|
|
iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
|
2969 |
|
|
are the same type."</p>
|
2970 |
|
|
</blockquote>
|
2971 |
|
|
<p><b>Rationale:</b></p>
|
2972 |
|
|
<p>Several arguments were advanced for and against allowing set elements to be
|
2973 |
|
|
mutable as long as the ordering was not effected. The argument which swayed the
|
2974 |
|
|
LWG was one of safety; if elements were mutable, there would be no compile-time
|
2975 |
|
|
way to detect of a simple user oversight which caused ordering to be
|
2976 |
|
|
modified. There was a report that this had actually happened in practice,
|
2977 |
|
|
and had been painful to diagnose. If users need to modify elements,
|
2978 |
|
|
it is possible to use mutable members or const_cast.</p>
|
2979 |
|
|
|
2980 |
|
|
<p>Simply requiring that keys be immutable is not sufficient, because the comparison
|
2981 |
|
|
object may indirectly (via pointers) operate on values outside of the keys.</p>
|
2982 |
|
|
|
2983 |
|
|
<p>
|
2984 |
|
|
The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
|
2985 |
|
|
to be different types to allow for potential future work in which some
|
2986 |
|
|
member functions might be overloaded between the two types. No such
|
2987 |
|
|
member functions exist now, and the LWG believes that user functionality
|
2988 |
|
|
will not be impaired by permitting the two types to be the same. A
|
2989 |
|
|
function that operates on both iterator types can be defined for
|
2990 |
|
|
<tt>const_iterator</tt> alone, and can rely on the automatic
|
2991 |
|
|
conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
|
2992 |
|
|
</p>
|
2993 |
|
|
|
2994 |
|
|
<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
|
2995 |
|
|
<hr>
|
2996 |
|
|
<a name="106"><h3>106. Numeric library private members are implementation defined</h3></a><p><b>Section:</b> 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
2997 |
|
|
<p>This is the only place in the whole standard where the implementation has to document
|
2998 |
|
|
something private.</p>
|
2999 |
|
|
<p><b>Proposed resolution:</b></p>
|
3000 |
|
|
<p>
|
3001 |
|
|
Remove the comment which says "// remainder implementation defined" from:
|
3002 |
|
|
</p>
|
3003 |
|
|
|
3004 |
|
|
<ul>
|
3005 |
|
|
<li>26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
|
3006 |
|
|
</li>
|
3007 |
|
|
<li>26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
|
3008 |
|
|
</li>
|
3009 |
|
|
<li>26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
|
3010 |
|
|
</li>
|
3011 |
|
|
<li>26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
|
3012 |
|
|
</li>
|
3013 |
|
|
</ul>
|
3014 |
|
|
<hr>
|
3015 |
|
|
<a name="108"><h3>108. Lifetime of exception::what() return unspecified</h3></a><p><b>Section:</b> 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
3016 |
|
|
<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
|
3017 |
|
|
exception::what() is left unspecified. This issue has implications
|
3018 |
|
|
with exception safety of exception handling: some exceptions should
|
3019 |
|
|
not throw bad_alloc.</p>
|
3020 |
|
|
<p><b>Proposed resolution:</b></p>
|
3021 |
|
|
<p>Add to 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> paragraph 9 (exception::what notes
|
3022 |
|
|
clause) the sentence:</p>
|
3023 |
|
|
|
3024 |
|
|
<blockquote>
|
3025 |
|
|
<p>The return value remains valid until the exception object from which it is obtained is
|
3026 |
|
|
destroyed or a non-const member function of the exception object is called.</p>
|
3027 |
|
|
</blockquote>
|
3028 |
|
|
<p><b>Rationale:</b></p>
|
3029 |
|
|
<p>If an exception object has non-const members, they may be used
|
3030 |
|
|
to set internal state that should affect the contents of the string
|
3031 |
|
|
returned by <tt>what()</tt>.
|
3032 |
|
|
</p>
|
3033 |
|
|
<hr>
|
3034 |
|
|
<a name="109"><h3>109. Missing binders for non-const sequence elements</h3></a><p><b>Section:</b> 20.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [lib.binders]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 7 Oct 1998</p>
|
3035 |
|
|
|
3036 |
|
|
<p>There are no versions of binders that apply to non-const elements
|
3037 |
|
|
of a sequence. This makes examples like for_each() using bind2nd() on
|
3038 |
|
|
page 521 of "The C++ Programming Language (3rd)"
|
3039 |
|
|
non-conforming. Suitable versions of the binders need to be added.</p>
|
3040 |
|
|
|
3041 |
|
|
<p>Further discussion from Nico:</p>
|
3042 |
|
|
|
3043 |
|
|
<p>What is probably meant here is shown in the following example:</p>
|
3044 |
|
|
|
3045 |
|
|
<pre>class Elem {
|
3046 |
|
|
public:
|
3047 |
|
|
void print (int i) const { }
|
3048 |
|
|
void modify (int i) { }
|
3049 |
|
|
}; </pre>
|
3050 |
|
|
<pre>int main()
|
3051 |
|
|
{
|
3052 |
|
|
vector<Elem> coll(2);
|
3053 |
|
|
for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::print),42)); // OK
|
3054 |
|
|
for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::modify),42)); // ERROR
|
3055 |
|
|
}</pre>
|
3056 |
|
|
|
3057 |
|
|
<p>The error results from the fact that bind2nd() passes its first
|
3058 |
|
|
argument (the argument of the sequence) as constant reference. See the
|
3059 |
|
|
following typical implementation:</p>
|
3060 |
|
|
|
3061 |
|
|
<blockquote>
|
3062 |
|
|
<pre>template <class Operation>
|
3063 |
|
|
class binder2nd
|
3064 |
|
|
: public unary_function<typename Operation::first_argument_type,
|
3065 |
|
|
typename Operation::result_type> {
|
3066 |
|
|
protected:
|
3067 |
|
|
Operation op;
|
3068 |
|
|
typename Operation::second_argument_type value;
|
3069 |
|
|
public:
|
3070 |
|
|
binder2nd(const Operation& o,
|
3071 |
|
|
const typename Operation::second_argument_type& v)
|
3072 |
|
|
: op(o), value(v) {} </pre>
|
3073 |
|
|
<pre> typename Operation::result_type
|
3074 |
|
|
operator()(const typename Operation::first_argument_type& x) const {
|
3075 |
|
|
return op(x, value);
|
3076 |
|
|
}
|
3077 |
|
|
};</pre>
|
3078 |
|
|
</blockquote>
|
3079 |
|
|
|
3080 |
|
|
<p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
|
3081 |
|
|
|
3082 |
|
|
<blockquote>
|
3083 |
|
|
<pre>template <class Operation>
|
3084 |
|
|
class binder2nd
|
3085 |
|
|
: public unary_function<typename Operation::first_argument_type,
|
3086 |
|
|
typename Operation::result_type> {
|
3087 |
|
|
protected:
|
3088 |
|
|
Operation op;
|
3089 |
|
|
typename Operation::second_argument_type value;
|
3090 |
|
|
public:
|
3091 |
|
|
binder2nd(const Operation& o,
|
3092 |
|
|
const typename Operation::second_argument_type& v)
|
3093 |
|
|
: op(o), value(v) {} </pre>
|
3094 |
|
|
<pre> typename Operation::result_type
|
3095 |
|
|
operator()(const typename Operation::first_argument_type& x) const {
|
3096 |
|
|
return op(x, value);
|
3097 |
|
|
}
|
3098 |
|
|
typename Operation::result_type
|
3099 |
|
|
operator()(typename Operation::first_argument_type& x) const {
|
3100 |
|
|
return op(x, value);
|
3101 |
|
|
}
|
3102 |
|
|
};</pre>
|
3103 |
|
|
</blockquote>
|
3104 |
|
|
<p><b>Proposed resolution:</b></p>
|
3105 |
|
|
|
3106 |
|
|
<p><b>Howard believes there is a flaw</b> in this resolution.
|
3107 |
|
|
See c++std-lib-9127. We may need to reopen this issue.</p>
|
3108 |
|
|
|
3109 |
|
|
<p>In 20.3.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binder.1st"> [lib.binder.1st]</a> in the declaration of binder1st after:</p>
|
3110 |
|
|
<blockquote>
|
3111 |
|
|
<p><tt>typename Operation::result_type<br>
|
3112 |
|
|
operator()(const typename Operation::second_argument_type& x) const;</tt></p>
|
3113 |
|
|
</blockquote>
|
3114 |
|
|
<p>insert:</p>
|
3115 |
|
|
<blockquote>
|
3116 |
|
|
<p><tt>typename Operation::result_type<br>
|
3117 |
|
|
operator()(typename Operation::second_argument_type& x) const;</tt></p>
|
3118 |
|
|
</blockquote>
|
3119 |
|
|
<p>In 20.3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binder.2nd"> [lib.binder.2nd]</a> in the declaration of binder2nd after:</p>
|
3120 |
|
|
<blockquote>
|
3121 |
|
|
<p><tt>typename Operation::result_type<br>
|
3122 |
|
|
operator()(const typename Operation::first_argument_type& x) const;</tt></p>
|
3123 |
|
|
</blockquote>
|
3124 |
|
|
<p>insert:</p>
|
3125 |
|
|
<blockquote>
|
3126 |
|
|
<p><tt>typename Operation::result_type<br>
|
3127 |
|
|
operator()(typename Operation::first_argument_type& x) const;</tt></p>
|
3128 |
|
|
</blockquote>
|
3129 |
|
|
|
3130 |
|
|
<p><i>[Kona: The LWG discussed this at some length.It was agreed that
|
3131 |
|
|
this is a mistake in the design, but there was no consensus on whether
|
3132 |
|
|
it was a defect in the Standard. Straw vote: NAD - 5. Accept
|
3133 |
|
|
proposed resolution - 3. Leave open - 6.]</i></p>
|
3134 |
|
|
|
3135 |
|
|
<p><i>[Copenhagen: It was generally agreed that this was a defect.
|
3136 |
|
|
Strap poll: NAD - 0. Accept proposed resolution - 10.
|
3137 |
|
|
Leave open - 1.]</i></p>
|
3138 |
|
|
|
3139 |
|
|
<hr>
|
3140 |
|
|
<a name="110"><h3>110. istreambuf_iterator::equal not const</h3></a><p><b>Section:</b> 24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 15 Oct 1998</p>
|
3141 |
|
|
<p>Member istreambuf_iterator<>::equal is not declared
|
3142 |
|
|
"const", yet 24.5.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::op=="> [lib.istreambuf.iterator::op==]</a> says that operator==,
|
3143 |
|
|
which is const, calls it. This is contradictory. </p>
|
3144 |
|
|
<p><b>Proposed resolution:</b></p>
|
3145 |
|
|
<p>In 24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a> and also in 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>,
|
3146 |
|
|
replace:</p>
|
3147 |
|
|
|
3148 |
|
|
<blockquote>
|
3149 |
|
|
<pre>bool equal(istreambuf_iterator& b);</pre>
|
3150 |
|
|
</blockquote>
|
3151 |
|
|
|
3152 |
|
|
<p>with:</p>
|
3153 |
|
|
|
3154 |
|
|
<blockquote>
|
3155 |
|
|
<pre>bool equal(const istreambuf_iterator& b) const;</pre>
|
3156 |
|
|
</blockquote>
|
3157 |
|
|
<hr>
|
3158 |
|
|
<a name="112"><h3>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p><b>Section:</b> 24.5.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Oct 1998</p>
|
3159 |
|
|
<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
|
3160 |
|
|
constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
|
3161 |
|
|
reads "<i>s</i> is not null". However, <i>s</i> is a
|
3162 |
|
|
reference, and references can't be null. </p>
|
3163 |
|
|
<p><b>Proposed resolution:</b></p>
|
3164 |
|
|
<p>In 24.5.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>:</p>
|
3165 |
|
|
|
3166 |
|
|
<p>Move the current paragraph 1, which reads "Requires: s is not
|
3167 |
|
|
null.", from the first constructor to the second constructor.</p>
|
3168 |
|
|
|
3169 |
|
|
<p>Insert a new paragraph 1 Requires clause for the first constructor
|
3170 |
|
|
reading:</p>
|
3171 |
|
|
|
3172 |
|
|
<blockquote>
|
3173 |
|
|
<p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
|
3174 |
|
|
</blockquote>
|
3175 |
|
|
<hr>
|
3176 |
|
|
<a name="114"><h3>114. Placement forms example in error twice</h3></a><p><b>Section:</b> 18.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 28 Oct 1998</p>
|
3177 |
|
|
<p>Section 18.4.1.3 contains the following example: </p>
|
3178 |
|
|
|
3179 |
|
|
<pre>[Example: This can be useful for constructing an object at a known address:
|
3180 |
|
|
char place[sizeof(Something)];
|
3181 |
|
|
Something* p = new (place) Something();
|
3182 |
|
|
-end example]</pre>
|
3183 |
|
|
|
3184 |
|
|
<p>First code line: "place" need not have any special alignment, and the
|
3185 |
|
|
following constructor could fail due to misaligned data.</p>
|
3186 |
|
|
|
3187 |
|
|
<p>Second code line: Aren't the parens on Something() incorrect? [Dublin: the LWG
|
3188 |
|
|
believes the () are correct.]</p>
|
3189 |
|
|
|
3190 |
|
|
<p>Examples are not normative, but nevertheless should not show code that is invalid or
|
3191 |
|
|
likely to fail.</p>
|
3192 |
|
|
<p><b>Proposed resolution:</b></p>
|
3193 |
|
|
<p>Replace the <u> first line of code</u> in the example in
|
3194 |
|
|
18.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> with:
|
3195 |
|
|
</p>
|
3196 |
|
|
|
3197 |
|
|
<blockquote>
|
3198 |
|
|
<pre>void* place = operator new(sizeof(Something));</pre>
|
3199 |
|
|
</blockquote>
|
3200 |
|
|
<hr>
|
3201 |
|
|
<a name="115"><h3>115. Typo in strstream constructors</h3></a><p><b>Section:</b> D.7.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstream.cons"> [depr.strstream.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 2 Nov 1998</p>
|
3202 |
|
|
<p>D.7.4.1 strstream constructors paragraph 2 says: </p>
|
3203 |
|
|
|
3204 |
|
|
<blockquote>
|
3205 |
|
|
<p>Effects: Constructs an object of class strstream, initializing the base class with
|
3206 |
|
|
iostream(& sb) and initializing sb with one of the two constructors: </p>
|
3207 |
|
|
<p>- If mode&app==0, then s shall designate the first element of an array of n
|
3208 |
|
|
elements. The constructor is strstreambuf(s, n, s). </p>
|
3209 |
|
|
<p>- If mode&app==0, then s shall designate the first element of an array of n
|
3210 |
|
|
elements that contains an NTBS whose first element is designated by s. The constructor is
|
3211 |
|
|
strstreambuf(s, n, s+std::strlen(s)).</p>
|
3212 |
|
|
</blockquote>
|
3213 |
|
|
|
3214 |
|
|
<p>Notice the second condition is the same as the first. I think the second condition
|
3215 |
|
|
should be "If mode&app==app", or "mode&app!=0", meaning that
|
3216 |
|
|
the append bit is set.</p>
|
3217 |
|
|
<p><b>Proposed resolution:</b></p>
|
3218 |
|
|
<p>In D.7.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ostrstream.cons"> [depr.ostrstream.cons]</a> paragraph 2 and D.7.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstream.cons"> [depr.strstream.cons]</a>
|
3219 |
|
|
paragraph 2, change the first condition to <tt>(mode&app)==0</tt>
|
3220 |
|
|
and the second condition to <tt>(mode&app)!=0</tt>.</p>
|
3221 |
|
|
<hr>
|
3222 |
|
|
<a name="117"><h3>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3></a><p><b>Section:</b> 27.6.2.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.arithmetic"> [lib.ostream.inserters.arithmetic]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Nov 1998</p>
|
3223 |
|
|
<p>The <b>effects</b> clause for numeric inserters says that
|
3224 |
|
|
insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
|
3225 |
|
|
<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
|
3226 |
|
|
int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
|
3227 |
|
|
<tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
|
3228 |
|
|
delegated to <tt>num_put</tt>, and that insertion is performed as if
|
3229 |
|
|
through the following code fragment: </p>
|
3230 |
|
|
|
3231 |
|
|
<pre>bool failed = use_facet<
|
3232 |
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
3233 |
|
|
>(getloc()).put(*this, *this, fill(), val). failed();</pre>
|
3234 |
|
|
|
3235 |
|
|
<p>This doesn't work, because <tt>num_put<></tt>::put is only
|
3236 |
|
|
overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
|
3237 |
|
|
long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
|
3238 |
|
|
void*</tt>. That is, the code fragment in the standard is incorrect
|
3239 |
|
|
(it is diagnosed as ambiguous at compile time) for the types
|
3240 |
|
|
<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
|
3241 |
|
|
int</tt>, and <tt>float</tt>. </p>
|
3242 |
|
|
|
3243 |
|
|
<p>We must either add new member functions to <tt>num_put</tt>, or
|
3244 |
|
|
else change the description in <tt>ostream</tt> so that it only calls
|
3245 |
|
|
functions that are actually there. I prefer the latter. </p>
|
3246 |
|
|
<p><b>Proposed resolution:</b></p>
|
3247 |
|
|
<p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
|
3248 |
|
|
|
3249 |
|
|
<blockquote>
|
3250 |
|
|
<p>
|
3251 |
|
|
The classes num_get<> and num_put<> handle localedependent numeric
|
3252 |
|
|
formatting and parsing. These inserter functions use the imbued
|
3253 |
|
|
locale value to perform numeric formatting. When val is of type bool,
|
3254 |
|
|
long, unsigned long, double, long double, or const void*, the
|
3255 |
|
|
formatting conversion occurs as if it performed the following code
|
3256 |
|
|
fragment:
|
3257 |
|
|
</p>
|
3258 |
|
|
|
3259 |
|
|
<pre>bool failed = use_facet<
|
3260 |
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
3261 |
|
|
>(getloc()).put(*this, *this, fill(), val). failed();
|
3262 |
|
|
</pre>
|
3263 |
|
|
|
3264 |
|
|
<p>
|
3265 |
|
|
When val is of type short the formatting conversion occurs as if it
|
3266 |
|
|
performed the following code fragment:
|
3267 |
|
|
</p>
|
3268 |
|
|
|
3269 |
|
|
<pre>ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
|
3270 |
|
|
bool failed = use_facet<
|
3271 |
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
3272 |
|
|
>(getloc()).put(*this, *this, fill(),
|
3273 |
|
|
baseflags == ios_base::oct || baseflags == ios_base::hex
|
3274 |
|
|
? static_cast<long>(static_cast<unsigned short>(val))
|
3275 |
|
|
: static_cast<long>(val)). failed();
|
3276 |
|
|
</pre>
|
3277 |
|
|
|
3278 |
|
|
<p>
|
3279 |
|
|
When val is of type int the formatting conversion occurs as if it performed
|
3280 |
|
|
the following code fragment:
|
3281 |
|
|
</p>
|
3282 |
|
|
|
3283 |
|
|
<pre>ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
|
3284 |
|
|
bool failed = use_facet<
|
3285 |
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
3286 |
|
|
>(getloc()).put(*this, *this, fill(),
|
3287 |
|
|
baseflags == ios_base::oct || baseflags == ios_base::hex
|
3288 |
|
|
? static_cast<long>(static_cast<unsigned int>(val))
|
3289 |
|
|
: static_cast<long>(val)). failed();
|
3290 |
|
|
</pre>
|
3291 |
|
|
|
3292 |
|
|
<p>
|
3293 |
|
|
When val is of type unsigned short or unsigned int the formatting conversion
|
3294 |
|
|
occurs as if it performed the following code fragment:
|
3295 |
|
|
</p>
|
3296 |
|
|
|
3297 |
|
|
<pre>bool failed = use_facet<
|
3298 |
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
3299 |
|
|
>(getloc()).put(*this, *this, fill(), static_cast<unsigned long>(val)).
|
3300 |
|
|
failed();
|
3301 |
|
|
</pre>
|
3302 |
|
|
|
3303 |
|
|
<p>
|
3304 |
|
|
When val is of type float the formatting conversion occurs as if it
|
3305 |
|
|
performed the following code fragment:
|
3306 |
|
|
</p>
|
3307 |
|
|
|
3308 |
|
|
<pre>bool failed = use_facet<
|
3309 |
|
|
num_put<charT,ostreambuf_iterator<charT,traits> >
|
3310 |
|
|
>(getloc()).put(*this, *this, fill(), static_cast<double>(val)).
|
3311 |
|
|
failed();
|
3312 |
|
|
</pre>
|
3313 |
|
|
|
3314 |
|
|
</blockquote>
|
3315 |
|
|
|
3316 |
|
|
<p><i>[post-Toronto: This differs from the previous proposed
|
3317 |
|
|
resolution; PJP provided the new wording. The differences are in
|
3318 |
|
|
signed short and int output.]</i></p>
|
3319 |
|
|
<p><b>Rationale:</b></p>
|
3320 |
|
|
<p>The original proposed resolution was to cast int and short to long,
|
3321 |
|
|
unsigned int and unsigned short to unsigned long, and float to double,
|
3322 |
|
|
thus ensuring that we don't try to use nonexistent num_put<>
|
3323 |
|
|
member functions. The current proposed resolution is more
|
3324 |
|
|
complicated, but gives more expected results for hex and octal output
|
3325 |
|
|
of signed short and signed int. (On a system with 16-bit short, for
|
3326 |
|
|
example, printing short(-1) in hex format should yield 0xffff.)</p>
|
3327 |
|
|
<hr>
|
3328 |
|
|
<a name="118"><h3>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3></a><p><b>Section:</b> 27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Nov 1998</p>
|
3329 |
|
|
<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
|
3330 |
|
|
<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
|
3331 |
|
|
<tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
|
3332 |
|
|
formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
|
3333 |
|
|
|
3334 |
|
|
<pre>typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
|
3335 |
|
|
iostate err = 0;
|
3336 |
|
|
use_facet< numget >(loc).get(*this, 0, *this, err, val);
|
3337 |
|
|
setstate(err);</pre>
|
3338 |
|
|
|
3339 |
|
|
<p>According to section 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, however,
|
3340 |
|
|
<tt>num_get<>::get()</tt> is only overloaded for the types
|
3341 |
|
|
<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
|
3342 |
|
|
int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
|
3343 |
|
|
<tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
|
3344 |
|
|
<tt>void*</tt>. Comparing the lists from the two sections, we find
|
3345 |
|
|
that 27.6.1.2.2 is using a nonexistent function for types
|
3346 |
|
|
<tt>short</tt> and <tt>int</tt>. </p>
|
3347 |
|
|
<p><b>Proposed resolution:</b></p>
|
3348 |
|
|
<p>In 27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> Arithmetic Extractors, remove the
|
3349 |
|
|
two lines (1st and 3rd) which read:</p>
|
3350 |
|
|
<blockquote>
|
3351 |
|
|
<pre>operator>>(short& val);
|
3352 |
|
|
...
|
3353 |
|
|
operator>>(int& val);</pre>
|
3354 |
|
|
</blockquote>
|
3355 |
|
|
|
3356 |
|
|
<p>And add the following at the end of that section (27.6.1.2.2) :</p>
|
3357 |
|
|
|
3358 |
|
|
<blockquote>
|
3359 |
|
|
<pre>operator>>(short& val);</pre>
|
3360 |
|
|
<p>The conversion occurs as if performed by the following code fragment (using
|
3361 |
|
|
the same notation as for the preceding code fragment):</p>
|
3362 |
|
|
<pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
|
3363 |
|
|
iostate err = 0;
|
3364 |
|
|
long lval;
|
3365 |
|
|
use_facet< numget >(loc).get(*this, 0, *this, err, lval);
|
3366 |
|
|
if (err == 0
|
3367 |
|
|
&& (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
|
3368 |
|
|
err = ios_base::failbit;
|
3369 |
|
|
setstate(err);</pre>
|
3370 |
|
|
<pre>operator>>(int& val);</pre>
|
3371 |
|
|
<p>The conversion occurs as if performed by the following code fragment (using
|
3372 |
|
|
the same notation as for the preceding code fragment):</p>
|
3373 |
|
|
<pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
|
3374 |
|
|
iostate err = 0;
|
3375 |
|
|
long lval;
|
3376 |
|
|
use_facet< numget >(loc).get(*this, 0, *this, err, lval);
|
3377 |
|
|
if (err == 0
|
3378 |
|
|
&& (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
|
3379 |
|
|
err = ios_base::failbit;
|
3380 |
|
|
setstate(err);</pre>
|
3381 |
|
|
</blockquote>
|
3382 |
|
|
|
3383 |
|
|
<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
|
3384 |
|
|
<hr>
|
3385 |
|
|
<a name="119"><h3>119. Should virtual functions be allowed to strengthen the exception specification?</h3></a><p><b>Section:</b> 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
3386 |
|
|
<p>Section 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p>
|
3387 |
|
|
|
3388 |
|
|
<p>"An implementation may strengthen the exception-specification
|
3389 |
|
|
for a function by removing listed exceptions." </p>
|
3390 |
|
|
|
3391 |
|
|
<p>The problem is that if an implementation is allowed to do this for
|
3392 |
|
|
virtual functions, then a library user cannot write a class that
|
3393 |
|
|
portably derives from that class. </p>
|
3394 |
|
|
|
3395 |
|
|
<p>For example, this would not compile if ios_base::failure::~failure
|
3396 |
|
|
had an empty exception specification: </p>
|
3397 |
|
|
|
3398 |
|
|
<pre>#include <ios>
|
3399 |
|
|
#include <string>
|
3400 |
|
|
|
3401 |
|
|
class D : public std::ios_base::failure {
|
3402 |
|
|
public:
|
3403 |
|
|
D(const std::string&);
|
3404 |
|
|
~D(); // error - exception specification must be compatible with
|
3405 |
|
|
// overridden virtual function ios_base::failure::~failure()
|
3406 |
|
|
};</pre>
|
3407 |
|
|
<p><b>Proposed resolution:</b></p>
|
3408 |
|
|
<p>Change Section 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> from:</p>
|
3409 |
|
|
|
3410 |
|
|
<p> "may strengthen the
|
3411 |
|
|
exception-specification for a function"</p>
|
3412 |
|
|
|
3413 |
|
|
<p>to:</p>
|
3414 |
|
|
|
3415 |
|
|
<p> "may strengthen the
|
3416 |
|
|
exception-specification for a non-virtual function". </p>
|
3417 |
|
|
<hr>
|
3418 |
|
|
<a name="120"><h3>120. Can an implementor add specializations?</h3></a><p><b>Section:</b> 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
3419 |
|
|
|
3420 |
|
|
<p>The original issue asked whether a library implementor could
|
3421 |
|
|
specialize standard library templates for built-in types. (This was
|
3422 |
|
|
an issue because users are permitted to explicitly instantiate
|
3423 |
|
|
standard library templates.)</p>
|
3424 |
|
|
|
3425 |
|
|
<p>Specializations are no longer a problem, because of the resolution
|
3426 |
|
|
to core issue 259. Under the proposed resolution, it will be legal
|
3427 |
|
|
for a translation unit to contain both a specialization and an
|
3428 |
|
|
explicit instantiation of the same template, provided that the
|
3429 |
|
|
specialization comes first. In such a case, the explicit
|
3430 |
|
|
instantiation will be ignored. Further discussion of library issue
|
3431 |
|
|
120 assumes that the core 259 resolution will be adopted.</p>
|
3432 |
|
|
|
3433 |
|
|
<p>However, as noted in lib-7047, one piece of this issue still
|
3434 |
|
|
remains: what happens if a standard library implementor explicitly
|
3435 |
|
|
instantiates a standard library templates? It's illegal for a program
|
3436 |
|
|
to contain two different explicit instantiations of the same template
|
3437 |
|
|
for the same type in two different translation units (ODR violation),
|
3438 |
|
|
and the core working group doesn't believe it is practical to relax
|
3439 |
|
|
that restriction.</p>
|
3440 |
|
|
|
3441 |
|
|
<p>The issue, then, is: are users allowed to explicitly instantiate
|
3442 |
|
|
standard library templates for non-user defined types? The status quo
|
3443 |
|
|
answer is 'yes'. Changing it to 'no' would give library implementors
|
3444 |
|
|
more freedom.</p>
|
3445 |
|
|
|
3446 |
|
|
<p>This is an issue because, for performance reasons, library
|
3447 |
|
|
implementors often need to explicitly instantiate standard library
|
3448 |
|
|
templates. (for example, std::basic_string<char>) Does giving
|
3449 |
|
|
users freedom to explicitly instantiate standard library templates for
|
3450 |
|
|
non-user defined types make it impossible or painfully difficult for
|
3451 |
|
|
library implementors to do this?</p>
|
3452 |
|
|
|
3453 |
|
|
<p>John Spicer suggests, in lib-8957, that library implementors have a
|
3454 |
|
|
mechanism they can use for explicit instantiations that doesn't
|
3455 |
|
|
prevent users from performing their own explicit instantiations: put
|
3456 |
|
|
each explicit instantiation in its own object file. (Different
|
3457 |
|
|
solutions might be necessary for Unix DSOs or MS-Windows DLLs.) On
|
3458 |
|
|
some platforms, library implementors might not need to do anything
|
3459 |
|
|
special: the "undefined behavior" that results from having two
|
3460 |
|
|
different explicit instantiations might be harmless.</p>
|
3461 |
|
|
|
3462 |
|
|
<p><b>Proposed resolution:</b></p>
|
3463 |
|
|
<p>Append to 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1: </p>
|
3464 |
|
|
<blockquote>
|
3465 |
|
|
A program may explicitly instantiate any templates in the standard
|
3466 |
|
|
library only if the declaration depends on the name of a user-defined
|
3467 |
|
|
type of external linkage and the instantiation meets the standard library
|
3468 |
|
|
requirements for the original template.
|
3469 |
|
|
</blockquote>
|
3470 |
|
|
|
3471 |
|
|
<p><i>[Kona: changed the wording from "a user-defined name" to "the name of
|
3472 |
|
|
a user-defined type"]</i></p>
|
3473 |
|
|
|
3474 |
|
|
<p><b>Rationale:</b></p>
|
3475 |
|
|
<p>The LWG considered another possible resolution:</p>
|
3476 |
|
|
<blockquote>
|
3477 |
|
|
<p>In light of the resolution to core issue 259, no normative changes
|
3478 |
|
|
in the library clauses are necessary. Add the following non-normative
|
3479 |
|
|
note to the end of 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1:</p>
|
3480 |
|
|
<blockquote>
|
3481 |
|
|
[<i>Note:</i> A program may explicitly instantiate standard library
|
3482 |
|
|
templates, even when an explicit instantiation does not depend on
|
3483 |
|
|
a user-defined name. <i>--end note</i>]
|
3484 |
|
|
</blockquote>
|
3485 |
|
|
</blockquote>
|
3486 |
|
|
|
3487 |
|
|
<p>The LWG rejected this because it was believed that it would make
|
3488 |
|
|
it unnecessarily difficult for library implementors to write
|
3489 |
|
|
high-quality implementations. A program may not include an
|
3490 |
|
|
explicit instantiation of the same template, for the same template
|
3491 |
|
|
arguments, in two different translation units. If users are
|
3492 |
|
|
allowed to provide explicit instantiations of Standard Library
|
3493 |
|
|
templates for built-in types, then library implementors aren't,
|
3494 |
|
|
at least not without nonportable tricks.</p>
|
3495 |
|
|
|
3496 |
|
|
<p>The most serious problem is a class template that has writeable
|
3497 |
|
|
static member variables. Unfortunately, such class templates are
|
3498 |
|
|
important and, in existing Standard Library implementations, are
|
3499 |
|
|
often explicitly specialized by library implementors: locale facets,
|
3500 |
|
|
which have a writeable static member variable <tt>id</tt>. If a
|
3501 |
|
|
user's explicit instantiation collided with the implementations
|
3502 |
|
|
explicit instantiation, iostream initialization could cause locales
|
3503 |
|
|
to be constructed in an inconsistent state.</p>
|
3504 |
|
|
|
3505 |
|
|
<p>One proposed implementation technique was for Standard Library
|
3506 |
|
|
implementors to provide explicit instantiations in separate object
|
3507 |
|
|
files, so that they would not be picked up by the linker when the
|
3508 |
|
|
user also provides an explicit instantiation. However, this
|
3509 |
|
|
technique only applies for Standard Library implementations that
|
3510 |
|
|
are packaged as static archives. Most Standard Library
|
3511 |
|
|
implementations nowadays are packaged as dynamic libraries, so this
|
3512 |
|
|
technique would not apply.</p>
|
3513 |
|
|
|
3514 |
|
|
<p>The Committee is now considering standardization of dynamic
|
3515 |
|
|
linking. If there are such changes in the future, it may be
|
3516 |
|
|
appropriate to revisit this issue later.</p>
|
3517 |
|
|
<hr>
|
3518 |
|
|
<a name="122"><h3>122. streambuf/wstreambuf description should not say they are specializations</h3></a><p><b>Section:</b> 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
3519 |
|
|
<p>Section 27.5.2 describes the streambuf classes this way: </p>
|
3520 |
|
|
|
3521 |
|
|
<blockquote>
|
3522 |
|
|
|
3523 |
|
|
<p>The class streambuf is a specialization of the template class basic_streambuf
|
3524 |
|
|
specialized for the type char. </p>
|
3525 |
|
|
|
3526 |
|
|
<p>The class wstreambuf is a specialization of the template class basic_streambuf
|
3527 |
|
|
specialized for the type wchar_t. </p>
|
3528 |
|
|
|
3529 |
|
|
</blockquote>
|
3530 |
|
|
|
3531 |
|
|
<p>This implies that these classes must be template specializations, not typedefs. </p>
|
3532 |
|
|
|
3533 |
|
|
<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
|
3534 |
|
|
<p><b>Proposed resolution:</b></p>
|
3535 |
|
|
<p>Remove 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> paragraphs 2 and 3 (the above two
|
3536 |
|
|
sentences). </p>
|
3537 |
|
|
<p><b>Rationale:</b></p>
|
3538 |
|
|
<p>The <tt>streambuf</tt> synopsis already has a declaration for the
|
3539 |
|
|
typedefs and that is sufficient. </p>
|
3540 |
|
|
<hr>
|
3541 |
|
|
<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.3.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.3.8.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.3.9.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998 </p>
|
3542 |
|
|
<p>One of the operator= in the valarray helper arrays is const and one
|
3543 |
|
|
is not. For example, look at slice_array. This operator= in Section
|
3544 |
|
|
26.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> is const: </p>
|
3545 |
|
|
|
3546 |
|
|
<p> <tt>void operator=(const valarray<T>&) const;</tt> </p>
|
3547 |
|
|
|
3548 |
|
|
<p>but this one in Section 26.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> is not: </p>
|
3549 |
|
|
|
3550 |
|
|
<p> <tt>void operator=(const T&); </tt></p>
|
3551 |
|
|
|
3552 |
|
|
<p>The description of the semantics for these two functions is similar. </p>
|
3553 |
|
|
<p><b>Proposed resolution:</b></p>
|
3554 |
|
|
|
3555 |
|
|
<p>26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> Template class slice_array</p>
|
3556 |
|
|
<blockquote>
|
3557 |
|
|
|
3558 |
|
|
<p>In the class template definition for slice_array, replace the member
|
3559 |
|
|
function declaration</p>
|
3560 |
|
|
<pre> void operator=(const T&);
|
3561 |
|
|
</pre>
|
3562 |
|
|
<p>with</p>
|
3563 |
|
|
<pre> void operator=(const T&) const;
|
3564 |
|
|
</pre>
|
3565 |
|
|
</blockquote>
|
3566 |
|
|
|
3567 |
|
|
<p>26.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> slice_array fill function</p>
|
3568 |
|
|
<blockquote>
|
3569 |
|
|
|
3570 |
|
|
<p>Change the function declaration</p>
|
3571 |
|
|
<pre> void operator=(const T&);
|
3572 |
|
|
</pre>
|
3573 |
|
|
<p>to</p>
|
3574 |
|
|
<pre> void operator=(const T&) const;
|
3575 |
|
|
</pre>
|
3576 |
|
|
</blockquote>
|
3577 |
|
|
|
3578 |
|
|
<p>26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> Template class gslice_array</p>
|
3579 |
|
|
<blockquote>
|
3580 |
|
|
|
3581 |
|
|
<p>In the class template definition for gslice_array, replace the member
|
3582 |
|
|
function declaration</p>
|
3583 |
|
|
<pre> void operator=(const T&);
|
3584 |
|
|
</pre>
|
3585 |
|
|
<p>with</p>
|
3586 |
|
|
<pre> void operator=(const T&) const;
|
3587 |
|
|
</pre>
|
3588 |
|
|
</blockquote>
|
3589 |
|
|
|
3590 |
|
|
<p>26.3.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a> gslice_array fill function</p>
|
3591 |
|
|
<blockquote>
|
3592 |
|
|
|
3593 |
|
|
<p>Change the function declaration</p>
|
3594 |
|
|
<pre> void operator=(const T&);
|
3595 |
|
|
</pre>
|
3596 |
|
|
<p>to</p>
|
3597 |
|
|
<pre> void operator=(const T&) const;
|
3598 |
|
|
</pre>
|
3599 |
|
|
</blockquote>
|
3600 |
|
|
|
3601 |
|
|
<p>26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> Template class mask_array</p>
|
3602 |
|
|
<blockquote>
|
3603 |
|
|
|
3604 |
|
|
<p>In the class template definition for mask_array, replace the member
|
3605 |
|
|
function declaration</p>
|
3606 |
|
|
<pre> void operator=(const T&);
|
3607 |
|
|
</pre>
|
3608 |
|
|
<p>with</p>
|
3609 |
|
|
<pre> void operator=(const T&) const;
|
3610 |
|
|
</pre>
|
3611 |
|
|
</blockquote>
|
3612 |
|
|
|
3613 |
|
|
<p>26.3.8.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a> mask_array fill function</p>
|
3614 |
|
|
<blockquote>
|
3615 |
|
|
|
3616 |
|
|
<p>Change the function declaration</p>
|
3617 |
|
|
<pre> void operator=(const T&);
|
3618 |
|
|
</pre>
|
3619 |
|
|
<p>to</p>
|
3620 |
|
|
<pre> void operator=(const T&) const;
|
3621 |
|
|
</pre>
|
3622 |
|
|
</blockquote>
|
3623 |
|
|
|
3624 |
|
|
<p>26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> Template class indirect_array</p>
|
3625 |
|
|
<blockquote>
|
3626 |
|
|
|
3627 |
|
|
<p>In the class template definition for indirect_array, replace the member
|
3628 |
|
|
function declaration</p>
|
3629 |
|
|
<pre> void operator=(const T&);
|
3630 |
|
|
</pre>
|
3631 |
|
|
<p>with</p>
|
3632 |
|
|
<pre> void operator=(const T&) const;
|
3633 |
|
|
</pre>
|
3634 |
|
|
</blockquote>
|
3635 |
|
|
|
3636 |
|
|
<p>26.3.9.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> indirect_array fill function</p>
|
3637 |
|
|
<blockquote>
|
3638 |
|
|
|
3639 |
|
|
<p>Change the function declaration</p>
|
3640 |
|
|
<pre> void operator=(const T&);
|
3641 |
|
|
</pre>
|
3642 |
|
|
<p>to</p>
|
3643 |
|
|
<pre> void operator=(const T&) const;
|
3644 |
|
|
</pre>
|
3645 |
|
|
</blockquote>
|
3646 |
|
|
|
3647 |
|
|
|
3648 |
|
|
<p><i>[Redmond: Robert provided wording.]</i></p>
|
3649 |
|
|
|
3650 |
|
|
<p><b>Rationale:</b></p>
|
3651 |
|
|
<p>There's no good reason for one version of operator= being const and
|
3652 |
|
|
another one not. Because of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, this now
|
3653 |
|
|
matters: these functions are now callable in more circumstances. In
|
3654 |
|
|
many existing implementations, both versions are already const.</p>
|
3655 |
|
|
<hr>
|
3656 |
|
|
<a name="124"><h3>124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*</h3></a><p><b>Section:</b> 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
3657 |
|
|
<p>In Section 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>
|
3658 |
|
|
ctype_byname<charT>::do_scan_is() and do_scan_not() are declared
|
3659 |
|
|
to return a const char* not a const charT*. </p>
|
3660 |
|
|
<p><b>Proposed resolution:</b></p>
|
3661 |
|
|
<p>Change Section 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <tt>do_scan_is()</tt> and
|
3662 |
|
|
<tt>do_scan_not()</tt> to return a <tt> const
|
3663 |
|
|
charT*</tt>. </p>
|
3664 |
|
|
<hr>
|
3665 |
|
|
<a name="125"></a><h3><a name="125">125. valarray<T>::operator!() return type is inconsistent</a></h3><p><b>Section:</b> 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
3666 |
|
|
<p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray<T>::operator!() is
|
3667 |
|
|
declared to return a valarray<T>, but in Section 26.3.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray<bool>. The
|
3668 |
|
|
latter appears to be correct. </p>
|
3669 |
|
|
<p><b>Proposed resolution:</b></p>
|
3670 |
|
|
<p>Change in Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> the declaration of
|
3671 |
|
|
<tt>operator!()</tt> so that the return type is
|
3672 |
|
|
<tt>valarray<bool></tt>. </p>
|
3673 |
|
|
<hr>
|
3674 |
|
|
<a name="126"><h3>126. typos in Effects clause of ctype::do_narrow()</h3></a><p><b>Section:</b> 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
3675 |
|
|
<p>Typos in 22.2.1.1.2 need to be fixed.</p>
|
3676 |
|
|
<p><b>Proposed resolution:</b></p>
|
3677 |
|
|
<p>In Section 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> change: </p>
|
3678 |
|
|
|
3679 |
|
|
<pre> do_widen(do_narrow(c),0) == c</pre>
|
3680 |
|
|
|
3681 |
|
|
<p>to:</p>
|
3682 |
|
|
|
3683 |
|
|
<pre> do_widen(do_narrow(c,0)) == c</pre>
|
3684 |
|
|
|
3685 |
|
|
<p>and change:</p>
|
3686 |
|
|
|
3687 |
|
|
<pre> (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
|
3688 |
|
|
|
3689 |
|
|
<p>to:</p>
|
3690 |
|
|
|
3691 |
|
|
<pre> (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
|
3692 |
|
|
<hr>
|
3693 |
|
|
<a name="127"><h3>127. auto_ptr<> conversion issues</h3></a><p><b>Section:</b> 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Colvin <b>Date:</b> 17 Feb 1999</p>
|
3694 |
|
|
<p>There are two problems with the current <tt>auto_ptr</tt> wording
|
3695 |
|
|
in the standard: </p>
|
3696 |
|
|
|
3697 |
|
|
<p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
|
3698 |
|
|
because <tt>auto_ptr<Derived>::auto_ptr_ref</tt> is unrelated to
|
3699 |
|
|
<tt>auto_ptr<Base>::auto_ptr_ref</tt>. <i>Also submitted by
|
3700 |
|
|
Nathan Myers, with the same proposed resolution.</i></p>
|
3701 |
|
|
|
3702 |
|
|
<p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
|
3703 |
|
|
<tt>auto_ptr_ref</tt> argument. </p>
|
3704 |
|
|
|
3705 |
|
|
<p>I have discussed these problems with my proposal coauthor, Bill
|
3706 |
|
|
Gibbons, and with some compiler and library implementors, and we
|
3707 |
|
|
believe that these problems are not desired or desirable implications
|
3708 |
|
|
of the standard. </p>
|
3709 |
|
|
|
3710 |
|
|
<p>25 Aug 1999: The proposed resolution now reflects changes suggested
|
3711 |
|
|
by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
|
3712 |
|
|
"assignment operator" to "public assignment
|
3713 |
|
|
operator", 2) changed effects to specify use of release(), 3)
|
3714 |
|
|
made the conversion to auto_ptr_ref const. </p>
|
3715 |
|
|
|
3716 |
|
|
<p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
|
3717 |
|
|
states that the conversion from auto_ptr to auto_ptr_ref should
|
3718 |
|
|
be const. This is not acceptable, because it would allow
|
3719 |
|
|
initialization and assignment from _any_ const auto_ptr! It also
|
3720 |
|
|
introduces an implementation difficulty in writing this conversion
|
3721 |
|
|
function -- namely, somewhere along the line, a const_cast will be
|
3722 |
|
|
necessary to remove that const so that release() may be called. This
|
3723 |
|
|
may result in undefined behavior [7.1.5.1/4]. The conversion
|
3724 |
|
|
operator does not have to be const, because a non-const implicit
|
3725 |
|
|
object parameter may be bound to an rvalue [13.3.3.1.4/3]
|
3726 |
|
|
[13.3.1/5]. </p>
|
3727 |
|
|
|
3728 |
|
|
<p>Tokyo: The LWG removed the following from the proposed resolution:</p>
|
3729 |
|
|
|
3730 |
|
|
<p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, and 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>,
|
3731 |
|
|
paragraph 2, make the conversion to auto_ptr_ref const:</p>
|
3732 |
|
|
<blockquote>
|
3733 |
|
|
<pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre>
|
3734 |
|
|
</blockquote>
|
3735 |
|
|
<p><b>Proposed resolution:</b></p>
|
3736 |
|
|
<p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, move
|
3737 |
|
|
the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
|
3738 |
|
|
|
3739 |
|
|
<p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a>, paragraph 2, add
|
3740 |
|
|
a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
|
3741 |
|
|
|
3742 |
|
|
<blockquote>
|
3743 |
|
|
<pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre>
|
3744 |
|
|
</blockquote>
|
3745 |
|
|
|
3746 |
|
|
<p>Also add the assignment operator to 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.auto.ptr.conv"> [lib.auto.ptr.conv]</a>: </p>
|
3747 |
|
|
|
3748 |
|
|
<blockquote>
|
3749 |
|
|
<pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre>
|
3750 |
|
|
|
3751 |
|
|
<b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
|
3752 |
|
|
p</tt> that <tt>r</tt> holds a reference to.<br>
|
3753 |
|
|
<b>Returns: </b><tt>*this</tt>.
|
3754 |
|
|
|
3755 |
|
|
</blockquote>
|
3756 |
|
|
<hr>
|
3757 |
|
|
<a name="129"><h3>129. Need error indication from seekp() and seekg()</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, 27.6.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 22 Feb 1999</p>
|
3758 |
|
|
<p>Currently, the standard does not specify how seekg() and seekp()
|
3759 |
|
|
indicate failure. They are not required to set failbit, and they can't
|
3760 |
|
|
return an error indication because they must return *this, i.e. the
|
3761 |
|
|
stream. Hence, it is undefined what happens if they fail. And they
|
3762 |
|
|
<i>can</i> fail, for instance, when a file stream is disconnected from the
|
3763 |
|
|
underlying file (is_open()==false) or when a wide character file
|
3764 |
|
|
stream must perform a state-dependent code conversion, etc. </p>
|
3765 |
|
|
|
3766 |
|
|
<p>The stream functions seekg() and seekp() should set failbit in the
|
3767 |
|
|
stream state in case of failure.</p>
|
3768 |
|
|
<p><b>Proposed resolution:</b></p>
|
3769 |
|
|
<p>Add to the Effects: clause of seekg() in
|
3770 |
|
|
27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> and to the Effects: clause of seekp() in
|
3771 |
|
|
27.6.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>: </p>
|
3772 |
|
|
|
3773 |
|
|
<blockquote>
|
3774 |
|
|
<p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
|
3775 |
|
|
</p>
|
3776 |
|
|
</blockquote>
|
3777 |
|
|
<p><b>Rationale:</b></p>
|
3778 |
|
|
<p>Setting failbit is the usual error reporting mechanism for streams</p>
|
3779 |
|
|
<hr>
|
3780 |
|
|
<a name="130"><h3>130. Return type of container::erase(iterator) differs for associative containers</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2 Mar 1999</p>
|
3781 |
|
|
<p>Table 67 (23.1.1) says that container::erase(iterator) returns an
|
3782 |
|
|
iterator. Table 69 (23.1.2) says that in addition to this requirement,
|
3783 |
|
|
associative containers also say that container::erase(iterator)
|
3784 |
|
|
returns void. That's not an addition; it's a change to the
|
3785 |
|
|
requirements, which has the effect of making associative containers
|
3786 |
|
|
fail to meet the requirements for containers.</p>
|
3787 |
|
|
<p><b>Proposed resolution:</b></p>
|
3788 |
|
|
|
3789 |
|
|
<p>
|
3790 |
|
|
In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in Table 69 Associative container
|
3791 |
|
|
requirements, change the return type of <tt>a.erase(q)</tt> from
|
3792 |
|
|
<tt>void</tt> to <tt>iterator</tt>. Change the
|
3793 |
|
|
assertion/not/pre/post-condition from "erases the element pointed to
|
3794 |
|
|
by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
|
3795 |
|
|
Returns an iterator pointing to the element immediately following q
|
3796 |
|
|
prior to the element being erased. If no such element exists, a.end()
|
3797 |
|
|
is returned."
|
3798 |
|
|
</p>
|
3799 |
|
|
|
3800 |
|
|
<p>
|
3801 |
|
|
In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in Table 69 Associative container
|
3802 |
|
|
requirements, change the return type of <tt>a.erase(q1, q2)</tt>
|
3803 |
|
|
from <tt>void</tt> to <tt>iterator</tt>. Change the
|
3804 |
|
|
assertion/not/pre/post-condition from "erases the elements in the
|
3805 |
|
|
range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
|
3806 |
|
|
q2)</tt>. Returns q2."
|
3807 |
|
|
</p>
|
3808 |
|
|
|
3809 |
|
|
<p>
|
3810 |
|
|
In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, in the <tt>map</tt> class synopsis; and
|
3811 |
|
|
in 23.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multimap"> [lib.multimap]</a>, in the <tt>multimap</tt> class synopsis; and
|
3812 |
|
|
in 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a>, in the <tt>set</tt> class synopsis; and
|
3813 |
|
|
in 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>, in the <tt>multiset</tt> class synopsis:
|
3814 |
|
|
change the signature of the first <tt>erase</tt> overload to
|
3815 |
|
|
</p>
|
3816 |
|
|
<pre> iterator erase(iterator position);
|
3817 |
|
|
</pre>
|
3818 |
|
|
<p>and change the signature of the third <tt>erase</tt> overload to</p>
|
3819 |
|
|
<pre> iterator erase(iterator first, iterator last);
|
3820 |
|
|
</pre>
|
3821 |
|
|
|
3822 |
|
|
|
3823 |
|
|
<p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
|
3824 |
|
|
|
3825 |
|
|
<p><i>[Post-Kona: the LWG agrees the return type should be
|
3826 |
|
|
<tt>iterator</tt>, not <tt>void</tt>. (Alex Stepanov agrees too.)
|
3827 |
|
|
Matt provided wording.]</i></p>
|
3828 |
|
|
|
3829 |
|
|
<p><i>[
|
3830 |
|
|
Sydney: the proposed wording went in the right direction, but it
|
3831 |
|
|
wasn't good enough. We want to return an iterator from the range form
|
3832 |
|
|
of erase as well as the single-iterator form. Also, the wording is
|
3833 |
|
|
slightly different from the wording we have for sequences; there's no
|
3834 |
|
|
good reason for having a difference. Matt provided new wording,
|
3835 |
|
|
which we will review at the next meeting.
|
3836 |
|
|
]</i></p>
|
3837 |
|
|
|
3838 |
|
|
<hr>
|
3839 |
|
|
<a name="132"><h3>132. list::resize description uses random access iterators</h3></a><p><b>Section:</b> 23.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
3840 |
|
|
<p>The description reads:</p>
|
3841 |
|
|
|
3842 |
|
|
<p>-1- Effects:</p>
|
3843 |
|
|
|
3844 |
|
|
<pre> if (sz > size())
|
3845 |
|
|
insert(end(), sz-size(), c);
|
3846 |
|
|
else if (sz < size())
|
3847 |
|
|
erase(begin()+sz, end());
|
3848 |
|
|
else
|
3849 |
|
|
; // do nothing</pre>
|
3850 |
|
|
|
3851 |
|
|
<p>Obviously list::resize should not be specified in terms of random access iterators.</p>
|
3852 |
|
|
<p><b>Proposed resolution:</b></p>
|
3853 |
|
|
<p>Change 23.2.2.2 paragraph 1 to:</p>
|
3854 |
|
|
|
3855 |
|
|
<p>Effects:</p>
|
3856 |
|
|
|
3857 |
|
|
<pre> if (sz > size())
|
3858 |
|
|
insert(end(), sz-size(), c);
|
3859 |
|
|
else if (sz < size())
|
3860 |
|
|
{
|
3861 |
|
|
iterator i = begin();
|
3862 |
|
|
advance(i, sz);
|
3863 |
|
|
erase(i, end());
|
3864 |
|
|
}</pre>
|
3865 |
|
|
|
3866 |
|
|
<p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
|
3867 |
|
|
with David Abrahams. They had a discussion and believe there is
|
3868 |
|
|
no issue of exception safety with the proposed resolution.]</i></p>
|
3869 |
|
|
<hr>
|
3870 |
|
|
<a name="133"><h3>133. map missing get_allocator()</h3></a><p><b>Section:</b> 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
3871 |
|
|
<p>The title says it all.</p>
|
3872 |
|
|
<p><b>Proposed resolution:</b></p>
|
3873 |
|
|
<p>Insert in 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
|
3874 |
|
|
after operator= in the map declaration:</p>
|
3875 |
|
|
|
3876 |
|
|
<pre> allocator_type get_allocator() const;</pre>
|
3877 |
|
|
<hr>
|
3878 |
|
|
<a name="134"><h3>134. vector constructors over specified</h3></a><p><b>Section:</b> 23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
3879 |
|
|
<p>The complexity description says: "It does at most 2N calls to the copy constructor
|
3880 |
|
|
of T and logN reallocations if they are just input iterators ...".</p>
|
3881 |
|
|
|
3882 |
|
|
<p>This appears to be overly restrictive, dictating the precise memory/performance
|
3883 |
|
|
tradeoff for the implementor.</p>
|
3884 |
|
|
<p><b>Proposed resolution:</b></p>
|
3885 |
|
|
<p>Change 23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a>, paragraph 1 to:</p>
|
3886 |
|
|
|
3887 |
|
|
<p>-1- Complexity: The constructor template <class
|
3888 |
|
|
InputIterator> vector(InputIterator first, InputIterator last)
|
3889 |
|
|
makes only N calls to the copy constructor of T (where N is the
|
3890 |
|
|
distance between first and last) and no reallocations if iterators
|
3891 |
|
|
first and last are of forward, bidirectional, or random access
|
3892 |
|
|
categories. It makes order N calls to the copy constructor of T and
|
3893 |
|
|
order logN reallocations if they are just input iterators.
|
3894 |
|
|
</p>
|
3895 |
|
|
<p><b>Rationale:</b></p>
|
3896 |
|
|
<p>"at most 2N calls" is correct only if the growth factor
|
3897 |
|
|
is greater than or equal to 2.
|
3898 |
|
|
</p>
|
3899 |
|
|
<hr>
|
3900 |
|
|
<a name="136"><h3>136. seekp, seekg setting wrong streams?</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
|
3901 |
|
|
<p>I may be misunderstanding the intent, but should not seekg set only
|
3902 |
|
|
the input stream and seekp set only the output stream? The description
|
3903 |
|
|
seems to say that each should set both input and output streams. If
|
3904 |
|
|
that's really the intent, I withdraw this proposal.</p>
|
3905 |
|
|
<p><b>Proposed resolution:</b></p>
|
3906 |
|
|
<p>In section 27.6.1.3 change:</p>
|
3907 |
|
|
|
3908 |
|
|
<pre>basic_istream<charT,traits>& seekg(pos_type pos);
|
3909 |
|
|
Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre>
|
3910 |
|
|
|
3911 |
|
|
<p>To:</p>
|
3912 |
|
|
|
3913 |
|
|
<pre>basic_istream<charT,traits>& seekg(pos_type pos);
|
3914 |
|
|
Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::in). </pre>
|
3915 |
|
|
|
3916 |
|
|
<p>In section 27.6.1.3 change:</p>
|
3917 |
|
|
|
3918 |
|
|
<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
|
3919 |
|
|
Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre>
|
3920 |
|
|
|
3921 |
|
|
<p>To:</p>
|
3922 |
|
|
|
3923 |
|
|
<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
|
3924 |
|
|
Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::in). </pre>
|
3925 |
|
|
|
3926 |
|
|
<p>In section 27.6.2.4, paragraph 2 change:</p>
|
3927 |
|
|
|
3928 |
|
|
<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre>
|
3929 |
|
|
|
3930 |
|
|
<p>To:</p>
|
3931 |
|
|
|
3932 |
|
|
<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::out). </pre>
|
3933 |
|
|
|
3934 |
|
|
<p>In section 27.6.2.4, paragraph 4 change:</p>
|
3935 |
|
|
|
3936 |
|
|
<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre>
|
3937 |
|
|
|
3938 |
|
|
<p>To:</p>
|
3939 |
|
|
|
3940 |
|
|
<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::out). </pre>
|
3941 |
|
|
|
3942 |
|
|
<p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
|
3943 |
|
|
like the opinion of more iostream experts before taking action.]</i></p>
|
3944 |
|
|
|
3945 |
|
|
<p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
|
3946 |
|
|
incorrect, his implementation already implements the Proposed
|
3947 |
|
|
Resolution.]</i></p>
|
3948 |
|
|
|
3949 |
|
|
<p><i>[Post-Tokyo: Matt Austern comments:<br>
|
3950 |
|
|
Is it a problem with basic_istream and basic_ostream, or is it a problem
|
3951 |
|
|
with basic_stringbuf?
|
3952 |
|
|
We could resolve the issue either by changing basic_istream and
|
3953 |
|
|
basic_ostream, or by changing basic_stringbuf. I prefer the latter
|
3954 |
|
|
change (or maybe both changes): I don't see any reason for the standard to
|
3955 |
|
|
require that std::stringbuf s(std::string("foo"), std::ios_base::in);
|
3956 |
|
|
s.pubseekoff(0, std::ios_base::beg); must fail.<br>
|
3957 |
|
|
This requirement is a bit weird. There's no similar requirement
|
3958 |
|
|
for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or
|
3959 |
|
|
basic_filebuf<>::seekpos.]</i></p>
|
3960 |
|
|
<hr>
|
3961 |
|
|
<a name="137"><h3>137. Do use_facet and has_facet look in the global locale?</h3></a><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p>
|
3962 |
|
|
<p>Section 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> says:</p>
|
3963 |
|
|
|
3964 |
|
|
<p>-4- In the call to use_facet<Facet>(loc), the type argument
|
3965 |
|
|
chooses a facet, making available all members of the named type. If
|
3966 |
|
|
Facet is not present in a locale (or, failing that, in the global
|
3967 |
|
|
locale), it throws the standard exception bad_cast. A C++ program can
|
3968 |
|
|
check if a locale implements a particular facet with the template
|
3969 |
|
|
function has_facet<Facet>(). </p>
|
3970 |
|
|
|
3971 |
|
|
<p>This contradicts the specification given in section
|
3972 |
|
|
22.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>:
|
3973 |
|
|
<br><br>
|
3974 |
|
|
template <class Facet> const Facet& use_facet(const
|
3975 |
|
|
locale& loc); <br>
|
3976 |
|
|
<br>
|
3977 |
|
|
-1- Get a reference to a facet of a locale. <br>
|
3978 |
|
|
-2- Returns: a reference to the corresponding facet of loc, if present. <br>
|
3979 |
|
|
-3- Throws: bad_cast if has_facet<Facet>(loc) is false. <br>
|
3980 |
|
|
-4- Notes: The reference returned remains valid at least as long as any copy of loc exists
|
3981 |
|
|
</p>
|
3982 |
|
|
<p><b>Proposed resolution:</b></p>
|
3983 |
|
|
<p>Remove the phrase "(or, failing that, in the global locale)"
|
3984 |
|
|
from section 22.1.1. </p>
|
3985 |
|
|
<p><b>Rationale:</b></p>
|
3986 |
|
|
<p>Needed for consistency with the way locales are handled elsewhere
|
3987 |
|
|
in the standard.</p>
|
3988 |
|
|
<hr>
|
3989 |
|
|
<a name="139"><h3>139. Optional sequence operation table description unclear</h3></a><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Mar 1999</p>
|
3990 |
|
|
<p>The sentence introducing the Optional sequence operation table
|
3991 |
|
|
(23.1.1 paragraph 12) has two problems:</p>
|
3992 |
|
|
|
3993 |
|
|
<p>A. It says ``The operations in table 68 are provided only for the containers for which
|
3994 |
|
|
they take constant time.''<br>
|
3995 |
|
|
<br>
|
3996 |
|
|
That could be interpreted in two ways, one of them being ``Even though table 68 shows
|
3997 |
|
|
particular operations as being provided, implementations are free to omit them if they
|
3998 |
|
|
cannot implement them in constant time.''<br>
|
3999 |
|
|
<br>
|
4000 |
|
|
B. That paragraph says nothing about amortized constant time, and it should. </p>
|
4001 |
|
|
<p><b>Proposed resolution:</b></p>
|
4002 |
|
|
<p>Replace the wording in 23.1.1 paragraph 12 which begins ``The operations in table 68 are provided only..."
|
4003 |
|
|
with:</p>
|
4004 |
|
|
|
4005 |
|
|
<blockquote>
|
4006 |
|
|
<p>Table 68 lists sequence operations that are provided for some types of sequential
|
4007 |
|
|
containers but not others. An implementation shall provide these operations for all
|
4008 |
|
|
container types shown in the ``container'' column, and shall implement them so as to take
|
4009 |
|
|
amortized constant time.</p>
|
4010 |
|
|
</blockquote>
|
4011 |
|
|
<hr>
|
4012 |
|
|
<a name="141"><h3>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3></a><p><b>Section:</b> 21.3.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::find.last.of"> [lib.string::find.last.of]</a>, 21.3.6.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::find.last.not.of"> [lib.string::find.last.not.of]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Arch Robison <b>Date:</b> 28 Apr 1999</p>
|
4013 |
|
|
<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
|
4014 |
|
|
say:<br>
|
4015 |
|
|
<br>
|
4016 |
|
|
— <tt>xpos <= pos</tt> and <tt>pos < size();</tt></p>
|
4017 |
|
|
|
4018 |
|
|
<p>Surely the document meant to say ``<tt>xpos < size()</tt>'' in both places.</p>
|
4019 |
|
|
|
4020 |
|
|
<p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
|
4021 |
|
|
proposed resolution.]</i></p>
|
4022 |
|
|
<p><b>Proposed resolution:</b></p>
|
4023 |
|
|
<p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
|
4024 |
|
|
<br>
|
4025 |
|
|
— <tt>xpos <= pos</tt> and <tt>pos < size();<br>
|
4026 |
|
|
<br>
|
4027 |
|
|
</tt>to:<br>
|
4028 |
|
|
<tt><br>
|
4029 |
|
|
</tt>— <tt>xpos <= pos</tt> and <tt>xpos < size();</tt></p>
|
4030 |
|
|
<hr>
|
4031 |
|
|
<a name="142"><h3>142. lexicographical_compare complexity wrong</h3></a><p><b>Section:</b> 25.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Jun 1999</p>
|
4032 |
|
|
<p>The lexicographical_compare complexity is specified as:<br>
|
4033 |
|
|
<br>
|
4034 |
|
|
"At most min((last1 - first1), (last2 - first2))
|
4035 |
|
|
applications of the corresponding comparison."<br>
|
4036 |
|
|
<br>
|
4037 |
|
|
The best I can do is twice that expensive.</p>
|
4038 |
|
|
|
4039 |
|
|
<p>Nicolai Josuttis comments in lib-6862: You mean, to check for
|
4040 |
|
|
equality you have to check both < and >? Yes, IMO you are
|
4041 |
|
|
right! (and Matt states this complexity in his book)</p>
|
4042 |
|
|
|
4043 |
|
|
<p><b>Proposed resolution:</b></p>
|
4044 |
|
|
<p>Change 25.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> complexity to:</p>
|
4045 |
|
|
<blockquote>
|
4046 |
|
|
At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
|
4047 |
|
|
applications of the corresponding comparison.
|
4048 |
|
|
</blockquote>
|
4049 |
|
|
|
4050 |
|
|
<p>Change the example at the end of paragraph 3 to read:</p>
|
4051 |
|
|
<blockquote>
|
4052 |
|
|
[Example:<br>
|
4053 |
|
|
<br>
|
4054 |
|
|
for ( ; first1 != last1 && first2 != last2 ;
|
4055 |
|
|
++first1, ++first2) {<br>
|
4056 |
|
|
if (*first1 < *first2) return true;<br>
|
4057 |
|
|
if (*first2 < *first1) return false;<br>
|
4058 |
|
|
}<br>
|
4059 |
|
|
return first1 == last1 && first2 != last2;<br>
|
4060 |
|
|
<br>
|
4061 |
|
|
--end example]
|
4062 |
|
|
</blockquote>
|
4063 |
|
|
<hr>
|
4064 |
|
|
<a name="144"><h3>144. Deque constructor complexity wrong </h3></a><p><b>Section:</b> 23.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 9 May 1999</p>
|
4065 |
|
|
<p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
|
4066 |
|
|
to have complexity requirements which are incorrect, and which contradict the
|
4067 |
|
|
complexity requirements for insert(). I suspect that the text in question,
|
4068 |
|
|
below, was taken from vector:</p>
|
4069 |
|
|
<blockquote>
|
4070 |
|
|
<p>Complexity: If the iterators first and last are forward iterators,
|
4071 |
|
|
bidirectional iterators, or random access iterators the constructor makes only
|
4072 |
|
|
N calls to the copy constructor, and performs no reallocations, where N is
|
4073 |
|
|
last - first.</p>
|
4074 |
|
|
</blockquote>
|
4075 |
|
|
<p>The word "reallocations" does not really apply to deque. Further,
|
4076 |
|
|
all of the following appears to be spurious:</p>
|
4077 |
|
|
<blockquote>
|
4078 |
|
|
<p>It makes at most 2N calls to the copy constructor of T and log N
|
4079 |
|
|
reallocations if they are input iterators.1)</p>
|
4080 |
|
|
<p>1) The complexity is greater in the case of input iterators because each
|
4081 |
|
|
element must be added individually: it is impossible to determine the distance
|
4082 |
|
|
between first abd last before doing the copying.</p>
|
4083 |
|
|
</blockquote>
|
4084 |
|
|
<p>This makes perfect sense for vector, but not for deque. Why should deque gain
|
4085 |
|
|
an efficiency advantage from knowing in advance the number of elements to
|
4086 |
|
|
insert?</p>
|
4087 |
|
|
<p><b>Proposed resolution:</b></p>
|
4088 |
|
|
<p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
|
4089 |
|
|
footnote, with the following text (which also corrects the "abd"
|
4090 |
|
|
typo):</p>
|
4091 |
|
|
<blockquote>
|
4092 |
|
|
<p>Complexity: Makes last - first calls to the copy constructor of T.</p>
|
4093 |
|
|
</blockquote>
|
4094 |
|
|
<hr>
|
4095 |
|
|
<a name="146"><h3>146. complex<T> Inserter and Extractor need sentries</h3></a><p><b>Section:</b> 26.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 12 May 1999</p>
|
4096 |
|
|
<p>The <u> extractor</u> for complex numbers is specified as: </p>
|
4097 |
|
|
|
4098 |
|
|
<blockquote>
|
4099 |
|
|
|
4100 |
|
|
<p> template<class T, class charT, class traits> <br>
|
4101 |
|
|
basic_istream<charT, traits>& <br>
|
4102 |
|
|
operator>>(basic_istream<charT, traits>& is, complex<T>& x);<br>
|
4103 |
|
|
<br>
|
4104 |
|
|
Effects: Extracts a complex number x of the form: u, (u), or (u,v),
|
4105 |
|
|
where u is the real part and v is the imaginary part
|
4106 |
|
|
(lib.istream.formatted). <br>
|
4107 |
|
|
Requires: The input values be convertible to T. If bad input is
|
4108 |
|
|
encountered, calls is.setstate(ios::failbit) (which may throw
|
4109 |
|
|
ios::failure (lib.iostate.flags). <br>
|
4110 |
|
|
Returns: is .</p>
|
4111 |
|
|
|
4112 |
|
|
</blockquote>
|
4113 |
|
|
<p>Is it intended that the extractor for complex numbers does not skip
|
4114 |
|
|
whitespace, unlike all other extractors in the standard library do?
|
4115 |
|
|
Shouldn't a sentry be used? <br>
|
4116 |
|
|
<br>
|
4117 |
|
|
The <u>inserter</u> for complex numbers is specified as:</p>
|
4118 |
|
|
|
4119 |
|
|
<blockquote>
|
4120 |
|
|
|
4121 |
|
|
<p> template<class T, class charT, class traits> <br>
|
4122 |
|
|
basic_ostream<charT, traits>& <br>
|
4123 |
|
|
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);<br>
|
4124 |
|
|
<br>
|
4125 |
|
|
Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
|
4126 |
|
|
<br>
|
4127 |
|
|
template<class T, class charT, class traits> <br>
|
4128 |
|
|
basic_ostream<charT, traits>& <br>
|
4129 |
|
|
operator<<(basic_ostream<charT, traits>& o, const complex<T>& x) <br>
|
4130 |
|
|
{ <br>
|
4131 |
|
|
basic_ostringstream<charT, traits> s; <br>
|
4132 |
|
|
s.flags(o.flags()); <br>
|
4133 |
|
|
s.imbue(o.getloc()); <br>
|
4134 |
|
|
s.precision(o.precision()); <br>
|
4135 |
|
|
s << '(' << x.real() << "," << x.imag() << ')'; <br>
|
4136 |
|
|
return o << s.str(); <br>
|
4137 |
|
|
}</p>
|
4138 |
|
|
|
4139 |
|
|
</blockquote>
|
4140 |
|
|
|
4141 |
|
|
<p>Is it intended that the inserter for complex numbers ignores the
|
4142 |
|
|
field width and does not do any padding? If, with the suggested
|
4143 |
|
|
implementation above, the field width were set in the stream then the
|
4144 |
|
|
opening parentheses would be adjusted, but the rest not, because the
|
4145 |
|
|
field width is reset to zero after each insertion.</p>
|
4146 |
|
|
|
4147 |
|
|
<p>I think that both operations should use sentries, for sake of
|
4148 |
|
|
consistency with the other inserters and extractors in the
|
4149 |
|
|
library. Regarding the issue of padding in the inserter, I don't know
|
4150 |
|
|
what the intent was. </p>
|
4151 |
|
|
<p><b>Proposed resolution:</b></p>
|
4152 |
|
|
<p>After 26.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> paragraph 14 (operator>>), add a
|
4153 |
|
|
Notes clause:</p>
|
4154 |
|
|
|
4155 |
|
|
<blockquote>
|
4156 |
|
|
|
4157 |
|
|
<p>Notes: This extraction is performed as a series of simpler
|
4158 |
|
|
extractions. Therefore, the skipping of whitespace is specified to be the
|
4159 |
|
|
same for each of the simpler extractions.</p>
|
4160 |
|
|
|
4161 |
|
|
</blockquote>
|
4162 |
|
|
<p><b>Rationale:</b></p>
|
4163 |
|
|
<p>For extractors, the note is added to make it clear that skipping whitespace
|
4164 |
|
|
follows an "all-or-none" rule.</p>
|
4165 |
|
|
|
4166 |
|
|
<p>For inserters, the LWG believes there is no defect; the standard is correct
|
4167 |
|
|
as written.</p>
|
4168 |
|
|
<hr>
|
4169 |
|
|
<a name="147"><h3>147. Library Intro refers to global functions that aren't global</h3></a><p><b>Section:</b> 17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p>
|
4170 |
|
|
<p>The library had many global functions until 17.4.1.1 [lib.contents]
|
4171 |
|
|
paragraph 2 was added: </p>
|
4172 |
|
|
|
4173 |
|
|
<blockquote>
|
4174 |
|
|
|
4175 |
|
|
<p>All library entities except macros, operator new and operator
|
4176 |
|
|
delete are defined within the namespace std or namespaces nested
|
4177 |
|
|
within namespace std. </p>
|
4178 |
|
|
|
4179 |
|
|
</blockquote>
|
4180 |
|
|
|
4181 |
|
|
<p>It appears "global function" was never updated in the following: </p>
|
4182 |
|
|
|
4183 |
|
|
<blockquote>
|
4184 |
|
|
|
4185 |
|
|
<p>17.4.4.3 - Global functions [lib.global.functions]<br>
|
4186 |
|
|
<br>
|
4187 |
|
|
-1- It is unspecified whether any global functions in the C++ Standard
|
4188 |
|
|
Library are defined as inline (dcl.fct.spec).<br>
|
4189 |
|
|
<br>
|
4190 |
|
|
-2- A call to a global function signature described in Clauses
|
4191 |
|
|
lib.language.support through lib.input.output behaves the same as if
|
4192 |
|
|
the implementation declares no additional global function
|
4193 |
|
|
signatures.*<br>
|
4194 |
|
|
<br>
|
4195 |
|
|
[Footnote: A valid C++ program always calls the expected library
|
4196 |
|
|
global function. An implementation may also define additional
|
4197 |
|
|
global functions that would otherwise not be called by a valid C++
|
4198 |
|
|
program. --- end footnote]<br>
|
4199 |
|
|
<br>
|
4200 |
|
|
-3- A global function cannot be declared by the implementation as
|
4201 |
|
|
taking additional default arguments. <br>
|
4202 |
|
|
<br>
|
4203 |
|
|
17.4.4.4 - Member functions [lib.member.functions]<br>
|
4204 |
|
|
<br>
|
4205 |
|
|
-2- An implementation can declare additional non-virtual member
|
4206 |
|
|
function signatures within a class: </p>
|
4207 |
|
|
|
4208 |
|
|
<blockquote>
|
4209 |
|
|
|
4210 |
|
|
<p>-- by adding arguments with default values to a member function
|
4211 |
|
|
signature; The same latitude does not extend to the implementation of
|
4212 |
|
|
virtual or global functions, however. </p>
|
4213 |
|
|
|
4214 |
|
|
</blockquote>
|
4215 |
|
|
</blockquote>
|
4216 |
|
|
<p><b>Proposed resolution:</b></p>
|
4217 |
|
|
<p> Change "global" to "global or non-member" in:</p>
|
4218 |
|
|
<blockquote>
|
4219 |
|
|
<p>17.4.4.3 [lib.global.functions] section title,<br>
|
4220 |
|
|
17.4.4.3 [lib.global.functions] para 1,<br>
|
4221 |
|
|
17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
|
4222 |
|
|
places in the footnote,<br>
|
4223 |
|
|
17.4.4.3 [lib.global.functions] para 3,<br>
|
4224 |
|
|
17.4.4.4 [lib.member.functions] para 2</p>
|
4225 |
|
|
</blockquote>
|
4226 |
|
|
<p><b>Rationale:</b></p>
|
4227 |
|
|
<p>
|
4228 |
|
|
Because operator new and delete are global, the proposed resolution
|
4229 |
|
|
was changed from "non-member" to "global or non-member.
|
4230 |
|
|
</p>
|
4231 |
|
|
<hr>
|
4232 |
|
|
<a name="148"><h3>148. Functions in the example facet BoolNames should be const</h3></a><p><b>Section:</b> 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 3 Jun 1999</p>
|
4233 |
|
|
<p>In 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, the do_truename() and
|
4234 |
|
|
do_falsename() functions in the example facet BoolNames should be
|
4235 |
|
|
const. The functions they are overriding in
|
4236 |
|
|
numpunct_byname<char> are const. </p>
|
4237 |
|
|
<p><b>Proposed resolution:</b></p>
|
4238 |
|
|
<p>In 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, insert "const" in
|
4239 |
|
|
two places:</p>
|
4240 |
|
|
<blockquote>
|
4241 |
|
|
<p><tt>string do_truename() const { return "Oui Oui!"; }<br>
|
4242 |
|
|
string do_falsename() const { return "Mais Non!"; }</tt></p>
|
4243 |
|
|
</blockquote>
|
4244 |
|
|
<hr>
|
4245 |
|
|
<a name="150"><h3>150. Find_first_of says integer instead of iterator </h3></a><p><b>Section:</b> 25.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt McClure <b>Date:</b> 30 Jun 1999</p>
|
4246 |
|
|
<p><b>Proposed resolution:</b></p>
|
4247 |
|
|
<p>Change 25.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> paragraph 2 from:</p>
|
4248 |
|
|
|
4249 |
|
|
<blockquote>
|
4250 |
|
|
<p>Returns: The first iterator i in the range [first1, last1) such
|
4251 |
|
|
that for some <u>integer</u> j in the range [first2, last2) ...</p>
|
4252 |
|
|
</blockquote>
|
4253 |
|
|
|
4254 |
|
|
<p>to:</p>
|
4255 |
|
|
|
4256 |
|
|
<blockquote>
|
4257 |
|
|
<p>Returns: The first iterator i in the range [first1, last1) such
|
4258 |
|
|
that for some iterator j in the range [first2, last2) ...</p>
|
4259 |
|
|
</blockquote>
|
4260 |
|
|
<hr>
|
4261 |
|
|
<a name="151"><h3>151. Can't currently clear() empty container</h3></a><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 21 Jun 1999</p>
|
4262 |
|
|
<p>For both sequences and associative containers, a.clear() has the
|
4263 |
|
|
semantics of erase(a.begin(),a.end()), which is undefined for an empty
|
4264 |
|
|
container since erase(q1,q2) requires that q1 be dereferenceable
|
4265 |
|
|
(23.1.1,3 and 23.1.2,7). When the container is empty, a.begin() is
|
4266 |
|
|
not dereferenceable.<br>
|
4267 |
|
|
<br>
|
4268 |
|
|
The requirement that q1 be unconditionally dereferenceable causes many
|
4269 |
|
|
operations to be intuitively undefined, of which clearing an empty
|
4270 |
|
|
container is probably the most dire.<br>
|
4271 |
|
|
<br>
|
4272 |
|
|
Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
|
4273 |
|
|
q2) is required to be a valid range, stating that q1 and q2 must be
|
4274 |
|
|
iterators or certain kinds of iterators is unnecessary.
|
4275 |
|
|
</p>
|
4276 |
|
|
<p><b>Proposed resolution:</b></p>
|
4277 |
|
|
<p>In 23.1.1, paragraph 3, change:</p>
|
4278 |
|
|
<blockquote>
|
4279 |
|
|
<p>p and q2 denote valid iterators to a, q <u> and q1</u> denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p>
|
4280 |
|
|
</blockquote>
|
4281 |
|
|
<p>to:</p>
|
4282 |
|
|
<blockquote>
|
4283 |
|
|
<p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
|
4284 |
|
|
in a</u></p>
|
4285 |
|
|
</blockquote>
|
4286 |
|
|
<p>In 23.1.2, paragraph 7, change:</p>
|
4287 |
|
|
<blockquote>
|
4288 |
|
|
<p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
|
4289 |
|
|
iterators to a, [q1, q2) is a valid range</p>
|
4290 |
|
|
</blockquote>
|
4291 |
|
|
<p>to</p>
|
4292 |
|
|
<blockquote>
|
4293 |
|
|
<p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
|
4294 |
|
|
<u>into a</u></p>
|
4295 |
|
|
</blockquote>
|
4296 |
|
|
<hr>
|
4297 |
|
|
<a name="152"><h3>152. Typo in <tt>scan_is()</tt> semantics</h3></a><p><b>Section:</b> 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4298 |
|
|
<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
|
4299 |
|
|
because there is no function <tt>is()</tt> which only takes a character as
|
4300 |
|
|
argument. Also, in the effects clause (paragraph 3), the semantic is also kept
|
4301 |
|
|
vague.</p>
|
4302 |
|
|
<p><b>Proposed resolution:</b></p>
|
4303 |
|
|
<p>In 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> paragraphs 4 and 6, change the returns
|
4304 |
|
|
clause from:</p>
|
4305 |
|
|
<blockquote>
|
4306 |
|
|
<p>"... such that <tt>is(*p)</tt>
|
4307 |
|
|
would..."</p>
|
4308 |
|
|
</blockquote>
|
4309 |
|
|
<p>to: "... such that <tt>is(m, *p)</tt>
|
4310 |
|
|
would...."</p>
|
4311 |
|
|
<hr>
|
4312 |
|
|
<a name="153"><h3>153. Typo in <tt>narrow()</tt> semantics</h3></a><p><b>Section:</b> 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4313 |
|
|
<p>The description of the array version of <tt>narrow()</tt> (in
|
4314 |
|
|
paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
|
4315 |
|
|
takes only three arguments because in addition to the range a default
|
4316 |
|
|
character is needed.</p>
|
4317 |
|
|
|
4318 |
|
|
<p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
|
4319 |
|
|
two signatures followed by a <b>Returns</b> clause that only addresses
|
4320 |
|
|
one of them.</p>
|
4321 |
|
|
|
4322 |
|
|
<p><b>Proposed resolution:</b></p>
|
4323 |
|
|
<p>Change the returns clause in 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>
|
4324 |
|
|
paragraph 10 from:</p>
|
4325 |
|
|
<p> Returns: do_widen(low, high, to).</p>
|
4326 |
|
|
|
4327 |
|
|
<p>to:</p>
|
4328 |
|
|
<p> Returns: do_widen(c) or do_widen(low, high, to),
|
4329 |
|
|
respectively.</p>
|
4330 |
|
|
|
4331 |
|
|
<p>Change 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> paragraph 10 and 11 from:</p>
|
4332 |
|
|
<pre> char narrow(char c, char /*dfault*/) const;
|
4333 |
|
|
const char* narrow(const char* low, const char* high,
|
4334 |
|
|
char /*dfault*/, char* to) const;</pre>
|
4335 |
|
|
<pre> Returns: do_narrow(low, high, to).</pre>
|
4336 |
|
|
<p>to:</p>
|
4337 |
|
|
<pre> char narrow(char c, char dfault) const;
|
4338 |
|
|
const char* narrow(const char* low, const char* high,
|
4339 |
|
|
char dfault, char* to) const;</pre>
|
4340 |
|
|
<pre> Returns: do_narrow(c, dfault) or
|
4341 |
|
|
do_narrow(low, high, dfault, to), respectively.</pre>
|
4342 |
|
|
|
4343 |
|
|
<p><i>[Kona: 1) the problem occurs in additional places, 2) a user
|
4344 |
|
|
defined version could be different.]</i></p>
|
4345 |
|
|
|
4346 |
|
|
<p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
|
4347 |
|
|
the LWG. He could find no other places the problem occurred. He
|
4348 |
|
|
asks for clarification of the Kona "a user defined
|
4349 |
|
|
version..." comment above. Perhaps it was a circuitous way of
|
4350 |
|
|
saying "dfault" needed to be uncommented?]</i></p>
|
4351 |
|
|
|
4352 |
|
|
<p><i>[Post-Toronto: the issues list maintainer has merged in the
|
4353 |
|
|
proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
|
4354 |
|
|
same paragraphs.]</i></p>
|
4355 |
|
|
<hr>
|
4356 |
|
|
<a name="154"><h3>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt>
|
4357 |
|
|
</h3></a><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4358 |
|
|
<p>The table in paragraph 7 for the length modifier does not list the length
|
4359 |
|
|
modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
|
4360 |
|
|
standard asks the implementation to do undefined things when using <tt>scanf()</tt>
|
4361 |
|
|
(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
|
4362 |
|
|
is actually a problem I found quite often in production code, too).</p>
|
4363 |
|
|
<p><b>Proposed resolution:</b></p>
|
4364 |
|
|
<p>In 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, paragraph 7, add a row in the Length
|
4365 |
|
|
Modifier table to say that for <tt>double</tt> a length modifier
|
4366 |
|
|
<tt>l</tt> is to be used.</p>
|
4367 |
|
|
<p><b>Rationale:</b></p>
|
4368 |
|
|
<p>The standard makes an embarrassing beginner's mistake.</p>
|
4369 |
|
|
<hr>
|
4370 |
|
|
<a name="155"><h3>155. Typo in naming the class defining the class <tt>Init</tt>
|
4371 |
|
|
</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4372 |
|
|
<p>There are conflicting statements about where the class
|
4373 |
|
|
<tt>Init</tt> is defined. According to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2
|
4374 |
|
|
it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> it is defined as <tt>ios_base::Init</tt>.</p>
|
4375 |
|
|
<p><b>Proposed resolution:</b></p>
|
4376 |
|
|
<p>Change 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2 from
|
4377 |
|
|
"<tt>basic_ios::Init"</tt> to
|
4378 |
|
|
"<tt>ios_base::Init"</tt>.</p>
|
4379 |
|
|
<p><b>Rationale:</b></p>
|
4380 |
|
|
<p>Although not strictly wrong, the standard was misleading enough to warrant
|
4381 |
|
|
the change.</p>
|
4382 |
|
|
<hr>
|
4383 |
|
|
<a name="156"><h3>156. Typo in <tt>imbue()</tt> description</h3></a><p><b>Section:</b> 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4384 |
|
|
<p>There is a small discrepancy between the declarations of
|
4385 |
|
|
<tt>imbue()</tt>: in 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> the argument is passed as
|
4386 |
|
|
<tt>locale const&</tt> (correct), in 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> it
|
4387 |
|
|
is passed as <tt>locale const</tt> (wrong).</p>
|
4388 |
|
|
<p><b>Proposed resolution:</b></p>
|
4389 |
|
|
<p>In 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> change the <tt>imbue</tt> argument
|
4390 |
|
|
from "<tt>locale const" to "locale
|
4391 |
|
|
const&".</tt></p>
|
4392 |
|
|
<hr>
|
4393 |
|
|
<a name="158"><h3>158. Underspecified semantics for <tt>setbuf()</tt>
|
4394 |
|
|
</h3></a><p><b>Section:</b> 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4395 |
|
|
<p>The default behavior of <tt>setbuf()</tt> is described only for the
|
4396 |
|
|
situation that <tt>gptr() != 0 && gptr() != egptr()</tt>:
|
4397 |
|
|
namely to do nothing. What has to be done in other situations
|
4398 |
|
|
is not described although there is actually only one reasonable
|
4399 |
|
|
approach, namely to do nothing, too.</p>
|
4400 |
|
|
|
4401 |
|
|
<p>Since changing the buffer would almost certainly mess up most
|
4402 |
|
|
buffer management of derived classes unless these classes do it
|
4403 |
|
|
themselves, the default behavior of <tt>setbuf()</tt> should always be
|
4404 |
|
|
to do nothing.</p>
|
4405 |
|
|
<p><b>Proposed resolution:</b></p>
|
4406 |
|
|
<p>Change 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 3, Default behavior,
|
4407 |
|
|
to: "Default behavior: Does nothing. Returns this."</p>
|
4408 |
|
|
<hr>
|
4409 |
|
|
<a name="159"><h3>159. Strange use of <tt>underflow()</tt>
|
4410 |
|
|
</h3></a><p><b>Section:</b> 27.5.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4411 |
|
|
<p>The description of the meaning of the result of
|
4412 |
|
|
<tt>showmanyc()</tt> seems to be rather strange: It uses calls to
|
4413 |
|
|
<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
|
4414 |
|
|
this function only reads the current character but does not extract
|
4415 |
|
|
it, <tt>uflow()</tt> would extract the current character. This should
|
4416 |
|
|
be fixed to use <tt>sbumpc()</tt> instead.</p>
|
4417 |
|
|
<p><b>Proposed resolution:</b></p>
|
4418 |
|
|
<p>Change 27.5.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> paragraph 1,
|
4419 |
|
|
<tt>showmanyc()</tt>returns clause, by replacing the word
|
4420 |
|
|
"supplied" with the words "extracted from the
|
4421 |
|
|
stream".</p>
|
4422 |
|
|
<hr>
|
4423 |
|
|
<a name="160"><h3>160. Typo: Use of non-existing function <tt>exception()</tt>
|
4424 |
|
|
</h3></a><p><b>Section:</b> 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4425 |
|
|
<p>The paragraph 4 refers to the function <tt>exception()</tt> which
|
4426 |
|
|
is not defined. Probably, the referred function is
|
4427 |
|
|
<tt>basic_ios<>::exceptions()</tt>.</p>
|
4428 |
|
|
<p><b>Proposed resolution:</b></p>
|
4429 |
|
|
<p>In 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>, 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 1,
|
4430 |
|
|
27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, paragraph 3, and 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>,
|
4431 |
|
|
paragraph 1, change "<tt>exception()" to
|
4432 |
|
|
"exceptions()"</tt>.</p>
|
4433 |
|
|
|
4434 |
|
|
<p><i>[Note to Editor: "exceptions" with an "s"
|
4435 |
|
|
is the correct spelling.]</i></p>
|
4436 |
|
|
<hr>
|
4437 |
|
|
<a name="161"><h3>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
|
4438 |
|
|
</h3></a><p><b>Section:</b> 27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4439 |
|
|
<p>The note in the second paragraph pretends that the first argument
|
4440 |
|
|
is an object of type <tt>istream_iterator</tt>. This is wrong: It is
|
4441 |
|
|
an object of type <tt>istreambuf_iterator</tt>.</p>
|
4442 |
|
|
<p><b>Proposed resolution:</b></p>
|
4443 |
|
|
<p>Change 27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> from:</p>
|
4444 |
|
|
<blockquote>
|
4445 |
|
|
<p>The first argument provides an object of the istream_iterator class...</p>
|
4446 |
|
|
</blockquote>
|
4447 |
|
|
<p>to</p>
|
4448 |
|
|
<blockquote>
|
4449 |
|
|
<p>The first argument provides an object of the istreambuf_iterator class...</p>
|
4450 |
|
|
</blockquote>
|
4451 |
|
|
<hr>
|
4452 |
|
|
<a name="164"><h3>164. do_put() has apparently unused fill argument</h3></a><p><b>Section:</b> 22.2.5.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 23 Jul 1999</p>
|
4453 |
|
|
<p>In 22.2.5.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> the do_put() function is specified
|
4454 |
|
|
as taking a fill character as an argument, but the description of the
|
4455 |
|
|
function does not say whether the character is used at all and, if so,
|
4456 |
|
|
in which way. The same holds for any format control parameters that
|
4457 |
|
|
are accessible through the ios_base& argument, such as the
|
4458 |
|
|
adjustment or the field width. Is strftime() supposed to use the fill
|
4459 |
|
|
character in any way? In any case, the specification of
|
4460 |
|
|
time_put.do_put() looks inconsistent to me.<br> <br> Is the
|
4461 |
|
|
signature of do_put() wrong, or is the effects clause incomplete?</p>
|
4462 |
|
|
<p><b>Proposed resolution:</b></p>
|
4463 |
|
|
<p>Add the following note after 22.2.5.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a>
|
4464 |
|
|
paragraph 2:</p>
|
4465 |
|
|
<blockquote>
|
4466 |
|
|
<p> [Note: the <tt>fill</tt> argument may be used in the implementation-defined formats, or by derivations. A space character is a reasonable default
|
4467 |
|
|
for this argument. --end Note]</p>
|
4468 |
|
|
</blockquote>
|
4469 |
|
|
<p><b>Rationale:</b></p>
|
4470 |
|
|
<p>The LWG felt that while the normative text was correct,
|
4471 |
|
|
users need some guidance on what to pass for the <tt>fill</tt>
|
4472 |
|
|
argument since the standard doesn't say how it's used.</p>
|
4473 |
|
|
<hr>
|
4474 |
|
|
<a name="165"><h3>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3></a><p><b>Section:</b> 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4475 |
|
|
<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
|
4476 |
|
|
functions falling into one of the groups "formatted output functions"
|
4477 |
|
|
and "unformatted output functions" calls any stream buffer function
|
4478 |
|
|
which might call a virtual function other than <tt>overflow()</tt>. Basically
|
4479 |
|
|
this is fine but this implies that <tt>sputn()</tt> (this function would call
|
4480 |
|
|
the virtual function <tt>xsputn()</tt>) is never called by any of the standard
|
4481 |
|
|
output functions. Is this really intended? At minimum it would be convenient to
|
4482 |
|
|
call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
|
4483 |
|
|
is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
|
4484 |
|
|
with the definition of <tt>flush()</tt> which calls <tt>rdbuf()->pubsync()</tt>
|
4485 |
|
|
and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
|
4486 |
|
|
under "unformatted output functions").</p>
|
4487 |
|
|
<p>In addition, I guess that the sentence starting with "They may use other
|
4488 |
|
|
public members of <tt>basic_ostream</tt> ..." probably was intended to
|
4489 |
|
|
start with "They may use other public members of <tt>basic_streamuf</tt>..."
|
4490 |
|
|
although the problem with the virtual members exists in both cases.</p>
|
4491 |
|
|
<p>I see two obvious resolutions:</p>
|
4492 |
|
|
<ol>
|
4493 |
|
|
<li>state in a footnote that this means that <tt>xsputn()</tt> will never be
|
4494 |
|
|
called by any ostream member and that this is intended.</li>
|
4495 |
|
|
<li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
|
4496 |
|
|
Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
|
4497 |
|
|
</ol>
|
4498 |
|
|
<p><b>Proposed resolution:</b></p>
|
4499 |
|
|
<p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
|
4500 |
|
|
<blockquote>
|
4501 |
|
|
<p>They may use other public members of basic_ostream except that they do not
|
4502 |
|
|
invoke any virtual members of rdbuf() except overflow().</p>
|
4503 |
|
|
</blockquote>
|
4504 |
|
|
<p>to:</p>
|
4505 |
|
|
<blockquote>
|
4506 |
|
|
<p>They may use other public members of basic_ostream except that they shall
|
4507 |
|
|
not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
|
4508 |
|
|
sync().</p>
|
4509 |
|
|
</blockquote>
|
4510 |
|
|
|
4511 |
|
|
<p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
|
4512 |
|
|
PJP why the standard is written this way.]</i></p>
|
4513 |
|
|
|
4514 |
|
|
<p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
|
4515 |
|
|
LWG. He comments: The rules can be made a little bit more specific if
|
4516 |
|
|
necessary be explicitly spelling out what virtuals are allowed to be
|
4517 |
|
|
called from what functions and eg to state specifically that flush()
|
4518 |
|
|
is allowed to call sync() while other functions are not.]</i></p>
|
4519 |
|
|
<hr>
|
4520 |
|
|
<a name="167"><h3>167. Improper use of <tt>traits_type::length()</tt>
|
4521 |
|
|
</h3></a><p><b>Section:</b> 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4522 |
|
|
<p>Paragraph 4 states that the length is determined using
|
4523 |
|
|
<tt>traits::length(s)</tt>. Unfortunately, this function is not
|
4524 |
|
|
defined for example if the character type is <tt>wchar_t</tt> and the
|
4525 |
|
|
type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
|
4526 |
|
|
the character type is <tt>char</tt> and the type of <tt>s</tt> is
|
4527 |
|
|
either <tt>signed char const*</tt> or <tt>unsigned char
|
4528 |
|
|
const*</tt>.</p>
|
4529 |
|
|
<p><b>Proposed resolution:</b></p>
|
4530 |
|
|
<p>Change 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> paragraph 4 from:</p>
|
4531 |
|
|
<blockquote>
|
4532 |
|
|
<p>Effects: Behaves like an formatted inserter (as described in
|
4533 |
|
|
lib.ostream.formatted.reqmts) of out. After a sentry object is
|
4534 |
|
|
constructed it inserts characters. The number of characters starting
|
4535 |
|
|
at s to be inserted is traits::length(s). Padding is determined as
|
4536 |
|
|
described in lib.facet.num.put.virtuals. The traits::length(s)
|
4537 |
|
|
characters starting at s are widened using out.widen
|
4538 |
|
|
(lib.basic.ios.members). The widened characters and any required
|
4539 |
|
|
padding are inserted into out. Calls width(0).</p>
|
4540 |
|
|
</blockquote>
|
4541 |
|
|
<p>to:</p>
|
4542 |
|
|
<blockquote>
|
4543 |
|
|
<p>Effects: Behaves like a formatted inserter (as described in
|
4544 |
|
|
lib.ostream.formatted.reqmts) of out. After a sentry object is
|
4545 |
|
|
constructed it inserts <i>n</i> characters starting at <i>s</i>,
|
4546 |
|
|
where <i>n</i> is the number that would be computed as if by:</p>
|
4547 |
|
|
<ul>
|
4548 |
|
|
<li>traits::length(s) for the overload where the first argument is of
|
4549 |
|
|
type basic_ostream<charT, traits>& and the second is
|
4550 |
|
|
of type const charT*, and also for the overload where the first
|
4551 |
|
|
argument is of type basic_ostream<char, traits>& and
|
4552 |
|
|
the second is of type const char*.</li>
|
4553 |
|
|
<li>std::char_traits<char>::length(s)
|
4554 |
|
|
for the overload where the first argument is of type
|
4555 |
|
|
basic_ostream<charT, traits>& and the second is of type
|
4556 |
|
|
const char*.</li>
|
4557 |
|
|
<li>traits::length(reinterpret_cast<const char*>(s))
|
4558 |
|
|
for the other two overloads.</li>
|
4559 |
|
|
</ul>
|
4560 |
|
|
<p>Padding is determined as described in
|
4561 |
|
|
lib.facet.num.put.virtuals. The <i>n</i> characters starting at
|
4562 |
|
|
<i>s</i> are widened using out.widen (lib.basic.ios.members). The
|
4563 |
|
|
widened characters and any required padding are inserted into
|
4564 |
|
|
out. Calls width(0).</p>
|
4565 |
|
|
</blockquote>
|
4566 |
|
|
|
4567 |
|
|
<p><i>[Santa Cruz: Matt supplied new wording]</i></p>
|
4568 |
|
|
|
4569 |
|
|
<p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
|
4570 |
|
|
number that would be computed as if by"]</i></p>
|
4571 |
|
|
|
4572 |
|
|
<p><b>Rationale:</b></p>
|
4573 |
|
|
<p>We have five separate cases. In two of them we can use the
|
4574 |
|
|
user-supplied traits class without any fuss. In the other three we
|
4575 |
|
|
try to use something as close to that user-supplied class as possible.
|
4576 |
|
|
In two cases we've got a traits class that's appropriate for
|
4577 |
|
|
char and what we've got is a const signed char* or a const
|
4578 |
|
|
unsigned char*; that's close enough so we can just use a reinterpret
|
4579 |
|
|
cast, and continue to use the user-supplied traits class. Finally,
|
4580 |
|
|
there's one case where we just have to give up: where we've got a
|
4581 |
|
|
traits class for some arbitrary charT type, and we somehow have to
|
4582 |
|
|
deal with a const char*. There's nothing better to do but fall back
|
4583 |
|
|
to char_traits<char></p>
|
4584 |
|
|
<hr>
|
4585 |
|
|
<a name="168"><h3>168. Typo: formatted vs. unformatted</h3></a><p><b>Section:</b> 27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4586 |
|
|
<p>The first paragraph begins with a descriptions what has to be done
|
4587 |
|
|
in <i>formatted</i> output functions. Probably this is a typo and the
|
4588 |
|
|
paragraph really want to describe unformatted output functions...</p>
|
4589 |
|
|
<p><b>Proposed resolution:</b></p>
|
4590 |
|
|
<p>In 27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> paragraph 1, the first and last
|
4591 |
|
|
sentences, change the word "formatted" to
|
4592 |
|
|
"unformatted":</p>
|
4593 |
|
|
<blockquote>
|
4594 |
|
|
<p>"Each <b>unformatted </b> output function begins ..."<br>
|
4595 |
|
|
"... value specified for the <b>unformatted </b> output
|
4596 |
|
|
function."</p>
|
4597 |
|
|
</blockquote>
|
4598 |
|
|
<hr>
|
4599 |
|
|
<a name="169"><h3>169. Bad efficiency of <tt>overflow()</tt> mandated</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4600 |
|
|
<p>Paragraph 8, Notes, of this section seems to mandate an extremely
|
4601 |
|
|
inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
|
4602 |
|
|
especially in view of the restriction that <tt>basic_ostream</tt>
|
4603 |
|
|
member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>): For each character to be inserted, a new buffer
|
4604 |
|
|
is to be created.</p>
|
4605 |
|
|
<p>Of course, the resolution below requires some handling of
|
4606 |
|
|
simultaneous input and output since it is no longer possible to update
|
4607 |
|
|
<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
|
4608 |
|
|
solution is to handle this in <tt>underflow()</tt>.</p>
|
4609 |
|
|
<p><b>Proposed resolution:</b></p>
|
4610 |
|
|
<p>In 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> paragraph 8, Notes, insert the words
|
4611 |
|
|
"at least" as in the following:</p>
|
4612 |
|
|
<blockquote>
|
4613 |
|
|
<p>To make a write position available, the function reallocates (or initially
|
4614 |
|
|
allocates) an array object with a sufficient number of elements to hold the
|
4615 |
|
|
current array object (if any), plus <b>at least</b> one additional write
|
4616 |
|
|
position.</p>
|
4617 |
|
|
</blockquote>
|
4618 |
|
|
<hr>
|
4619 |
|
|
<a name="170"><h3>170. Inconsistent definition of <tt>traits_type</tt>
|
4620 |
|
|
</h3></a><p><b>Section:</b> 27.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4621 |
|
|
<p>The classes <tt>basic_stringstream</tt> (27.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>),
|
4622 |
|
|
<tt>basic_istringstream</tt> (27.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istringstream"> [lib.istringstream]</a>), and
|
4623 |
|
|
<tt>basic_ostringstream</tt> (27.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) are inconsistent
|
4624 |
|
|
in their definition of the type <tt>traits_type</tt>: For
|
4625 |
|
|
<tt>istringstream</tt>, this type is defined, for the other two it is
|
4626 |
|
|
not. This should be consistent.</p>
|
4627 |
|
|
<p><b>Proposed resolution:</b></p>
|
4628 |
|
|
<p><b>Proposed resolution:</b></p> <p>To the declarations of
|
4629 |
|
|
<tt>basic_ostringstream</tt> (27.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) and
|
4630 |
|
|
<tt>basic_stringstream</tt> (27.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>) add:</p>
|
4631 |
|
|
<blockquote>
|
4632 |
|
|
<pre>typedef traits traits_type;</pre>
|
4633 |
|
|
</blockquote>
|
4634 |
|
|
<hr>
|
4635 |
|
|
<a name="171"><h3>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3></a><p><b>Section:</b> 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
4636 |
|
|
<p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> paragraph 3, it is stated that a joint input and
|
4637 |
|
|
output position is maintained by <tt>basic_filebuf</tt>. Still, the
|
4638 |
|
|
description of <tt>seekpos()</tt> seems to talk about different file
|
4639 |
|
|
positions. In particular, it is unclear (at least to me) what is
|
4640 |
|
|
supposed to happen to the output buffer (if there is one) if only the
|
4641 |
|
|
input position is changed. The standard seems to mandate that the
|
4642 |
|
|
output buffer is kept and processed as if there was no positioning of
|
4643 |
|
|
the output position (by changing the input position). Of course, this
|
4644 |
|
|
can be exactly what you want if the flag <tt>ios_base::ate</tt> is
|
4645 |
|
|
set. However, I think, the standard should say something like
|
4646 |
|
|
this:</p>
|
4647 |
|
|
<ul>
|
4648 |
|
|
<li>If <tt>(which & mode) == 0</tt> neither read nor write position is
|
4649 |
|
|
changed and the call fails. Otherwise, the joint read and write position is
|
4650 |
|
|
altered to correspond to <tt>sp</tt>.</li>
|
4651 |
|
|
<li>If there is an output buffer, the output sequences is updated and any
|
4652 |
|
|
unshift sequence is written before the position is altered.</li>
|
4653 |
|
|
<li>If there is an input buffer, the input sequence is updated after the
|
4654 |
|
|
position is altered.</li>
|
4655 |
|
|
</ul>
|
4656 |
|
|
<p>Plus the appropriate error handling, that is...</p>
|
4657 |
|
|
<p><b>Proposed resolution:</b></p>
|
4658 |
|
|
<p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
|
4659 |
|
|
paragraph 14 from:</p>
|
4660 |
|
|
<blockquote>
|
4661 |
|
|
<p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
|
4662 |
|
|
ios_base::out);</p>
|
4663 |
|
|
<p>Alters the file position, if possible, to correspond to the position stored
|
4664 |
|
|
in sp (as described below).</p>
|
4665 |
|
|
<p>- if (which&ios_base::in)!=0, set the file position to sp, then update
|
4666 |
|
|
the input sequence</p>
|
4667 |
|
|
<p>- if (which&ios_base::out)!=0, then update the output sequence, write
|
4668 |
|
|
any unshift sequence, and set the file position to sp.</p>
|
4669 |
|
|
</blockquote>
|
4670 |
|
|
<p>to:</p>
|
4671 |
|
|
<blockquote>
|
4672 |
|
|
<p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
|
4673 |
|
|
ios_base::out);</p>
|
4674 |
|
|
<p>Alters the file position, if possible, to correspond to the position stored
|
4675 |
|
|
in sp (as described below). Altering the file position performs as follows:</p>
|
4676 |
|
|
<p>1. if (om & ios_base::out)!=0, then update the output sequence and
|
4677 |
|
|
write any unshift sequence;</p>
|
4678 |
|
|
<p>2. set the file position to sp;</p>
|
4679 |
|
|
<p>3. if (om & ios_base::in)!=0, then update the input sequence;</p>
|
4680 |
|
|
<p>where om is the open mode passed to the last call to open(). The operation
|
4681 |
|
|
fails if is_open() returns false.</p>
|
4682 |
|
|
</blockquote>
|
4683 |
|
|
|
4684 |
|
|
<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
|
4685 |
|
|
<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
|
4686 |
|
|
<hr>
|
4687 |
|
|
<a name="172"><h3>172. Inconsistent types for <tt>basic_istream::ignore()</tt>
|
4688 |
|
|
</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
4689 |
|
|
<p>In 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> the function
|
4690 |
|
|
<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
|
4691 |
|
|
argument. However, in 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>
|
4692 |
|
|
paragraph 23 the first argument is of type <tt>int.</tt></p>
|
4693 |
|
|
|
4694 |
|
|
<p>As far as I can see this is not really a contradiction because
|
4695 |
|
|
everything is consistent if <tt>streamsize</tt> is typedef to be
|
4696 |
|
|
<tt>int</tt>. However, this is almost certainly not what was
|
4697 |
|
|
intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
|
4698 |
|
|
as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
|
4699 |
|
|
|
4700 |
|
|
<p>Darin Adler also
|
4701 |
|
|
submitted this issue, commenting: Either 27.6.1.1 should be modified
|
4702 |
|
|
to show a first parameter of type int, or 27.6.1.3 should be modified
|
4703 |
|
|
to show a first parameter of type streamsize and use
|
4704 |
|
|
numeric_limits<streamsize>::max.</p>
|
4705 |
|
|
<p><b>Proposed resolution:</b></p>
|
4706 |
|
|
<p>In 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> paragraph 23 and 24, change both uses
|
4707 |
|
|
of <tt>int</tt> in the description of <tt>ignore()</tt> to
|
4708 |
|
|
<tt>streamsize</tt>.</p>
|
4709 |
|
|
<hr>
|
4710 |
|
|
<a name="173"><h3>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
|
4711 |
|
|
</h3></a><p><b>Section:</b> 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
4712 |
|
|
|
4713 |
|
|
<p>
|
4714 |
|
|
In 27.8.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> the function <tt>setbuf()</tt> gets an
|
4715 |
|
|
object of type <tt>streamsize</tt> as second argument. However, in
|
4716 |
|
|
27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9 the second argument is of type
|
4717 |
|
|
<tt>int</tt>.
|
4718 |
|
|
</p>
|
4719 |
|
|
|
4720 |
|
|
<p>
|
4721 |
|
|
As far as I can see this is not really a contradiction because
|
4722 |
|
|
everything is consistent if <tt>streamsize</tt> is typedef to be
|
4723 |
|
|
<tt>int</tt>. However, this is almost certainly not what was
|
4724 |
|
|
intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
|
4725 |
|
|
as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
|
4726 |
|
|
</p>
|
4727 |
|
|
|
4728 |
|
|
<p><b>Proposed resolution:</b></p>
|
4729 |
|
|
<p>In 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9, change all uses of
|
4730 |
|
|
<tt>int</tt> in the description of <tt>setbuf()</tt> to
|
4731 |
|
|
<tt>streamsize</tt>.</p>
|
4732 |
|
|
<hr>
|
4733 |
|
|
<a name="174"><h3>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
|
4734 |
|
|
</h3></a><p><b>Section:</b> D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
4735 |
|
|
<p>According to paragraph 1 of this section, <tt>streampos</tt> is the
|
4736 |
|
|
type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
|
4737 |
|
|
paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
|
4738 |
|
|
<p><b>Proposed resolution:</b></p>
|
4739 |
|
|
<p>Change D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 1 from "<tt>typedef
|
4740 |
|
|
OFF_T streampos;</tt>" to "<tt>typedef POS_T
|
4741 |
|
|
streampos;</tt>"</p>
|
4742 |
|
|
<hr>
|
4743 |
|
|
<a name="175"><h3>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3></a><p><b>Section:</b> D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
4744 |
|
|
<p>According to paragraph 8 of this section, the methods
|
4745 |
|
|
<tt>basic_streambuf::pubseekpos()</tt>,
|
4746 |
|
|
<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
|
4747 |
|
|
"may" be overloaded by a version of this function taking the
|
4748 |
|
|
type <tt>ios_base::open_mode</tt> as last argument argument instead of
|
4749 |
|
|
<tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
|
4750 |
|
|
in this section to be an alias for one of the integral types). The
|
4751 |
|
|
clause specifies, that the last argument has a default argument in
|
4752 |
|
|
three cases. However, this generates an ambiguity with the overloaded
|
4753 |
|
|
version because now the arguments are absolutely identical if the last
|
4754 |
|
|
argument is not specified.</p>
|
4755 |
|
|
<p><b>Proposed resolution:</b></p>
|
4756 |
|
|
<p>In D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, remove the default arguments for
|
4757 |
|
|
<tt>basic_streambuf::pubseekpos()</tt>,
|
4758 |
|
|
<tt>basic_ifstream::open()</tt>, and
|
4759 |
|
|
<tt>basic_ofstream::open().</tt></p>
|
4760 |
|
|
<hr>
|
4761 |
|
|
<a name="176"><h3>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3></a><p><b>Section:</b> D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
4762 |
|
|
<p>The "overload" for the function <tt>exceptions()</tt> in
|
4763 |
|
|
paragraph 8 gives the impression that there is another function of
|
4764 |
|
|
this function defined in class <tt>ios_base</tt>. However, this is not
|
4765 |
|
|
the case. Thus, it is hard to tell how the semantics (paragraph 9) can
|
4766 |
|
|
be implemented: "Call the corresponding member function specified
|
4767 |
|
|
in clause 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>."</p>
|
4768 |
|
|
<p><b>Proposed resolution:</b></p>
|
4769 |
|
|
<p>In D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, move the declaration of the
|
4770 |
|
|
function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
|
4771 |
|
|
<hr>
|
4772 |
|
|
<a name="179"><h3>179. Comparison of const_iterators to iterators doesn't work</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 2 Jul 1998</p>
|
4773 |
|
|
<p>Currently the following will not compile on two well-known standard
|
4774 |
|
|
library implementations:</p>
|
4775 |
|
|
|
4776 |
|
|
<blockquote>
|
4777 |
|
|
<pre>#include <set>
|
4778 |
|
|
using namespace std;
|
4779 |
|
|
|
4780 |
|
|
void f(const set<int> &s)
|
4781 |
|
|
{
|
4782 |
|
|
set<int>::iterator i;
|
4783 |
|
|
if (i==s.end()); // s.end() returns a const_iterator
|
4784 |
|
|
}</pre>
|
4785 |
|
|
</blockquote>
|
4786 |
|
|
|
4787 |
|
|
<p>
|
4788 |
|
|
The reason this doesn't compile is because operator== was implemented
|
4789 |
|
|
as a member function of the nested classes set:iterator and
|
4790 |
|
|
set::const_iterator, and there is no conversion from const_iterator to
|
4791 |
|
|
iterator. Surprisingly, (s.end() == i) does work, though, because of
|
4792 |
|
|
the conversion from iterator to const_iterator.
|
4793 |
|
|
</p>
|
4794 |
|
|
|
4795 |
|
|
<p>
|
4796 |
|
|
I don't see a requirement anywhere in the standard that this must
|
4797 |
|
|
work. Should there be one? If so, I think the requirement would need
|
4798 |
|
|
to be added to the tables in section 24.1.1. I'm not sure about the
|
4799 |
|
|
wording. If this requirement existed in the standard, I would think
|
4800 |
|
|
that implementors would have to make the comparison operators
|
4801 |
|
|
non-member functions.</p>
|
4802 |
|
|
|
4803 |
|
|
<p>This issues was also raised on comp.std.c++ by Darin
|
4804 |
|
|
Adler. The example given was:</p>
|
4805 |
|
|
|
4806 |
|
|
<blockquote>
|
4807 |
|
|
<pre>bool check_equal(std::deque<int>::iterator i,
|
4808 |
|
|
std::deque<int>::const_iterator ci)
|
4809 |
|
|
{
|
4810 |
|
|
return i == ci;
|
4811 |
|
|
}</pre>
|
4812 |
|
|
</blockquote>
|
4813 |
|
|
|
4814 |
|
|
<p>Comment from John Potter:</p>
|
4815 |
|
|
<blockquote>
|
4816 |
|
|
<p>
|
4817 |
|
|
In case nobody has noticed, accepting it will break reverse_iterator.
|
4818 |
|
|
</p>
|
4819 |
|
|
|
4820 |
|
|
<p>
|
4821 |
|
|
The fix is to make the comparison operators templated on two types.
|
4822 |
|
|
</p>
|
4823 |
|
|
|
4824 |
|
|
<pre> template <class Iterator1, class Iterator2>
|
4825 |
|
|
bool operator== (reverse_iterator<Iterator1> const& x,
|
4826 |
|
|
reverse_iterator<Iterator2> const& y);
|
4827 |
|
|
</pre>
|
4828 |
|
|
|
4829 |
|
|
<p>
|
4830 |
|
|
Obviously: return x.base() == y.base();
|
4831 |
|
|
</p>
|
4832 |
|
|
|
4833 |
|
|
<p>
|
4834 |
|
|
Currently, no reverse_iterator to const_reverse_iterator compares are
|
4835 |
|
|
valid.
|
4836 |
|
|
</p>
|
4837 |
|
|
|
4838 |
|
|
<p>
|
4839 |
|
|
BTW, I think the issue is in support of bad code. Compares should be
|
4840 |
|
|
between two iterators of the same type. All std::algorithms require
|
4841 |
|
|
the begin and end iterators to be of the same type.
|
4842 |
|
|
</p>
|
4843 |
|
|
</blockquote>
|
4844 |
|
|
<p><b>Proposed resolution:</b></p>
|
4845 |
|
|
<p>Insert this paragraph after 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 7:</p>
|
4846 |
|
|
<blockquote>
|
4847 |
|
|
<p>In the expressions</p>
|
4848 |
|
|
<pre> i == j
|
4849 |
|
|
i != j
|
4850 |
|
|
i < j
|
4851 |
|
|
i <= j
|
4852 |
|
|
i >= j
|
4853 |
|
|
i > j
|
4854 |
|
|
i - j
|
4855 |
|
|
</pre>
|
4856 |
|
|
<p>Where i and j denote objects of a container's iterator type,
|
4857 |
|
|
either or both may be replaced by an object of the container's
|
4858 |
|
|
const_iterator type referring to the same element with no
|
4859 |
|
|
change in semantics.</p>
|
4860 |
|
|
</blockquote>
|
4861 |
|
|
|
4862 |
|
|
<p><i>[post-Toronto: Judy supplied a proposed resolution saying that
|
4863 |
|
|
<tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
|
4864 |
|
|
iterator comparison and difference operations.]</i></p>
|
4865 |
|
|
|
4866 |
|
|
<p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
|
4867 |
|
|
explicitly listed expressions; there was concern that the previous
|
4868 |
|
|
proposed resolution was too informal.]</i></p>
|
4869 |
|
|
<p><b>Rationale:</b></p>
|
4870 |
|
|
<p>
|
4871 |
|
|
The LWG believes it is clear that the above wording applies only to
|
4872 |
|
|
the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
|
4873 |
|
|
where <tt>X</tt> is a container. There is no requirement that
|
4874 |
|
|
<tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
|
4875 |
|
|
can be mixed. If mixing them is considered important, that's a
|
4876 |
|
|
separate issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
|
4877 |
|
|
</p>
|
4878 |
|
|
<hr>
|
4879 |
|
|
<a name="181"><h3>181. make_pair() unintended behavior</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 3 Aug 1999</p>
|
4880 |
|
|
<p>The claim has surfaced in Usenet that expressions such as<br>
|
4881 |
|
|
<br>
|
4882 |
|
|
<tt>make_pair("abc", 3)</tt><br>
|
4883 |
|
|
<br>
|
4884 |
|
|
are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
|
4885 |
|
|
parameter to <tt> const char (&)[4]</tt>, which type is uncopyable.<br>
|
4886 |
|
|
<br>
|
4887 |
|
|
I doubt anyone intended that behavior...
|
4888 |
|
|
</p>
|
4889 |
|
|
<p><b>Proposed resolution:</b></p>
|
4890 |
|
|
<p>In 20.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.utility"> [lib.utility]</a>, paragraph 1 change the following
|
4891 |
|
|
declaration of make_pair():</p>
|
4892 |
|
|
<blockquote>
|
4893 |
|
|
<pre>template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);</pre>
|
4894 |
|
|
</blockquote>
|
4895 |
|
|
<p>to:</p>
|
4896 |
|
|
<blockquote>
|
4897 |
|
|
<pre>template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);</pre>
|
4898 |
|
|
</blockquote>
|
4899 |
|
|
<p> In 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 7 and the line before, change:</p>
|
4900 |
|
|
<blockquote>
|
4901 |
|
|
<pre>template <class T1, class T2>
|
4902 |
|
|
pair<T1, T2> make_pair(const T1& x, const T2& y);</pre>
|
4903 |
|
|
</blockquote>
|
4904 |
|
|
<p>to:</p>
|
4905 |
|
|
<blockquote>
|
4906 |
|
|
<pre>template <class T1, class T2>
|
4907 |
|
|
pair<T1, T2> make_pair(T1 x, T2 y);</pre>
|
4908 |
|
|
</blockquote>
|
4909 |
|
|
<p>and add the following footnote to the effects clause:</p>
|
4910 |
|
|
<blockquote>
|
4911 |
|
|
<p> According to 12.8 [class.copy], an implementation is permitted
|
4912 |
|
|
to not perform a copy of an argument, thus avoiding unnecessary
|
4913 |
|
|
copies.</p>
|
4914 |
|
|
</blockquote>
|
4915 |
|
|
<p><b>Rationale:</b></p>
|
4916 |
|
|
<p>Two potential fixes were suggested by Matt Austern and Dietmar
|
4917 |
|
|
Kühl, respectively, 1) overloading with array arguments, and 2) use of
|
4918 |
|
|
a reference_traits class with a specialization for arrays. Andy
|
4919 |
|
|
Koenig suggested changing to pass by value. In discussion, it appeared
|
4920 |
|
|
that this was a much smaller change to the standard that the other two
|
4921 |
|
|
suggestions, and any efficiency concerns were more than offset by the
|
4922 |
|
|
advantages of the solution. Two implementors reported that the
|
4923 |
|
|
proposed resolution passed their test suites.</p>
|
4924 |
|
|
<hr>
|
4925 |
|
|
<a name="182"><h3>182. Ambiguous references to size_t</h3></a><p><b>Section:</b> 17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Al Stevens <b>Date:</b> 15 Aug 1999</p>
|
4926 |
|
|
<p>Many references to <tt> size_t</tt> throughout the document
|
4927 |
|
|
omit the <tt> std::</tt> namespace qualification.</p> <p>For
|
4928 |
|
|
example, 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2:</p>
|
4929 |
|
|
<blockquote>
|
4930 |
|
|
<pre>— operator new(size_t)
|
4931 |
|
|
— operator new(size_t, const std::nothrow_t&)
|
4932 |
|
|
— operator new[](size_t)
|
4933 |
|
|
— operator new[](size_t, const std::nothrow_t&)</pre>
|
4934 |
|
|
</blockquote>
|
4935 |
|
|
<p><b>Proposed resolution:</b></p>
|
4936 |
|
|
<p> In 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2: replace:</p>
|
4937 |
|
|
<blockquote>
|
4938 |
|
|
<p><tt> - operator new(size_t)<br>
|
4939 |
|
|
- operator new(size_t, const std::nothrow_t&)<br>
|
4940 |
|
|
- operator new[](size_t)<br>
|
4941 |
|
|
- operator new[](size_t, const std::nothrow_t&)</tt></p>
|
4942 |
|
|
</blockquote>
|
4943 |
|
|
<p> by:</p>
|
4944 |
|
|
<blockquote>
|
4945 |
|
|
<pre>- operator new(std::size_t)
|
4946 |
|
|
- operator new(std::size_t, const std::nothrow_t&)
|
4947 |
|
|
- operator new[](std::size_t)
|
4948 |
|
|
- operator new[](std::size_t, const std::nothrow_t&)</pre>
|
4949 |
|
|
</blockquote>
|
4950 |
|
|
<p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
|
4951 |
|
|
<blockquote>
|
4952 |
|
|
<p>The typedef members pointer, const_pointer, size_type, and difference_type
|
4953 |
|
|
are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
|
4954 |
|
|
</blockquote>
|
4955 |
|
|
<p> by:</p>
|
4956 |
|
|
<blockquote>
|
4957 |
|
|
<p>The typedef members pointer, const_pointer, size_type, and difference_type
|
4958 |
|
|
are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
|
4959 |
|
|
respectively.</p>
|
4960 |
|
|
</blockquote>
|
4961 |
|
|
<p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
|
4962 |
|
|
<blockquote>
|
4963 |
|
|
<p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
|
4964 |
|
|
<p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
|
4965 |
|
|
is unspecified when or how often this function is called. The use of hint is
|
4966 |
|
|
unspecified, but intended as an aid to locality if an implementation so
|
4967 |
|
|
desires.</p>
|
4968 |
|
|
</blockquote>
|
4969 |
|
|
<p>by:</p>
|
4970 |
|
|
<blockquote>
|
4971 |
|
|
<p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
|
4972 |
|
|
<p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
|
4973 |
|
|
it is unspecified when or how often this function is called. The use of hint
|
4974 |
|
|
is unspecified, but intended as an aid to locality if an implementation so
|
4975 |
|
|
desires.</p>
|
4976 |
|
|
</blockquote>
|
4977 |
|
|
<p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
|
4978 |
|
|
<blockquote>
|
4979 |
|
|
<p>In Table 37, X denotes a Traits class defining types and functions for the
|
4980 |
|
|
character container type CharT; c and d denote values of type CharT; p and q
|
4981 |
|
|
denote values of type const CharT*; s denotes a value of type CharT*; n, i and
|
4982 |
|
|
j denote values of type size_t; e and f denote values of type X::int_type; pos
|
4983 |
|
|
denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
|
4984 |
|
|
</blockquote>
|
4985 |
|
|
<p>by:</p>
|
4986 |
|
|
<blockquote>
|
4987 |
|
|
<p>In Table 37, X denotes a Traits class defining types and functions for the
|
4988 |
|
|
character container type CharT; c and d denote values of type CharT; p and q
|
4989 |
|
|
denote values of type const CharT*; s denotes a value of type CharT*; n, i and
|
4990 |
|
|
j denote values of type std::size_t; e and f denote values of type X::int_type;
|
4991 |
|
|
pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
|
4992 |
|
|
</blockquote>
|
4993 |
|
|
<p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
|
4994 |
|
|
X::length(p): "size_t" by "std::size_t".</p>
|
4995 |
|
|
<p> In [lib.std.iterator.tags] 24.3.3, paragraph 2: replace:<br>
|
4996 |
|
|
typedef ptrdiff_t difference_type;<br>
|
4997 |
|
|
by:<br>
|
4998 |
|
|
typedef std::ptrdiff_t difference_type;</p>
|
4999 |
|
|
<p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
|
5000 |
|
|
declaration of template <class charT> class ctype.<br>
|
5001 |
|
|
<br>
|
5002 |
|
|
In [lib.iterator.traits] 24.3.1, paragraph 2 put namespace std { ...} around the declaration of:<br>
|
5003 |
|
|
<br>
|
5004 |
|
|
template<class Iterator> struct iterator_traits<br>
|
5005 |
|
|
template<class T> struct iterator_traits<T*><br>
|
5006 |
|
|
template<class T> struct iterator_traits<const T*></p>
|
5007 |
|
|
<p><b>Rationale:</b></p>
|
5008 |
|
|
<p>The LWG believes correcting names like <tt>size_t</tt> and
|
5009 |
|
|
<tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
|
5010 |
|
|
to be essentially editorial. There there can't be another size_t or
|
5011 |
|
|
ptrdiff_t meant anyway because, according to 17.4.3.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.extern.types"> [lib.extern.types]</a>,</p>
|
5012 |
|
|
|
5013 |
|
|
<blockquote>
|
5014 |
|
|
For each type T from the Standard C library, the types ::T and std::T
|
5015 |
|
|
are reserved to the implementation and, when defined, ::T shall be
|
5016 |
|
|
identical to std::T.
|
5017 |
|
|
</blockquote>
|
5018 |
|
|
|
5019 |
|
|
<p>The issue is treated as a Defect Report to make explicit the Project
|
5020 |
|
|
Editor's authority to make this change.</p>
|
5021 |
|
|
|
5022 |
|
|
<p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
|
5023 |
|
|
request of the LWG.]</i></p>
|
5024 |
|
|
|
5025 |
|
|
<p><i>[Toronto: This is tangentially related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, but only tangentially: the intent of this issue is to
|
5026 |
|
|
address use of the name <tt>size_t</tt> in contexts outside of
|
5027 |
|
|
namespace std, such as in the description of <tt>::operator new</tt>.
|
5028 |
|
|
The proposed changes should be reviewed to make sure they are
|
5029 |
|
|
correct.]</i></p>
|
5030 |
|
|
|
5031 |
|
|
<p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
|
5032 |
|
|
them to be correct.]</i></p>
|
5033 |
|
|
|
5034 |
|
|
<hr>
|
5035 |
|
|
<a name="183"><h3>183. I/O stream manipulators don't work for wide character streams</h3></a><p><b>Section:</b> 27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 7 Jul 1999</p>
|
5036 |
|
|
<p>27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> paragraph 3 says (clause numbering added for
|
5037 |
|
|
exposition):</p>
|
5038 |
|
|
<blockquote>
|
5039 |
|
|
<p>Returns: An object s of unspecified type such that if [1] out is an (instance
|
5040 |
|
|
of) basic_ostream then the expression out<<s behaves as if f(s) were
|
5041 |
|
|
called, and if [2] in is an (instance of) basic_istream then the expression
|
5042 |
|
|
in>>s behaves as if f(s) were called. Where f can be defined as: ios_base&
|
5043 |
|
|
f(ios_base& str, ios_base::fmtflags mask) { // reset specified flags
|
5044 |
|
|
str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
|
5045 |
|
|
out<<s has type ostream& and value out. [4] The expression in>>s
|
5046 |
|
|
has type istream& and value in.</p>
|
5047 |
|
|
</blockquote>
|
5048 |
|
|
<p>Given the definitions [1] and [2] for out and in, surely [3] should read:
|
5049 |
|
|
"The expression out << s has type basic_ostream& ..." and
|
5050 |
|
|
[4] should read: "The expression in >> s has type basic_istream&
|
5051 |
|
|
..."</p>
|
5052 |
|
|
<p>If the wording in the standard is correct, I can see no way of implementing
|
5053 |
|
|
any of the manipulators so that they will work with wide character streams.</p>
|
5054 |
|
|
<p>e.g. wcout << setbase( 16 );</p>
|
5055 |
|
|
<p>Must have value 'wcout' (which makes sense) and type 'ostream&' (which
|
5056 |
|
|
doesn't).</p>
|
5057 |
|
|
<p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
|
5058 |
|
|
8. In addition, Para 6 [setfill] has a similar error, but relates only to
|
5059 |
|
|
ostreams.</p>
|
5060 |
|
|
<p>I'd be happier if there was a better way of saying this, to make it clear
|
5061 |
|
|
that the value of the expression is "the same specialization of
|
5062 |
|
|
basic_ostream as out"&</p>
|
5063 |
|
|
<p><b>Proposed resolution:</b></p>
|
5064 |
|
|
<p>Replace section 27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> except paragraph 1 with the
|
5065 |
|
|
following:</p>
|
5066 |
|
|
<blockquote>
|
5067 |
|
|
<p>2- The type designated smanip in each of the following function
|
5068 |
|
|
descriptions is implementation-specified and may be different for each
|
5069 |
|
|
function.<br>
|
5070 |
|
|
<br>
|
5071 |
|
|
<tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
|
5072 |
|
|
<br>
|
5073 |
|
|
-3- Returns: An object s of unspecified type such that if out is an
|
5074 |
|
|
instance of basic_ostream<charT,traits> then the expression
|
5075 |
|
|
out<<s behaves
|
5076 |
|
|
as if f(s, mask) were called, or if in is an instance of
|
5077 |
|
|
basic_istream<charT,traits> then the expression in>>s
|
5078 |
|
|
behaves as if
|
5079 |
|
|
f(s, mask) were called. The function f can be defined as:*<br>
|
5080 |
|
|
<br>
|
5081 |
|
|
[Footnote: The expression cin >> resetiosflags(ios_base::skipws)
|
5082 |
|
|
clears ios_base::skipws in the format flags stored in the
|
5083 |
|
|
basic_istream<charT,traits> object cin (the same as cin >>
|
5084 |
|
|
noskipws), and the expression cout <<
|
5085 |
|
|
resetiosflags(ios_base::showbase) clears
|
5086 |
|
|
ios_base::showbase in the format flags stored in the
|
5087 |
|
|
basic_ostream<charT,traits> object cout (the same as cout
|
5088 |
|
|
<<
|
5089 |
|
|
noshowbase). --- end footnote]<br>
|
5090 |
|
|
<br>
|
5091 |
|
|
<tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br>
|
5092 |
|
|
{<br>
|
5093 |
|
|
// reset specified flags<br>
|
5094 |
|
|
str.setf(ios_base::fmtflags(0), mask);<br>
|
5095 |
|
|
return str;<br>
|
5096 |
|
|
}<br>
|
5097 |
|
|
</tt><br>
|
5098 |
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
5099 |
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
|
5100 |
|
|
<br>
|
5101 |
|
|
<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
|
5102 |
|
|
<br>
|
5103 |
|
|
-4- Returns: An object s of unspecified type such that if out is an
|
5104 |
|
|
instance of basic_ostream<charT,traits> then the expression
|
5105 |
|
|
out<<s behaves
|
5106 |
|
|
as if f(s, mask) were called, or if in is an instance of
|
5107 |
|
|
basic_istream<charT,traits> then the expression in>>s
|
5108 |
|
|
behaves as if f(s,
|
5109 |
|
|
mask) were called. The function f can be defined as:<br>
|
5110 |
|
|
<br>
|
5111 |
|
|
<tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br>
|
5112 |
|
|
{<br>
|
5113 |
|
|
// set specified flags<br>
|
5114 |
|
|
str.setf(mask);<br>
|
5115 |
|
|
return str;<br>
|
5116 |
|
|
}<br>
|
5117 |
|
|
</tt><br>
|
5118 |
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
5119 |
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
|
5120 |
|
|
<br>
|
5121 |
|
|
<tt>smanip setbase(int base);</tt><br>
|
5122 |
|
|
<br>
|
5123 |
|
|
-5- Returns: An object s of unspecified type such that if out is an
|
5124 |
|
|
instance of basic_ostream<charT,traits> then the expression
|
5125 |
|
|
out<<s behaves
|
5126 |
|
|
as if f(s, base) were called, or if in is an instance of
|
5127 |
|
|
basic_istream<charT,traits> then the expression in>>s
|
5128 |
|
|
behaves as if f(s,
|
5129 |
|
|
base) were called. The function f can be defined as:<br>
|
5130 |
|
|
<br>
|
5131 |
|
|
<tt>ios_base& f(ios_base& str, int base)<br>
|
5132 |
|
|
{<br>
|
5133 |
|
|
// set basefield<br>
|
5134 |
|
|
str.setf(base == 8 ? ios_base::oct :<br>
|
5135 |
|
|
base == 10 ? ios_base::dec :<br>
|
5136 |
|
|
base == 16 ? ios_base::hex :<br>
|
5137 |
|
|
ios_base::fmtflags(0), ios_base::basefield);<br>
|
5138 |
|
|
return str;<br>
|
5139 |
|
|
}<br>
|
5140 |
|
|
</tt><br>
|
5141 |
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
5142 |
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in.<br>
|
5143 |
|
|
<br>
|
5144 |
|
|
<tt>smanip setfill(char_type c);<br>
|
5145 |
|
|
</tt><br>
|
5146 |
|
|
-6- Returns: An object s of unspecified type such that if out is (or is
|
5147 |
|
|
derived from) basic_ostream<charT,traits> and c has type charT
|
5148 |
|
|
then the
|
5149 |
|
|
expression out<<s behaves as if f(s, c) were called. The function
|
5150 |
|
|
f can be
|
5151 |
|
|
defined as:<br>
|
5152 |
|
|
<br>
|
5153 |
|
|
<tt>template<class charT, class traits><br>
|
5154 |
|
|
basic_ios<charT,traits>& f(basic_ios<charT,traits>& str, charT c)<br>
|
5155 |
|
|
{<br>
|
5156 |
|
|
// set fill character<br>
|
5157 |
|
|
str.fill(c);<br>
|
5158 |
|
|
return str;<br>
|
5159 |
|
|
}<br>
|
5160 |
|
|
</tt><br>
|
5161 |
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.<br>
|
5162 |
|
|
<br>
|
5163 |
|
|
<tt>smanip setprecision(int n);</tt><br>
|
5164 |
|
|
<br>
|
5165 |
|
|
-7- Returns: An object s of unspecified type such that if out is an
|
5166 |
|
|
instance of basic_ostream<charT,traits> then the expression
|
5167 |
|
|
out<<s behaves
|
5168 |
|
|
as if f(s, n) were called, or if in is an instance of
|
5169 |
|
|
basic_istream<charT,traits> then the expression in>>s
|
5170 |
|
|
behaves as if f(s, n)
|
5171 |
|
|
were called. The function f can be defined as:<br>
|
5172 |
|
|
<br>
|
5173 |
|
|
<tt>ios_base& f(ios_base& str, int n)<br>
|
5174 |
|
|
{<br>
|
5175 |
|
|
// set precision<br>
|
5176 |
|
|
str.precision(n);<br>
|
5177 |
|
|
return str;<br>
|
5178 |
|
|
}<br>
|
5179 |
|
|
</tt><br>
|
5180 |
|
|
The expression out<<s has type basic_ostream<charT,traits>& and value out.
|
5181 |
|
|
The expression in>>s has type basic_istream<charT,traits>& and value in<br>
|
5182 |
|
|
.<br>
|
5183 |
|
|
<tt>smanip setw(int n);<br>
|
5184 |
|
|
</tt><br>
|
5185 |
|
|
-8- Returns: An object s of unspecified type such that if out is an
|
5186 |
|
|
instance of basic_ostream<charT,traits> then the expression
|
5187 |
|
|
out<<s behaves
|
5188 |
|
|
as if f(s, n) were called, or if in is an instance of
|
5189 |
|
|
basic_istream<charT,traits> then the expression in>>s
|
5190 |
|
|
behaves as if f(s, n)
|
5191 |
|
|
were called. The function f can be defined as:<br>
|
5192 |
|
|
<br>
|
5193 |
|
|
<tt>ios_base& f(ios_base& str, int n)<br>
|
5194 |
|
|
{<br>
|
5195 |
|
|
// set width<br>
|
5196 |
|
|
str.width(n);<br>
|
5197 |
|
|
return str;<br>
|
5198 |
|
|
}<br>
|
5199 |
|
|
</tt><br>
|
5200 |
|
|
The expression out<<s has type
|
5201 |
|
|
basic_ostream<charT,traits>& and value out. The expression
|
5202 |
|
|
in>>s has type basic_istream<charT,traits>& and value
|
5203 |
|
|
in.
|
5204 |
|
|
</p>
|
5205 |
|
|
</blockquote>
|
5206 |
|
|
|
5207 |
|
|
<p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
|
5208 |
|
|
the proposed resolution.]</i></p>
|
5209 |
|
|
|
5210 |
|
|
<p><i>[Tokyo - The LWG noted that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> involves
|
5211 |
|
|
the same paragraphs.]</i></p>
|
5212 |
|
|
|
5213 |
|
|
<p><i>[Post-Tokyo: The issues list maintainer combined the proposed
|
5214 |
|
|
resolution of this issue with the proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
|
5215 |
|
|
intertwined that dealing with them separately appear fraught with
|
5216 |
|
|
error. The full text was supplied by Bill Plauger; it was cross
|
5217 |
|
|
checked against changes supplied by Andy Sawyer. It should be further
|
5218 |
|
|
checked by the LWG.]</i></p>
|
5219 |
|
|
<hr>
|
5220 |
|
|
<a name="184"><h3>184. numeric_limits<bool> wording problems</h3></a><p><b>Section:</b> 18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 21 Jul 1999</p>
|
5221 |
|
|
<p>bools are defined by the standard to be of integer types, as per
|
5222 |
|
|
3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.fundamental"> [basic.fundamental]</a> paragraph 7. However "integer types"
|
5223 |
|
|
seems to have a special meaning for the author of 18.2. The net effect
|
5224 |
|
|
is an unclear and confusing specification for
|
5225 |
|
|
numeric_limits<bool> as evidenced below.</p>
|
5226 |
|
|
|
5227 |
|
|
<p>18.2.1.2/7 says numeric_limits<>::digits is, for built-in integer
|
5228 |
|
|
types, the number of non-sign bits in the representation.</p>
|
5229 |
|
|
|
5230 |
|
|
<p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
|
5231 |
|
|
arithmetical value converts to true.</p>
|
5232 |
|
|
|
5233 |
|
|
<p>I don't think it makes sense at all to require
|
5234 |
|
|
numeric_limits<bool>::digits and numeric_limits<bool>::digits10 to
|
5235 |
|
|
be meaningful.</p>
|
5236 |
|
|
|
5237 |
|
|
<p>The standard defines what constitutes a signed (resp. unsigned) integer
|
5238 |
|
|
types. It doesn't categorize bool as being signed or unsigned. And the set of
|
5239 |
|
|
values of bool type has only two elements.</p>
|
5240 |
|
|
|
5241 |
|
|
<p>I don't think it makes sense to require numeric_limits<bool>::is_signed
|
5242 |
|
|
to be meaningful.</p>
|
5243 |
|
|
|
5244 |
|
|
<p>18.2.1.2/18 for numeric_limits<integer_type>::radix says:</p>
|
5245 |
|
|
<blockquote>
|
5246 |
|
|
<p>For integer types, specifies the base of the representation.186)</p>
|
5247 |
|
|
</blockquote>
|
5248 |
|
|
|
5249 |
|
|
<p>This disposition is at best misleading and confusing for the standard
|
5250 |
|
|
requires a "pure binary numeration system" for integer types as per
|
5251 |
|
|
3.9.1/7</p>
|
5252 |
|
|
|
5253 |
|
|
<p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
|
5254 |
|
|
BCD)." This also erroneous as the standard never defines any integer
|
5255 |
|
|
types with base representation other than 2.</p>
|
5256 |
|
|
|
5257 |
|
|
<p>Furthermore, numeric_limits<bool>::is_modulo and
|
5258 |
|
|
numeric_limits<bool>::is_signed have similar problems.</p>
|
5259 |
|
|
<p><b>Proposed resolution:</b></p>
|
5260 |
|
|
<p>Append to the end of 18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>:</p>
|
5261 |
|
|
<blockquote>
|
5262 |
|
|
<p>The specialization for bool shall be provided as follows:</p>
|
5263 |
|
|
<pre> namespace std {
|
5264 |
|
|
template<> class numeric_limits<bool> {
|
5265 |
|
|
public:
|
5266 |
|
|
static const bool is_specialized = true;
|
5267 |
|
|
static bool min() throw() { return false; }
|
5268 |
|
|
static bool max() throw() { return true; }
|
5269 |
|
|
|
5270 |
|
|
static const int digits = 1;
|
5271 |
|
|
static const int digits10 = 0;
|
5272 |
|
|
static const bool is_signed = false;
|
5273 |
|
|
static const bool is_integer = true;
|
5274 |
|
|
static const bool is_exact = true;
|
5275 |
|
|
static const int radix = 2;
|
5276 |
|
|
static bool epsilon() throw() { return 0; }
|
5277 |
|
|
static bool round_error() throw() { return 0; }
|
5278 |
|
|
|
5279 |
|
|
static const int min_exponent = 0;
|
5280 |
|
|
static const int min_exponent10 = 0;
|
5281 |
|
|
static const int max_exponent = 0;
|
5282 |
|
|
static const int max_exponent10 = 0;
|
5283 |
|
|
|
5284 |
|
|
static const bool has_infinity = false;
|
5285 |
|
|
static const bool has_quiet_NaN = false;
|
5286 |
|
|
static const bool has_signaling_NaN = false;
|
5287 |
|
|
static const float_denorm_style has_denorm = denorm_absent;
|
5288 |
|
|
static const bool has_denorm_loss = false;
|
5289 |
|
|
static bool infinity() throw() { return 0; }
|
5290 |
|
|
static bool quiet_NaN() throw() { return 0; }
|
5291 |
|
|
static bool signaling_NaN() throw() { return 0; }
|
5292 |
|
|
static bool denorm_min() throw() { return 0; }
|
5293 |
|
|
|
5294 |
|
|
static const bool is_iec559 = false;
|
5295 |
|
|
static const bool is_bounded = true;
|
5296 |
|
|
static const bool is_modulo = false;
|
5297 |
|
|
|
5298 |
|
|
static const bool traps = false;
|
5299 |
|
|
static const bool tinyness_before = false;
|
5300 |
|
|
static const float_round_style round_style = round_toward_zero;
|
5301 |
|
|
};
|
5302 |
|
|
}</pre>
|
5303 |
|
|
</blockquote>
|
5304 |
|
|
|
5305 |
|
|
<p><i>[Tokyo: The LWG desires wording that specifies exact values
|
5306 |
|
|
rather than more general wording in the original proposed
|
5307 |
|
|
resolution.]</i></p>
|
5308 |
|
|
|
5309 |
|
|
<p><i>[Post-Tokyo: At the request of the LWG in Tokyo, Nico
|
5310 |
|
|
Josuttis provided the above wording.]</i></p>
|
5311 |
|
|
<hr>
|
5312 |
|
|
<a name="185"><h3>185. Questionable use of term "inline"</h3></a><p><b>Section:</b> 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> UK Panel <b>Date:</b> 26 Jul 1999</p>
|
5313 |
|
|
<p>Paragraph 4 of 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> says:</p>
|
5314 |
|
|
<blockquote>
|
5315 |
|
|
<p> [Example: To negate every element of a: transform(a.begin(), a.end(),
|
5316 |
|
|
a.begin(), negate<double>()); The corresponding functions will inline
|
5317 |
|
|
the addition and the negation. end example]</p>
|
5318 |
|
|
</blockquote>
|
5319 |
|
|
<p>(Note: The "addition" referred to in the above is in para 3) we can
|
5320 |
|
|
find no other wording, except this (non-normative) example which suggests that
|
5321 |
|
|
any "inlining" will take place in this case.</p>
|
5322 |
|
|
<p>Indeed both:</p>
|
5323 |
|
|
<blockquote>
|
5324 |
|
|
<p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
|
5325 |
|
|
unspecified whether any global functions in the C++ Standard Library
|
5326 |
|
|
are defined as inline (7.1.2).</p>
|
5327 |
|
|
</blockquote>
|
5328 |
|
|
<p>and</p>
|
5329 |
|
|
<blockquote>
|
5330 |
|
|
<p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
|
5331 |
|
|
unspecified whether any member functions in the C++ Standard Library
|
5332 |
|
|
are defined as inline (7.1.2).</p>
|
5333 |
|
|
</blockquote>
|
5334 |
|
|
<p>take care to state that this may indeed NOT be the case.</p>
|
5335 |
|
|
<p>Thus the example "mandates" behavior that is explicitly
|
5336 |
|
|
not required elsewhere.</p>
|
5337 |
|
|
<p><b>Proposed resolution:</b></p>
|
5338 |
|
|
<p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 1, remove the sentence:</p>
|
5339 |
|
|
<blockquote>
|
5340 |
|
|
<p>They are important for the effective use of the library.</p>
|
5341 |
|
|
</blockquote>
|
5342 |
|
|
<p>Remove 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 2, which reads:</p>
|
5343 |
|
|
<blockquote>
|
5344 |
|
|
<p> Using function objects together with function templates
|
5345 |
|
|
increases the expressive power of the library as well as making the
|
5346 |
|
|
resulting code much more efficient.</p>
|
5347 |
|
|
</blockquote>
|
5348 |
|
|
<p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.objects"> [lib.function.objects]</a> paragraph 4, remove the sentence:</p>
|
5349 |
|
|
<blockquote>
|
5350 |
|
|
<p>The corresponding functions will inline the addition and the
|
5351 |
|
|
negation.</p>
|
5352 |
|
|
</blockquote>
|
5353 |
|
|
|
5354 |
|
|
<p><i>[Kona: The LWG agreed there was a defect.]</i></p>
|
5355 |
|
|
<p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
|
5356 |
|
|
<hr>
|
5357 |
|
|
<a name="186"><h3>186. bitset::set() second parameter should be bool</h3></a><p><b>Section:</b> 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Darin Adler <b>Date:</b> 13 Aug 1999</p>
|
5358 |
|
|
<p>In section 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, paragraph 13 defines the
|
5359 |
|
|
bitset::set operation to take a second parameter of type int. The
|
5360 |
|
|
function tests whether this value is non-zero to determine whether to
|
5361 |
|
|
set the bit to true or false. The type of this second parameter should
|
5362 |
|
|
be bool. For one thing, the intent is to specify a Boolean value. For
|
5363 |
|
|
another, the result type from test() is bool. In addition, it's
|
5364 |
|
|
possible to slice an integer that's larger than an int. This can't
|
5365 |
|
|
happen with bool, since conversion to bool has the semantic of
|
5366 |
|
|
translating 0 to false and any non-zero value to true.</p>
|
5367 |
|
|
<p><b>Proposed resolution:</b></p>
|
5368 |
|
|
<p>In 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> Para 1 Replace:</p>
|
5369 |
|
|
<blockquote>
|
5370 |
|
|
<pre>bitset<N>& set(size_t pos, int val = true ); </pre>
|
5371 |
|
|
</blockquote>
|
5372 |
|
|
<p>With:</p>
|
5373 |
|
|
<blockquote>
|
5374 |
|
|
<pre>bitset<N>& set(size_t pos, bool val = true );</pre>
|
5375 |
|
|
</blockquote>
|
5376 |
|
|
<p>In 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> Para 12(.5) Replace:</p>
|
5377 |
|
|
<blockquote>
|
5378 |
|
|
<pre>bitset<N>& set(size_t pos, int val = 1 );</pre>
|
5379 |
|
|
</blockquote>
|
5380 |
|
|
<p>With:</p>
|
5381 |
|
|
<blockquote>
|
5382 |
|
|
<pre>bitset<N>& set(size_t pos, bool val = true );</pre>
|
5383 |
|
|
</blockquote>
|
5384 |
|
|
|
5385 |
|
|
<p><i>[Kona: The LWG agrees with the description. Andy Sawyer will work
|
5386 |
|
|
on better P/R wording.]</i></p>
|
5387 |
|
|
<p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
|
5388 |
|
|
<p><b>Rationale:</b></p>
|
5389 |
|
|
<p><tt>bool</tt> is a better choice. It is believed that binary
|
5390 |
|
|
compatibility is not an issue, because this member function is
|
5391 |
|
|
usually implemented as <tt>inline</tt>, and because it is already
|
5392 |
|
|
the case that users cannot rely on the type of a pointer to a
|
5393 |
|
|
nonvirtual member of a standard library class.</p>
|
5394 |
|
|
<hr>
|
5395 |
|
|
<a name="187"><h3>187. iter_swap underspecified</h3></a><p><b>Section:</b> 25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 14 Aug 1999</p>
|
5396 |
|
|
<p>The description of iter_swap in 25.2.2 paragraph 7,says that it
|
5397 |
|
|
``exchanges the values'' of the objects to which two iterators
|
5398 |
|
|
refer.<br> <br> What it doesn't say is whether it does so using swap
|
5399 |
|
|
or using the assignment operator and copy constructor.<br> <br> This
|
5400 |
|
|
question is an important one to answer, because swap is specialized to
|
5401 |
|
|
work efficiently for standard containers.<br> For example:</p>
|
5402 |
|
|
<blockquote>
|
5403 |
|
|
<pre>vector<int> v1, v2;
|
5404 |
|
|
iter_swap(&v1, &v2);</pre>
|
5405 |
|
|
</blockquote>
|
5406 |
|
|
<p>Is this call to iter_swap equivalent to calling swap(v1, v2)?
|
5407 |
|
|
Or is it equivalent to</p>
|
5408 |
|
|
<blockquote>
|
5409 |
|
|
<pre>{
|
5410 |
|
|
vector<int> temp = v1;
|
5411 |
|
|
v1 = v2;
|
5412 |
|
|
v2 = temp;
|
5413 |
|
|
}</pre>
|
5414 |
|
|
</blockquote>
|
5415 |
|
|
<p>The first alternative is O(1); the second is O(n).</p>
|
5416 |
|
|
<p>A LWG member, Dave Abrahams, comments:</p>
|
5417 |
|
|
<blockquote>
|
5418 |
|
|
<p>Not an objection necessarily, but I want to point out the cost of
|
5419 |
|
|
that requirement:</p>
|
5420 |
|
|
<blockquote>
|
5421 |
|
|
<p><tt>iter_swap(list<T>::iterator, list<T>::iterator)</tt></p>
|
5422 |
|
|
</blockquote>
|
5423 |
|
|
<p>can currently be specialized to be more efficient than
|
5424 |
|
|
iter_swap(T*,T*) for many T (by using splicing). Your proposal would
|
5425 |
|
|
make that optimization illegal. </p>
|
5426 |
|
|
</blockquote>
|
5427 |
|
|
|
5428 |
|
|
<p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
|
5429 |
|
|
which are no longer permitted.]</i></p>
|
5430 |
|
|
<p><b>Proposed resolution:</b></p>
|
5431 |
|
|
<p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
|
5432 |
|
|
<blockquote>
|
5433 |
|
|
<p>Exchanges the values pointed to by the two iterators a and b.</p>
|
5434 |
|
|
</blockquote>
|
5435 |
|
|
<p>to</p>
|
5436 |
|
|
<blockquote>
|
5437 |
|
|
<p><tt>swap(*a, *b)</tt>.</p>
|
5438 |
|
|
</blockquote>
|
5439 |
|
|
|
5440 |
|
|
<p><b>Rationale:</b></p>
|
5441 |
|
|
<p>It's useful to say just what <tt>iter_swap</tt> does. There may be
|
5442 |
|
|
some iterators for which we want to specialize <tt>iter_swap</tt>,
|
5443 |
|
|
but the fully general version should have a general specification.</p>
|
5444 |
|
|
|
5445 |
|
|
<p>Note that in the specific case of <tt>list<T>::iterator</tt>,
|
5446 |
|
|
iter_swap should not be specialized as suggested above. That would do
|
5447 |
|
|
much more than exchanging the two iterators' values: it would change
|
5448 |
|
|
predecessor/successor relationships, possibly moving the iterator from
|
5449 |
|
|
one list to another. That would surely be inappropriate.</p>
|
5450 |
|
|
<hr>
|
5451 |
|
|
<a name="189"><h3>189. setprecision() not specified correctly</h3></a><p><b>Section:</b> 27.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 25 Aug 1999</p>
|
5452 |
|
|
<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
|
5453 |
|
|
and includes a parenthetical note saying that it is the number of
|
5454 |
|
|
digits after the decimal point.<br>
|
5455 |
|
|
<br>
|
5456 |
|
|
This claim is not strictly correct. For example, in the default
|
5457 |
|
|
floating-point output format, setprecision sets the number of
|
5458 |
|
|
significant digits printed, not the number of digits after the decimal
|
5459 |
|
|
point.<br>
|
5460 |
|
|
<br>
|
5461 |
|
|
I would like the committee to look at the definition carefully and
|
5462 |
|
|
correct the statement in 27.4.2.2</p>
|
5463 |
|
|
<p><b>Proposed resolution:</b></p>
|
5464 |
|
|
<p>Remove from 27.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a>, paragraph 9, the text
|
5465 |
|
|
"(number of digits after the decimal point)".</p>
|
5466 |
|
|
<hr>
|
5467 |
|
|
<a name="193"><h3>193. Heap operations description incorrect</h3></a><p><b>Section:</b> 25.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 24 Sep 1999</p>
|
5468 |
|
|
<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
|
5469 |
|
|
is<br>
|
5470 |
|
|
<br>
|
5471 |
|
|
`"(1) *a is the largest element"<br>
|
5472 |
|
|
<br>
|
5473 |
|
|
I think this is incorrect and should be changed to the wording in the proposed
|
5474 |
|
|
resolution.</p>
|
5475 |
|
|
<p>Actually there are two independent changes:</p>
|
5476 |
|
|
<blockquote>
|
5477 |
|
|
<p>A-"part of largest equivalence class" instead of "largest", cause 25.3
|
5478 |
|
|
[lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
|
5479 |
|
|
<p>B-Take
|
5480 |
|
|
'an oldest' from that equivalence class, otherwise the heap functions
|
5481 |
|
|
could not be used for a priority queue as explained in 23.2.3.2.2
|
5482 |
|
|
[lib.priqueue.members] (where I assume that a "priority queue" respects
|
5483 |
|
|
priority AND time).</p>
|
5484 |
|
|
</blockquote>
|
5485 |
|
|
<p><b>Proposed resolution:</b></p>
|
5486 |
|
|
<p>Change 25.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> property (1) from:</p>
|
5487 |
|
|
<blockquote>
|
5488 |
|
|
<p>(1) *a is the largest element</p>
|
5489 |
|
|
</blockquote>
|
5490 |
|
|
<p>to:</p>
|
5491 |
|
|
<blockquote>
|
5492 |
|
|
<p>(1) There is no element greater than <tt>*a</tt></p>
|
5493 |
|
|
</blockquote>
|
5494 |
|
|
<hr>
|
5495 |
|
|
<a name="195"><h3>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3></a><p><b>Section:</b> 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 13 Oct 1999</p>
|
5496 |
|
|
<p>Suppose that <tt>is.flags() & ios_base::skipws</tt> is nonzero.
|
5497 |
|
|
What should <tt>basic_istream<>::sentry</tt>'s constructor do if it
|
5498 |
|
|
reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it
|
5499 |
|
|
should set failbit. Should it set eofbit as well? The standard
|
5500 |
|
|
doesn't seem to answer that question.</p>
|
5501 |
|
|
|
5502 |
|
|
<p>On the one hand, nothing in 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> says that
|
5503 |
|
|
<tt>basic_istream<>::sentry</tt> should ever set eofbit. On the
|
5504 |
|
|
other hand, 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> paragraph 4 says that if
|
5505 |
|
|
extraction from a <tt>streambuf</tt> "returns
|
5506 |
|
|
<tt>traits::eof()</tt>, then the input function, except as explicitly
|
5507 |
|
|
noted otherwise, completes its actions and does
|
5508 |
|
|
<tt>setstate(eofbit)"</tt>. So the question comes down to
|
5509 |
|
|
whether <tt>basic_istream<>::sentry</tt>'s constructor is an
|
5510 |
|
|
input function.</p>
|
5511 |
|
|
|
5512 |
|
|
<p>Comments from Jerry Schwarz:</p>
|
5513 |
|
|
<blockquote>
|
5514 |
|
|
<p>It was always my intention that eofbit should be set any time that a
|
5515 |
|
|
virtual returned something to indicate eof, no matter what reason
|
5516 |
|
|
iostream code had for calling the virtual.</p>
|
5517 |
|
|
<p>
|
5518 |
|
|
The motivation for this is that I did not want to require streambufs
|
5519 |
|
|
to behave consistently if their virtuals are called after they have
|
5520 |
|
|
signaled eof.</p>
|
5521 |
|
|
<p>
|
5522 |
|
|
The classic case is a streambuf reading from a UNIX file. EOF isn't
|
5523 |
|
|
really a state for UNIX file descriptors. The convention is that a
|
5524 |
|
|
read on UNIX returns 0 bytes to indicate "EOF", but the file
|
5525 |
|
|
descriptor isn't shut down in any way and future reads do not
|
5526 |
|
|
necessarily also return 0 bytes. In particular, you can read from
|
5527 |
|
|
tty's on UNIX even after they have signaled "EOF". (It
|
5528 |
|
|
isn't always understood that a ^D on UNIX is not an EOF indicator, but
|
5529 |
|
|
an EOL indicator. By typing a "line" consisting solely of
|
5530 |
|
|
^D you cause a read to return 0 bytes, and by convention this is
|
5531 |
|
|
interpreted as end of file.)</p>
|
5532 |
|
|
</blockquote>
|
5533 |
|
|
<p><b>Proposed resolution:</b></p>
|
5534 |
|
|
<p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
|
5535 |
|
|
<blockquote>
|
5536 |
|
|
<p>If <tt>is.rdbuf()->sbumpc()</tt> or <tt>is.rdbuf()->sgetc()</tt>
|
5537 |
|
|
returns <tt>traits::eof()</tt>, the function calls
|
5538 |
|
|
<tt>setstate(failbit | eofbit)</tt> (which may throw
|
5539 |
|
|
<tt>ios_base::failure</tt>).
|
5540 |
|
|
</p>
|
5541 |
|
|
</blockquote>
|
5542 |
|
|
<hr>
|
5543 |
|
|
<a name="198"><h3>198. Validity of pointers and references unspecified after iterator destruction</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 3 Nov 1999</p>
|
5544 |
|
|
<p>
|
5545 |
|
|
Is a pointer or reference obtained from an iterator still valid after
|
5546 |
|
|
destruction of the iterator?
|
5547 |
|
|
</p>
|
5548 |
|
|
<p>
|
5549 |
|
|
Is a pointer or reference obtained from an iterator still valid after the value
|
5550 |
|
|
of the iterator changes?
|
5551 |
|
|
</p>
|
5552 |
|
|
<blockquote>
|
5553 |
|
|
<pre>#include <iostream>
|
5554 |
|
|
#include <vector>
|
5555 |
|
|
#include <iterator>
|
5556 |
|
|
|
5557 |
|
|
int main()
|
5558 |
|
|
{
|
5559 |
|
|
typedef std::vector<int> vec_t;
|
5560 |
|
|
vec_t v;
|
5561 |
|
|
v.push_back( 1 );
|
5562 |
|
|
|
5563 |
|
|
// Is a pointer or reference obtained from an iterator still
|
5564 |
|
|
// valid after destruction of the iterator?
|
5565 |
|
|
int * p = &*v.begin();
|
5566 |
|
|
std::cout << *p << '\n'; // OK?
|
5567 |
|
|
|
5568 |
|
|
// Is a pointer or reference obtained from an iterator still
|
5569 |
|
|
// valid after the value of the iterator changes?
|
5570 |
|
|
vec_t::iterator iter( v.begin() );
|
5571 |
|
|
p = &*iter++;
|
5572 |
|
|
std::cout << *p << '\n'; // OK?
|
5573 |
|
|
|
5574 |
|
|
return 0;
|
5575 |
|
|
}
|
5576 |
|
|
</pre>
|
5577 |
|
|
</blockquote>
|
5578 |
|
|
|
5579 |
|
|
<p>The standard doesn't appear to directly address these
|
5580 |
|
|
questions. The standard needs to be clarified. At least two real-world
|
5581 |
|
|
cases have been reported where library implementors wasted
|
5582 |
|
|
considerable effort because of the lack of clarity in the
|
5583 |
|
|
standard. The question is important because requiring pointers and
|
5584 |
|
|
references to remain valid has the effect for practical purposes of
|
5585 |
|
|
prohibiting iterators from pointing to cached rather than actual
|
5586 |
|
|
elements of containers.</p>
|
5587 |
|
|
|
5588 |
|
|
<p>The standard itself assumes that pointers and references obtained
|
5589 |
|
|
from an iterator are still valid after iterator destruction or
|
5590 |
|
|
change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a>, which returns a reference, defines
|
5591 |
|
|
effects:</p>
|
5592 |
|
|
|
5593 |
|
|
<blockquote>
|
5594 |
|
|
<pre>Iterator tmp = current;
|
5595 |
|
|
return *--tmp;</pre>
|
5596 |
|
|
</blockquote>
|
5597 |
|
|
<p>The definition of reverse_iterator::operator->(), 24.4.1.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opref"> [lib.reverse.iter.opref]</a>, which returns a pointer, defines effects:</p>
|
5598 |
|
|
<blockquote>
|
5599 |
|
|
<pre>return &(operator*());</pre>
|
5600 |
|
|
</blockquote>
|
5601 |
|
|
|
5602 |
|
|
<p>Because the standard itself assumes pointers and references remain
|
5603 |
|
|
valid after iterator destruction or change, the standard should say so
|
5604 |
|
|
explicitly. This will also reduce the chance of user code breaking
|
5605 |
|
|
unexpectedly when porting to a different standard library
|
5606 |
|
|
implementation.</p>
|
5607 |
|
|
<p><b>Proposed resolution:</b></p>
|
5608 |
|
|
<p>Add a new paragraph to 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>:</p>
|
5609 |
|
|
<blockquote>
|
5610 |
|
|
Destruction of an iterator may invalidate pointers and references
|
5611 |
|
|
previously obtained from that iterator.
|
5612 |
|
|
</blockquote>
|
5613 |
|
|
|
5614 |
|
|
<p>Replace paragraph 1 of 24.4.1.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a> with:</p>
|
5615 |
|
|
|
5616 |
|
|
<blockquote>
|
5617 |
|
|
<p><b>Effects:</b></p>
|
5618 |
|
|
<pre> this->tmp = current;
|
5619 |
|
|
--this->tmp;
|
5620 |
|
|
return *this->tmp;
|
5621 |
|
|
</pre>
|
5622 |
|
|
|
5623 |
|
|
<p>
|
5624 |
|
|
[<i>Note:</i> This operation must use an auxiliary member variable,
|
5625 |
|
|
rather than a temporary variable, to avoid returning a reference that
|
5626 |
|
|
persists beyond the lifetime of its associated iterator. (See
|
5627 |
|
|
24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>.) The name of this member variable is shown for
|
5628 |
|
|
exposition only. <i>--end note</i>]
|
5629 |
|
|
</p>
|
5630 |
|
|
</blockquote>
|
5631 |
|
|
|
5632 |
|
|
<p><i>[Post-Tokyo: The issue has been reformulated purely
|
5633 |
|
|
in terms of iterators.]</i></p>
|
5634 |
|
|
|
5635 |
|
|
<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
|
5636 |
|
|
assumption by reverse_iterator. The issue and proposed resolution was
|
5637 |
|
|
reformulated yet again to reflect this reality.]</i></p>
|
5638 |
|
|
|
5639 |
|
|
<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
|
5640 |
|
|
assumes its underlying iterator has persistent pointers and
|
5641 |
|
|
references. Andy Koenig pointed out that it is possible to rewrite
|
5642 |
|
|
reverse_iterator so that it no longer makes such an assupmption.
|
5643 |
|
|
However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>. If we
|
5644 |
|
|
decide it is intentional that <tt>p[n]</tt> may return by value
|
5645 |
|
|
instead of reference when <tt>p</tt> is a Random Access Iterator,
|
5646 |
|
|
other changes in reverse_iterator will be necessary.]</i></p>
|
5647 |
|
|
<p><b>Rationale:</b></p>
|
5648 |
|
|
<p>This issue has been discussed extensively. Note that it is
|
5649 |
|
|
<i>not</i> an issue about the behavior of predefined iterators. It is
|
5650 |
|
|
asking whether or not user-defined iterators are permitted to have
|
5651 |
|
|
transient pointers and references. Several people presented examples
|
5652 |
|
|
of useful user-defined iterators that have such a property; examples
|
5653 |
|
|
include a B-tree iterator, and an "iota iterator" that doesn't point
|
5654 |
|
|
to memory. Library implementors already seem to be able to cope with
|
5655 |
|
|
such iterators: they take pains to avoid forming references to memory
|
5656 |
|
|
that gets iterated past. The only place where this is a problem is
|
5657 |
|
|
<tt>reverse_iterator</tt>, so this issue changes
|
5658 |
|
|
<tt>reverse_iterator</tt> to make it work.</p>
|
5659 |
|
|
|
5660 |
|
|
<p>This resolution does not weaken any guarantees provided by
|
5661 |
|
|
predefined iterators like <tt>list<int>::iterator</tt>.
|
5662 |
|
|
Clause 23 should be reviewed to make sure that guarantees for
|
5663 |
|
|
predefined iterators are as strong as users expect.</p>
|
5664 |
|
|
|
5665 |
|
|
<hr>
|
5666 |
|
|
<a name="199"><h3>199. What does <tt>allocate(0)</tt> return?</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p>
|
5667 |
|
|
<p>
|
5668 |
|
|
Suppose that <tt>A</tt> is a class that conforms to the
|
5669 |
|
|
Allocator requirements of Table 32, and <tt>a</tt> is an
|
5670 |
|
|
object of class <tt>A</tt> What should be the return
|
5671 |
|
|
value of <tt>a.allocate(0)</tt>? Three reasonable
|
5672 |
|
|
possibilities: forbid the argument <tt>0</tt>, return
|
5673 |
|
|
a null pointer, or require that the return value be a
|
5674 |
|
|
unique non-null pointer.
|
5675 |
|
|
</p>
|
5676 |
|
|
<p><b>Proposed resolution:</b></p>
|
5677 |
|
|
<p>
|
5678 |
|
|
Add a note to the <tt>allocate</tt> row of Table 32:
|
5679 |
|
|
"[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
|
5680 |
|
|
<p><b>Rationale:</b></p>
|
5681 |
|
|
<p>A key to understanding this issue is that the ultimate use of
|
5682 |
|
|
allocate() is to construct an iterator, and that iterator for zero
|
5683 |
|
|
length sequences must be the container's past-the-end
|
5684 |
|
|
representation. Since this already implies special case code, it
|
5685 |
|
|
would be over-specification to mandate the return value.
|
5686 |
|
|
</p>
|
5687 |
|
|
<hr>
|
5688 |
|
|
<a name="200"><h3>200. Forward iterator requirements don't allow constant iterators</h3></a><p><b>Section:</b> 24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p>
|
5689 |
|
|
<p>
|
5690 |
|
|
In table 74, the return type of the expression <tt>*a</tt> is given
|
5691 |
|
|
as <tt>T&</tt>, where <tt>T</tt> is the iterator's value type.
|
5692 |
|
|
For constant iterators, however, this is wrong. ("Value type"
|
5693 |
|
|
is never defined very precisely, but it is clear that the value type
|
5694 |
|
|
of, say, <tt>std::list<int>::const_iterator</tt> is supposed to be
|
5695 |
|
|
<tt>int</tt>, not <tt>const int</tt>.)
|
5696 |
|
|
</p>
|
5697 |
|
|
<p><b>Proposed resolution:</b></p>
|
5698 |
|
|
<p>
|
5699 |
|
|
In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
|
5700 |
|
|
return type from "<tt>T&</tt>" to "<tt>T&</tt>
|
5701 |
|
|
if <tt>X</tt> is mutable, otherwise <tt>const T&</tt>".
|
5702 |
|
|
In the <tt>a->m</tt> row, change the return type from
|
5703 |
|
|
"<tt>U&</tt>" to "<tt>U&</tt> if <tt>X</tt> is mutable,
|
5704 |
|
|
otherwise <tt>const U&</tt>".
|
5705 |
|
|
</p>
|
5706 |
|
|
|
5707 |
|
|
<p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
|
5708 |
|
|
there are multiple const problems with the STL portion of the library
|
5709 |
|
|
and that these should be addressed as a single package. Note
|
5710 |
|
|
that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a> has already been declared NAD Future for
|
5711 |
|
|
that very reason.]</i></p>
|
5712 |
|
|
|
5713 |
|
|
<p><i>[Redmond: the LWG thinks this is separable from other constness
|
5714 |
|
|
issues. This issue is just cleanup; it clarifies language that was
|
5715 |
|
|
written before we had iterator_traits. Proposed resolution was
|
5716 |
|
|
modified: the original version only discussed *a. It was pointed out
|
5717 |
|
|
that we also need to worry about *r++ and a->m.]</i></p>
|
5718 |
|
|
|
5719 |
|
|
<hr>
|
5720 |
|
|
<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 13 Jan 2000</p>
|
5721 |
|
|
<p>
|
5722 |
|
|
What should unique() do if you give it a predicate that is not an
|
5723 |
|
|
equivalence relation? There are at least two plausible answers:
|
5724 |
|
|
</p>
|
5725 |
|
|
|
5726 |
|
|
<blockquote>
|
5727 |
|
|
|
5728 |
|
|
<p>
|
5729 |
|
|
1. You can't, because 25.2.8 says that it it "eliminates all but
|
5730 |
|
|
the first element from every consecutive group of equal
|
5731 |
|
|
elements..." and it wouldn't make sense to interpret "equal" as
|
5732 |
|
|
meaning anything but an equivalence relation. [It also doesn't
|
5733 |
|
|
make sense to interpret "equal" as meaning ==, because then there
|
5734 |
|
|
would never be any sense in giving a predicate as an argument at
|
5735 |
|
|
all.]
|
5736 |
|
|
</p>
|
5737 |
|
|
|
5738 |
|
|
<p>
|
5739 |
|
|
2. The word "equal" should be interpreted to mean whatever the
|
5740 |
|
|
predicate says, even if it is not an equivalence relation
|
5741 |
|
|
(and in particular, even if it is not transitive).
|
5742 |
|
|
</p>
|
5743 |
|
|
|
5744 |
|
|
</blockquote>
|
5745 |
|
|
|
5746 |
|
|
<p>
|
5747 |
|
|
The example that raised this question is from Usenet:
|
5748 |
|
|
</p>
|
5749 |
|
|
|
5750 |
|
|
<blockquote>
|
5751 |
|
|
|
5752 |
|
|
<pre>int f[] = { 1, 3, 7, 1, 2 };
|
5753 |
|
|
int* z = unique(f, f+5, greater<int>());</pre>
|
5754 |
|
|
|
5755 |
|
|
</blockquote>
|
5756 |
|
|
|
5757 |
|
|
<p>
|
5758 |
|
|
If one blindly applies the definition using the predicate
|
5759 |
|
|
greater<int>, and ignore the word "equal", you get:
|
5760 |
|
|
</p>
|
5761 |
|
|
|
5762 |
|
|
<blockquote>
|
5763 |
|
|
|
5764 |
|
|
<p>
|
5765 |
|
|
Eliminates all but the first element from every consecutive group
|
5766 |
|
|
of elements referred to by the iterator i in the range [first, last)
|
5767 |
|
|
for which *i > *(i - 1).
|
5768 |
|
|
</p>
|
5769 |
|
|
|
5770 |
|
|
</blockquote>
|
5771 |
|
|
|
5772 |
|
|
<p>
|
5773 |
|
|
The first surprise is the order of the comparison. If we wanted to
|
5774 |
|
|
allow for the predicate not being an equivalence relation, then we
|
5775 |
|
|
should surely compare elements the other way: pred(*(i - 1), *i). If
|
5776 |
|
|
we do that, then the description would seem to say: "Break the
|
5777 |
|
|
sequence into subsequences whose elements are in strictly increasing
|
5778 |
|
|
order, and keep only the first element of each subsequence". So the
|
5779 |
|
|
result would be 1, 1, 2. If we take the description at its word, it
|
5780 |
|
|
would seem to call for strictly DEcreasing order, in which case the
|
5781 |
|
|
result should be 1, 3, 7, 2.<br>
|
5782 |
|
|
<br>
|
5783 |
|
|
In fact, the SGI implementation of unique() does neither: It yields 1,
|
5784 |
|
|
3, 7.
|
5785 |
|
|
</p>
|
5786 |
|
|
<p><b>Proposed resolution:</b></p>
|
5787 |
|
|
<p>Change 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
|
5788 |
|
|
<blockquote>
|
5789 |
|
|
For a nonempty range, eliminates all but the first element from every
|
5790 |
|
|
consecutive group of equivalent elements referred to by the iterator
|
5791 |
|
|
<tt>i</tt> in the range [first+1, last) for which the following
|
5792 |
|
|
conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
|
5793 |
|
|
false</tt>.
|
5794 |
|
|
</blockquote>
|
5795 |
|
|
|
5796 |
|
|
<p>
|
5797 |
|
|
Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
|
5798 |
|
|
comparison function must be an equivalence relation."
|
5799 |
|
|
</p>
|
5800 |
|
|
|
5801 |
|
|
<p><i>[Redmond: discussed arguments for and against requiring the
|
5802 |
|
|
comparison function to be an equivalence relation. Straw poll:
|
5803 |
|
|
14-2-5. First number is to require that it be an equivalence
|
5804 |
|
|
relation, second number is to explicitly not require that it be an
|
5805 |
|
|
equivalence relation, third number is people who believe they need
|
5806 |
|
|
more time to consider the issue. A separate issue: Andy Sawyer
|
5807 |
|
|
pointed out that "i-1" is incorrect, since "i" can refer to the first
|
5808 |
|
|
iterator in the range. Matt provided wording to address this
|
5809 |
|
|
problem.]</i></p>
|
5810 |
|
|
|
5811 |
|
|
<p><i>[Curaçao: The LWG changed "... the range (first,
|
5812 |
|
|
last)..." to "... the range [first+1, last)..." for
|
5813 |
|
|
clarity. They considered this change close enough to editorial to not
|
5814 |
|
|
require another round of review.]</i></p>
|
5815 |
|
|
|
5816 |
|
|
<p><b>Rationale:</b></p>
|
5817 |
|
|
<p>The LWG also considered an alternative resolution: change
|
5818 |
|
|
25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
|
5819 |
|
|
|
5820 |
|
|
<blockquote>
|
5821 |
|
|
For a nonempty range, eliminates all but the first element from every
|
5822 |
|
|
consecutive group of elements referred to by the iterator
|
5823 |
|
|
<tt>i</tt> in the range (first, last) for which the following
|
5824 |
|
|
conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
|
5825 |
|
|
false</tt>.
|
5826 |
|
|
</blockquote>
|
5827 |
|
|
|
5828 |
|
|
<p>
|
5829 |
|
|
Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
|
5830 |
|
|
comparison function need not be an equivalence relation."
|
5831 |
|
|
</p>
|
5832 |
|
|
|
5833 |
|
|
|
5834 |
|
|
<p>Informally: the proposed resolution imposes an explicit requirement
|
5835 |
|
|
that the comparison function be an equivalence relation. The
|
5836 |
|
|
alternative resolution does not, and it gives enough information so
|
5837 |
|
|
that the behavior of unique() for a non-equivalence relation is
|
5838 |
|
|
specified. Both resolutions are consistent with the behavior of
|
5839 |
|
|
existing implementations.</p>
|
5840 |
|
|
<hr>
|
5841 |
|
|
<a name="208"><h3>208. Unnecessary restriction on past-the-end iterators</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 02 Feb 2000</p>
|
5842 |
|
|
<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
|
5843 |
|
|
past-the-end values are always non-singular."</p>
|
5844 |
|
|
<p>This places an unnecessary restriction on past-the-end iterators for
|
5845 |
|
|
containers with forward iterators (for example, a singly-linked list). If the
|
5846 |
|
|
past-the-end value on such a container was a well-known singular value, it would
|
5847 |
|
|
still satisfy all forward iterator requirements.</p>
|
5848 |
|
|
<p>Removing this restriction would allow, for example, a singly-linked list
|
5849 |
|
|
without a "footer" node.</p>
|
5850 |
|
|
<p>This would have an impact on existing code that expects past-the-end
|
5851 |
|
|
iterators obtained from different (generic) containers being not equal.</p>
|
5852 |
|
|
<p><b>Proposed resolution:</b></p>
|
5853 |
|
|
<p>Change 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> paragraph 5, the last sentence, from:</p>
|
5854 |
|
|
<blockquote>
|
5855 |
|
|
<p>Dereferenceable and past-the-end values are always non-singular.</p>
|
5856 |
|
|
</blockquote>
|
5857 |
|
|
<p>to:</p>
|
5858 |
|
|
<blockquote>
|
5859 |
|
|
<p>Dereferenceable values are always non-singular. </p>
|
5860 |
|
|
</blockquote>
|
5861 |
|
|
<p><b>Rationale:</b></p>
|
5862 |
|
|
<p>For some kinds of containers, including singly linked lists and
|
5863 |
|
|
zero-length vectors, null pointers are perfectly reasonable past-the-end
|
5864 |
|
|
iterators. Null pointers are singular.
|
5865 |
|
|
</p>
|
5866 |
|
|
<hr>
|
5867 |
|
|
<a name="209"><h3>209. basic_string declarations inconsistent</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Igor Stauder <b>Date:</b> 11 Feb 2000</p>
|
5868 |
|
|
<p>In Section 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> the basic_string member function
|
5869 |
|
|
declarations use a consistent style except for the following functions:</p>
|
5870 |
|
|
<blockquote>
|
5871 |
|
|
<pre>void push_back(const charT);
|
5872 |
|
|
basic_string& assign(const basic_string&);
|
5873 |
|
|
void swap(basic_string<charT,traits,Allocator>&);</pre>
|
5874 |
|
|
</blockquote>
|
5875 |
|
|
<p>- push_back, assign, swap: missing argument name <br>
|
5876 |
|
|
- push_back: use of const with charT (i.e. POD type passed by value
|
5877 |
|
|
not by reference - should be charT or const charT& )<br>
|
5878 |
|
|
- swap: redundant use of template parameters in argument
|
5879 |
|
|
basic_string<charT,traits,Allocator>&</p>
|
5880 |
|
|
<p><b>Proposed resolution:</b></p>
|
5881 |
|
|
<p>In Section 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> change the basic_string member
|
5882 |
|
|
function declarations push_back, assign, and swap to:</p>
|
5883 |
|
|
<blockquote>
|
5884 |
|
|
<pre>void push_back(charT c);
|
5885 |
|
|
|
5886 |
|
|
basic_string& assign(const basic_string& str);
|
5887 |
|
|
void swap(basic_string& str);</pre>
|
5888 |
|
|
</blockquote>
|
5889 |
|
|
<p><b>Rationale:</b></p>
|
5890 |
|
|
<p>Although the standard is in general not consistent in declaration
|
5891 |
|
|
style, the basic_string declarations are consistent other than the
|
5892 |
|
|
above. The LWG felt that this was sufficient reason to merit the
|
5893 |
|
|
change.
|
5894 |
|
|
</p>
|
5895 |
|
|
<hr>
|
5896 |
|
|
<a name="210"><h3>210. distance first and last confused</h3></a><p><b>Section:</b> 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 15 Feb 2000</p>
|
5897 |
|
|
<p>In paragraph 9 of section 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>, it is written:</p>
|
5898 |
|
|
<blockquote>
|
5899 |
|
|
<p> In the description of the algorithms operators + and - are used
|
5900 |
|
|
for some of the iterator categories for which they do not have to
|
5901 |
|
|
be defined. In these cases the semantics of [...] a-b is the same
|
5902 |
|
|
as of<br>
|
5903 |
|
|
<br>
|
5904 |
|
|
<tt>return distance(a, b);</tt></p>
|
5905 |
|
|
</blockquote>
|
5906 |
|
|
<p><b>Proposed resolution:</b></p>
|
5907 |
|
|
<p>On the last line of paragraph 9 of section 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> change
|
5908 |
|
|
<tt>"a-b"</tt> to <tt>"b-a".</tt></p>
|
5909 |
|
|
<p><b>Rationale:</b></p>
|
5910 |
|
|
<p>There are two ways to fix the defect; change the description to b-a
|
5911 |
|
|
or change the return to distance(b,a). The LWG preferred the
|
5912 |
|
|
former for consistency.</p>
|
5913 |
|
|
<hr>
|
5914 |
|
|
<a name="211"><h3>211. operator>>(istream&, string&) doesn't set failbit</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Scott Snyder <b>Date:</b> 4 Feb 2000</p>
|
5915 |
|
|
<p>The description of the stream extraction operator for std::string (section
|
5916 |
|
|
21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
|
5917 |
|
|
the case that the operator fails to extract any characters from the input
|
5918 |
|
|
stream.</p>
|
5919 |
|
|
<p>This implies that the typical construction</p>
|
5920 |
|
|
<blockquote>
|
5921 |
|
|
<pre>std::istream is;
|
5922 |
|
|
std::string str;
|
5923 |
|
|
...
|
5924 |
|
|
while (is >> str) ... ;</pre>
|
5925 |
|
|
</blockquote>
|
5926 |
|
|
<p>(which tests failbit) is not required to terminate at EOF.</p>
|
5927 |
|
|
<p>Furthermore, this is inconsistent with other extraction operators,
|
5928 |
|
|
which do include this requirement. (See sections 27.6.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a> and 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), where this
|
5929 |
|
|
requirement is present, either explicitly or implicitly, for the
|
5930 |
|
|
extraction operators. It is also present explicitly in the description
|
5931 |
|
|
of getline (istream&, string&, charT) in section 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> paragraph 8.)</p>
|
5932 |
|
|
<p><b>Proposed resolution:</b></p>
|
5933 |
|
|
<p>Insert new paragraph after paragraph 2 in section 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>:</p>
|
5934 |
|
|
<blockquote>
|
5935 |
|
|
|
5936 |
|
|
<p>If the function extracts no characters, it calls
|
5937 |
|
|
is.setstate(ios::failbit) which may throw ios_base::failure
|
5938 |
|
|
(27.4.4.3).</p>
|
5939 |
|
|
</blockquote>
|
5940 |
|
|
<hr>
|
5941 |
|
|
<a name="212"><h3>212. Empty range behavior unclear for several algorithms</h3></a><p><b>Section:</b> 25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 26 Feb 2000</p>
|
5942 |
|
|
<p>The standard doesn't specify what min_element() and max_element() shall
|
5943 |
|
|
return if the range is empty (first equals last). The usual implementations
|
5944 |
|
|
return last. This problem seems also apply to partition(), stable_partition(),
|
5945 |
|
|
next_permutation(), and prev_permutation().</p>
|
5946 |
|
|
<p><b>Proposed resolution:</b></p>
|
5947 |
|
|
<p>In 25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> - Minimum and maximum, paragraphs 7 and
|
5948 |
|
|
9, append: Returns last if first==last.</p>
|
5949 |
|
|
<p><b>Rationale:</b></p>
|
5950 |
|
|
<p>The LWG looked in some detail at all of the above mentioned
|
5951 |
|
|
algorithms, but believes that except for min_element() and
|
5952 |
|
|
max_element() it is already clear that last is returned if first ==
|
5953 |
|
|
last.</p>
|
5954 |
|
|
<hr>
|
5955 |
|
|
<a name="214"><h3>214. set::find() missing const overload</h3></a><p><b>Section:</b> 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a>, 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 28 Feb 2000</p>
|
5956 |
|
|
<p>The specification for the associative container requirements in
|
5957 |
|
|
Table 69 state that the find member function should "return
|
5958 |
|
|
iterator; const_iterator for constant a". The map and multimap
|
5959 |
|
|
container descriptions have two overloaded versions of find, but set
|
5960 |
|
|
and multiset do not, all they have is:</p>
|
5961 |
|
|
<blockquote>
|
5962 |
|
|
<pre>iterator find(const key_type & x) const;</pre>
|
5963 |
|
|
</blockquote>
|
5964 |
|
|
<p><b>Proposed resolution:</b></p>
|
5965 |
|
|
<p>Change the prototypes for find(), lower_bound(), upper_bound(), and
|
5966 |
|
|
equal_range() in section 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a> and section 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a> to each have two overloads:</p>
|
5967 |
|
|
<blockquote>
|
5968 |
|
|
<pre>iterator find(const key_type & x);
|
5969 |
|
|
const_iterator find(const key_type & x) const;</pre>
|
5970 |
|
|
<pre>iterator lower_bound(const key_type & x);
|
5971 |
|
|
const_iterator lower_bound(const key_type & x) const;</pre>
|
5972 |
|
|
<pre>iterator upper_bound(const key_type & x);
|
5973 |
|
|
const_iterator upper_bound(const key_type & x) const;</pre>
|
5974 |
|
|
<pre>pair<iterator, iterator> equal_range(const key_type & x);
|
5975 |
|
|
pair<const_iterator, const_iterator> equal_range(const key_type & x) const;</pre>
|
5976 |
|
|
</blockquote>
|
5977 |
|
|
|
5978 |
|
|
<p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
|
5979 |
|
|
extending the proposed resolution to lower_bound, upper_bound, and
|
5980 |
|
|
equal_range.]</i></p>
|
5981 |
|
|
<hr>
|
5982 |
|
|
<a name="217"><h3>217. Facets example (Classifying Japanese characters) contains errors</h3></a><p><b>Section:</b> 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 29 Feb 2000</p>
|
5983 |
|
|
<p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
|
5984 |
|
|
<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
|
5985 |
|
|
must be const in order for it to be callable on a const object (a reference to
|
5986 |
|
|
which which is what std::use_facet<>() returns).</p>
|
5987 |
|
|
<p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
|
5988 |
|
|
name of the namespace `My'.</p>
|
5989 |
|
|
<p>3) In the definition of `loc' and subsequently in the call to use_facet<>()
|
5990 |
|
|
in main(), the name of the facet is misspelled: it should read `My::JCtype'
|
5991 |
|
|
rather than `My::JCType'.</p>
|
5992 |
|
|
<p><b>Proposed resolution:</b></p>
|
5993 |
|
|
<p>Replace the "Classifying Japanese characters" example in 22.2.8,
|
5994 |
|
|
paragraph 11 with the following:</p>
|
5995 |
|
|
<pre>#include <locale></pre>
|
5996 |
|
|
<pre>namespace My {
|
5997 |
|
|
using namespace std;
|
5998 |
|
|
class JCtype : public locale::facet {
|
5999 |
|
|
public:
|
6000 |
|
|
static locale::id id; // required for use as a new locale facet
|
6001 |
|
|
bool is_kanji (wchar_t c) const;
|
6002 |
|
|
JCtype() {}
|
6003 |
|
|
protected:
|
6004 |
|
|
~JCtype() {}
|
6005 |
|
|
};
|
6006 |
|
|
}</pre>
|
6007 |
|
|
<pre>// file: filt.C
|
6008 |
|
|
#include <iostream>
|
6009 |
|
|
#include <locale>
|
6010 |
|
|
#include "jctype" // above
|
6011 |
|
|
std::locale::id My::JCtype::id; // the static JCtype member
|
6012 |
|
|
declared above.</pre>
|
6013 |
|
|
<pre>int main()
|
6014 |
|
|
{
|
6015 |
|
|
using namespace std;
|
6016 |
|
|
typedef ctype<wchar_t> wctype;
|
6017 |
|
|
locale loc(locale(""), // the user's preferred locale...
|
6018 |
|
|
new My::JCtype); // and a new feature ...
|
6019 |
|
|
wchar_t c = use_facet<wctype>(loc).widen('!');
|
6020 |
|
|
if (!use_facet<My::JCtype>(loc).is_kanji(c))
|
6021 |
|
|
cout << "no it isn't!" << endl;
|
6022 |
|
|
return 0;
|
6023 |
|
|
}</pre>
|
6024 |
|
|
<hr>
|
6025 |
|
|
<a name="220"><h3>220. ~ios_base() usage valid?</h3></a><p><b>Section:</b> 27.4.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 13 Mar 2000</p>
|
6026 |
|
|
<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
|
6027 |
|
|
paragraph 2:</p>
|
6028 |
|
|
<blockquote>
|
6029 |
|
|
<p>Effects: Destroys an object of class ios_base. Calls each registered
|
6030 |
|
|
callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
|
6031 |
|
|
time that any ios_base member function called from within fn has well defined
|
6032 |
|
|
results.</p>
|
6033 |
|
|
</blockquote>
|
6034 |
|
|
<p>But what is not clear is: If no callback functions were ever registered, does
|
6035 |
|
|
it matter whether the ios_base members were ever initialized?</p>
|
6036 |
|
|
<p>For instance, does this program have defined behavior:</p>
|
6037 |
|
|
<blockquote>
|
6038 |
|
|
<pre>#include <ios></pre>
|
6039 |
|
|
<pre>class D : public std::ios_base { };</pre>
|
6040 |
|
|
<pre>int main() { D d; }</pre>
|
6041 |
|
|
</blockquote>
|
6042 |
|
|
<p>It seems that registration of a callback function would surely affect the
|
6043 |
|
|
state of an ios_base. That is, when you register a callback function with an
|
6044 |
|
|
ios_base, the ios_base must record that fact somehow.</p>
|
6045 |
|
|
<p>But if after construction the ios_base is in an indeterminate state, and that
|
6046 |
|
|
state is not made determinate before the destructor is called, then how would
|
6047 |
|
|
the destructor know if any callbacks had indeed been registered? And if the
|
6048 |
|
|
number of callbacks that had been registered is indeterminate, then is not the
|
6049 |
|
|
behavior of the destructor undefined?</p>
|
6050 |
|
|
<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
|
6051 |
|
|
it explicit that destruction before initialization results in undefined
|
6052 |
|
|
behavior.</p>
|
6053 |
|
|
<p><b>Proposed resolution:</b></p>
|
6054 |
|
|
<p>Modify 27.4.2.7 paragraph 1 from</p>
|
6055 |
|
|
<blockquote>
|
6056 |
|
|
<p>Effects: Each ios_base member has an indeterminate value after
|
6057 |
|
|
construction.</p>
|
6058 |
|
|
</blockquote>
|
6059 |
|
|
<p>to</p>
|
6060 |
|
|
<blockquote>
|
6061 |
|
|
<p>Effects: Each ios_base member has an indeterminate
|
6062 |
|
|
value after construction. These members must be initialized by calling
|
6063 |
|
|
basic_ios::init. If an ios_base object is destroyed before these
|
6064 |
|
|
initializations have taken place, the behavior is undefined.</p>
|
6065 |
|
|
</blockquote>
|
6066 |
|
|
<hr>
|
6067 |
|
|
<a name="221"><h3>221. num_get<>::do_get stage 2 processing broken</h3></a><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 14 Mar 2000</p>
|
6068 |
|
|
<p>Stage 2 processing of numeric conversion is broken.</p>
|
6069 |
|
|
|
6070 |
|
|
<p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
|
6071 |
|
|
conversion specifier is %i. A %i specifier determines a number's base
|
6072 |
|
|
by its prefix (0 for octal, 0x for hex), so the intention is clearly
|
6073 |
|
|
that a 0x prefix is allowed. Paragraph 8 in the same section,
|
6074 |
|
|
however, describes very precisely how characters are processed. (It
|
6075 |
|
|
must be done "as if" by a specified code fragment.) That
|
6076 |
|
|
description does not allow a 0x prefix to be recognized.</p>
|
6077 |
|
|
|
6078 |
|
|
<p>Very roughly, stage 2 processing reads a char_type ct. It converts
|
6079 |
|
|
ct to a char, not by using narrow but by looking it up in a
|
6080 |
|
|
translation table that was created by widening the string literal
|
6081 |
|
|
"0123456789abcdefABCDEF+-". The character "x" is
|
6082 |
|
|
not found in that table, so it can't be recognized by stage 2
|
6083 |
|
|
processing.</p>
|
6084 |
|
|
<p><b>Proposed resolution:</b></p>
|
6085 |
|
|
<p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
|
6086 |
|
|
<blockquote>
|
6087 |
|
|
<pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
|
6088 |
|
|
</blockquote>
|
6089 |
|
|
<p>with the line:</p>
|
6090 |
|
|
<blockquote>
|
6091 |
|
|
<pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
|
6092 |
|
|
</blockquote>
|
6093 |
|
|
<p><b>Rationale:</b></p>
|
6094 |
|
|
<p>If we're using the technique of widening a string literal, the
|
6095 |
|
|
string literal must contain every character we wish to recognize.
|
6096 |
|
|
This technique has the consequence that alternate representations
|
6097 |
|
|
of digits will not be recognized. This design decision was made
|
6098 |
|
|
deliberately, with full knowledge of that limitation.</p>
|
6099 |
|
|
<hr>
|
6100 |
|
|
<a name="222"><h3>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3></a><p><b>Section:</b> 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 17 Mar 2000</p>
|
6101 |
|
|
<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
|
6102 |
|
|
<blockquote>
|
6103 |
|
|
<pre>21.3.6.8 - basic_string::compare [lib.string::compare]
|
6104 |
|
|
|
6105 |
|
|
int compare(size_type pos1, size_type n1,
|
6106 |
|
|
const basic_string<charT,traits,Allocator>& str ,
|
6107 |
|
|
size_type pos2 , size_type n2 ) const;
|
6108 |
|
|
|
6109 |
|
|
-4- Returns:
|
6110 |
|
|
|
6111 |
|
|
basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
|
6112 |
|
|
basic_string<charT,traits,Allocator>(str,pos2,n2)) .</pre>
|
6113 |
|
|
</blockquote>
|
6114 |
|
|
<p>and the constructor that's implicitly called by the above is
|
6115 |
|
|
defined to throw an out-of-range exception if pos > str.size(). See
|
6116 |
|
|
section 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> paragraph 4.</p>
|
6117 |
|
|
|
6118 |
|
|
<p>On the other hand, the compare function descriptions themselves don't have
|
6119 |
|
|
"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
|
6120 |
|
|
that do not apply to a function are omitted.</p>
|
6121 |
|
|
<p>So it seems there is an inconsistency in the standard -- are the
|
6122 |
|
|
"Effects" clauses correct, or are the "Throws" clauses
|
6123 |
|
|
missing?</p>
|
6124 |
|
|
<p><b>Proposed resolution:</b></p>
|
6125 |
|
|
<p>In 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> paragraph 3, the footnote 148 attached to
|
6126 |
|
|
the sentence "Descriptions of function semantics contain the
|
6127 |
|
|
following elements (as appropriate):", insert the word
|
6128 |
|
|
"further" so that the foot note reads:</p>
|
6129 |
|
|
<blockquote>
|
6130 |
|
|
<p>To save space, items that do not apply to a function are
|
6131 |
|
|
omitted. For example, if a function does not specify any further
|
6132 |
|
|
preconditions, there will be no "Requires" paragraph.</p>
|
6133 |
|
|
</blockquote>
|
6134 |
|
|
<p><b>Rationale:</b></p>
|
6135 |
|
|
<p>The standard is somewhat inconsistent, but a failure to note a
|
6136 |
|
|
throw condition in a throws clause does not grant permission not to
|
6137 |
|
|
throw. The inconsistent wording is in a footnote, and thus
|
6138 |
|
|
non-normative. The proposed resolution from the LWG clarifies the
|
6139 |
|
|
footnote.</p>
|
6140 |
|
|
<hr>
|
6141 |
|
|
<a name="223"><h3>223. reverse algorithm should use iter_swap rather than swap</h3></a><p><b>Section:</b> 25.2.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 21 Mar 2000</p>
|
6142 |
|
|
<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
|
6143 |
|
|
<p><b>Proposed resolution:</b></p>
|
6144 |
|
|
<p>In 25.2.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>, replace:</p>
|
6145 |
|
|
<blockquote>
|
6146 |
|
|
Effects: For each non-negative integer i <= (last - first)/2,
|
6147 |
|
|
applies swap to all pairs of iterators first + i, (last - i) - 1.
|
6148 |
|
|
</blockquote>
|
6149 |
|
|
<p>with:</p>
|
6150 |
|
|
<blockquote>
|
6151 |
|
|
Effects: For each non-negative integer i <= (last - first)/2,
|
6152 |
|
|
applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
|
6153 |
|
|
</blockquote>
|
6154 |
|
|
<hr>
|
6155 |
|
|
<a name="224"><h3>224. clear() complexity for associative containers refers to undefined N</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 23 Mar 2000</p>
|
6156 |
|
|
<p>In the associative container requirements table in 23.1.2 paragraph 7,
|
6157 |
|
|
a.clear() has complexity "log(size()) + N". However, the meaning of N
|
6158 |
|
|
is not defined.</p>
|
6159 |
|
|
<p><b>Proposed resolution:</b></p>
|
6160 |
|
|
<p>In the associative container requirements table in 23.1.2 paragraph
|
6161 |
|
|
7, the complexity of a.clear(), change "log(size()) + N" to
|
6162 |
|
|
"linear in <tt>size()</tt>".</p>
|
6163 |
|
|
<p><b>Rationale:</b></p>
|
6164 |
|
|
<p>It's the "log(size())", not the "N", that is in
|
6165 |
|
|
error: there's no difference between <i>O(N)</i> and <i>O(N +
|
6166 |
|
|
log(N))</i>. The text in the standard is probably an incorrect
|
6167 |
|
|
cut-and-paste from the range version of <tt>erase</tt>.</p>
|
6168 |
|
|
<hr>
|
6169 |
|
|
<a name="225"><h3>225. std:: algorithms use of other unqualified algorithms</h3></a><p><b>Section:</b> 17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Apr 2000</p>
|
6170 |
|
|
<p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
|
6171 |
|
|
user namespaces might be found through Koenig lookup?</p>
|
6172 |
|
|
<p>For example, a popular standard library implementation includes this
|
6173 |
|
|
implementation of std::unique:</p>
|
6174 |
|
|
<blockquote>
|
6175 |
|
|
<pre>namespace std {
|
6176 |
|
|
template <class _ForwardIter>
|
6177 |
|
|
_ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
|
6178 |
|
|
__first = adjacent_find(__first, __last);
|
6179 |
|
|
return unique_copy(__first, __last, __first);
|
6180 |
|
|
}
|
6181 |
|
|
}</pre>
|
6182 |
|
|
</blockquote>
|
6183 |
|
|
<p>Imagine two users on opposite sides of town, each using unique on his own
|
6184 |
|
|
sequences bounded by my_iterators . User1 looks at his standard library
|
6185 |
|
|
implementation and says, "I know how to implement a more efficient
|
6186 |
|
|
unique_copy for my_iterators", and writes:</p>
|
6187 |
|
|
<blockquote>
|
6188 |
|
|
<pre>namespace user1 {
|
6189 |
|
|
class my_iterator;
|
6190 |
|
|
// faster version for my_iterator
|
6191 |
|
|
my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
|
6192 |
|
|
}</pre>
|
6193 |
|
|
</blockquote>
|
6194 |
|
|
<p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
|
6195 |
|
|
<p>User2 has other needs, and writes:</p>
|
6196 |
|
|
<blockquote>
|
6197 |
|
|
<pre>namespace user2 {
|
6198 |
|
|
class my_iterator;
|
6199 |
|
|
// Returns true iff *c is a unique copy of *a and *b.
|
6200 |
|
|
bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
|
6201 |
|
|
}</pre>
|
6202 |
|
|
</blockquote>
|
6203 |
|
|
<p>User2 is shocked to find later that his fully-qualified use of
|
6204 |
|
|
std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
|
6205 |
|
|
compile (if he's lucky). Looking in the standard, he sees the following Effects
|
6206 |
|
|
clause for unique():</p>
|
6207 |
|
|
<blockquote>
|
6208 |
|
|
<p>Effects: Eliminates all but the first element from every consecutive group
|
6209 |
|
|
of equal elements referred to by the iterator i in the range [first, last) for
|
6210 |
|
|
which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
|
6211 |
|
|
*(i - 1)) != false</p>
|
6212 |
|
|
</blockquote>
|
6213 |
|
|
<p>The standard gives user2 absolutely no reason to think he can interfere with
|
6214 |
|
|
std::unique by defining names in namespace user2. His standard library has been
|
6215 |
|
|
built with the template export feature, so he is unable to inspect the
|
6216 |
|
|
implementation. User1 eventually compiles his code with another compiler, and
|
6217 |
|
|
his version of unique_copy silently stops being called. Eventually, he realizes
|
6218 |
|
|
that he was depending on an implementation detail of his library and had no
|
6219 |
|
|
right to expect his unique_copy() to be called portably.</p>
|
6220 |
|
|
<p>On the face of it, and given above scenario, it may seem obvious that the
|
6221 |
|
|
implementation of unique() shown is non-conforming because it uses unique_copy()
|
6222 |
|
|
rather than ::std::unique_copy(). Most standard library implementations,
|
6223 |
|
|
however, seem to disagree with this notion.</p>
|
6224 |
|
|
<p> <i>[Tokyo: Steve Adamczyk from
|
6225 |
|
|
the core working group indicates that "std::" is sufficient;
|
6226 |
|
|
leading "::" qualification is not required because any namespace
|
6227 |
|
|
qualification is sufficient to suppress Koenig lookup.]</i></p>
|
6228 |
|
|
<p><b>Proposed resolution:</b></p>
|
6229 |
|
|
<p>Add a paragraph and a note at the end of
|
6230 |
|
|
17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>:</p>
|
6231 |
|
|
<blockquote>
|
6232 |
|
|
|
6233 |
|
|
<p>Unless otherwise specified, no global or non-member function in the
|
6234 |
|
|
standard library shall use a function from another namespace which is
|
6235 |
|
|
found through <i>argument-dependent name lookup</i> (3.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.lookup.koenig"> [basic.lookup.koenig]</a>).</p>
|
6236 |
|
|
|
6237 |
|
|
<p>[Note: the phrase "unless otherwise specified" is intended to
|
6238 |
|
|
allow Koenig lookup in cases like that of ostream_iterators:<br>
|
6239 |
|
|
|
6240 |
|
|
<br>
|
6241 |
|
|
Effects:</p>
|
6242 |
|
|
<blockquote>
|
6243 |
|
|
<p>*out_stream << value;<br>
|
6244 |
|
|
if(delim != 0) *out_stream << delim;<br>
|
6245 |
|
|
return (*this);</p>
|
6246 |
|
|
<p>--end note]</p>
|
6247 |
|
|
</blockquote>
|
6248 |
|
|
</blockquote>
|
6249 |
|
|
|
6250 |
|
|
<p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
|
6251 |
|
|
is as yet unsure if the proposed resolution is the best
|
6252 |
|
|
solution. Furthermore, the LWG believes that the same problem of
|
6253 |
|
|
unqualified library names applies to wording in the standard itself,
|
6254 |
|
|
and has opened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> accordingly. Any resolution of
|
6255 |
|
|
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be coordinated with the resolution of
|
6256 |
|
|
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
|
6257 |
|
|
|
6258 |
|
|
<p><i>[Toronto: The LWG is not sure if this is a defect in the
|
6259 |
|
|
standard. Most LWG members believe that an implementation of
|
6260 |
|
|
<tt>std::unique</tt> like the one quoted in this issue is already
|
6261 |
|
|
illegal, since, under certain circumstances, its semantics are not
|
6262 |
|
|
those specified in the standard. The standard's description of
|
6263 |
|
|
<tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
|
6264 |
|
|
should have any effect.]</i></p>
|
6265 |
|
|
|
6266 |
|
|
<p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
|
6267 |
|
|
225, 226, and 229. Their conclusion was that the issues should be
|
6268 |
|
|
separated into an LWG portion (Howard's paper, N1387=02-0045), and a
|
6269 |
|
|
EWG portion (Dave will write a proposal). The LWG and EWG had
|
6270 |
|
|
(separate) discussions of this plan the next day. The proposed
|
6271 |
|
|
resolution for this issue is in accordance with Howard's paper.]</i></p>
|
6272 |
|
|
|
6273 |
|
|
<p><b>Rationale:</b></p>
|
6274 |
|
|
<p>It could be argued that this proposed isn't strictly necessary,
|
6275 |
|
|
that the Standard doesn't grant implementors license to write a
|
6276 |
|
|
standard function that behaves differently than specified in the
|
6277 |
|
|
Standard just because of an unrelated user-defined name in some
|
6278 |
|
|
other namespace. However, this is at worst a clarification. It is
|
6279 |
|
|
surely right that algorithsm shouldn't pick up random names, that
|
6280 |
|
|
user-defined names should have no effect unless otherwise specified.
|
6281 |
|
|
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> deals with the question of when it is
|
6282 |
|
|
appropriate for the standard to explicitly specify otherwise.</p>
|
6283 |
|
|
<hr>
|
6284 |
|
|
<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Apr 2000</p>
|
6285 |
|
|
<p>The issues are: </p>
|
6286 |
|
|
<p>1. How can a 3rd party library implementor (lib1) write a version of a standard
|
6287 |
|
|
algorithm which is specialized to work with his own class template? </p>
|
6288 |
|
|
<p>2. How can another library implementor (lib2) write a generic algorithm which
|
6289 |
|
|
will take advantage of the specialized algorithm in lib1?</p>
|
6290 |
|
|
<p>This appears to be the only viable answer under current language rules:</p>
|
6291 |
|
|
<blockquote>
|
6292 |
|
|
<pre>namespace lib1
|
6293 |
|
|
{
|
6294 |
|
|
// arbitrary-precision numbers using T as a basic unit
|
6295 |
|
|
template <class T>
|
6296 |
|
|
class big_num { //...
|
6297 |
|
|
};
|
6298 |
|
|
</pre>
|
6299 |
|
|
<pre> // defining this in namespace std is illegal (it would be an
|
6300 |
|
|
// overload), so we hope users will rely on Koenig lookup
|
6301 |
|
|
template <class T>
|
6302 |
|
|
void swap(big_int<T>&, big_int<T>&);
|
6303 |
|
|
}</pre>
|
6304 |
|
|
<pre>#include <algorithm>
|
6305 |
|
|
namespace lib2
|
6306 |
|
|
{
|
6307 |
|
|
template <class T>
|
6308 |
|
|
void generic_sort(T* start, T* end)
|
6309 |
|
|
{
|
6310 |
|
|
...
|
6311 |
|
|
// using-declaration required so we can work on built-in types
|
6312 |
|
|
using std::swap;
|
6313 |
|
|
// use Koenig lookup to find specialized algorithm if available
|
6314 |
|
|
swap(*x, *y);
|
6315 |
|
|
}
|
6316 |
|
|
}</pre>
|
6317 |
|
|
</blockquote>
|
6318 |
|
|
<p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
|
6319 |
|
|
and somewhat slippery. The implementor needs to remember to write the
|
6320 |
|
|
using-declaration, or generic_sort will fail to compile when T is a built-in
|
6321 |
|
|
type. The second drawback is that the use of this style in lib2 effectively
|
6322 |
|
|
"reserves" names in any namespace which defines types which may
|
6323 |
|
|
eventually be used with lib2. This may seem innocuous at first when applied to
|
6324 |
|
|
names like swap, but consider more ambiguous names like unique_copy() instead.
|
6325 |
|
|
It is easy to imagine the user wanting to define these names differently in his
|
6326 |
|
|
own namespace. A definition with semantics incompatible with the standard
|
6327 |
|
|
library could cause serious problems (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>).</p>
|
6328 |
|
|
<p>Why, you may ask, can't we just partially specialize std::swap()? It's
|
6329 |
|
|
because the language doesn't allow for partial specialization of function
|
6330 |
|
|
templates. If you write:</p>
|
6331 |
|
|
<blockquote>
|
6332 |
|
|
<pre>namespace std
|
6333 |
|
|
{
|
6334 |
|
|
template <class T>
|
6335 |
|
|
void swap(lib1::big_int<T>&, lib1::big_int<T>&);
|
6336 |
|
|
}</pre>
|
6337 |
|
|
</blockquote>
|
6338 |
|
|
<p>You have just overloaded std::swap, which is illegal under the current
|
6339 |
|
|
language rules. On the other hand, the following full specialization is legal:</p>
|
6340 |
|
|
<blockquote>
|
6341 |
|
|
<pre>namespace std
|
6342 |
|
|
{
|
6343 |
|
|
template <>
|
6344 |
|
|
void swap(lib1::other_type&, lib1::other_type&);
|
6345 |
|
|
}</pre>
|
6346 |
|
|
</blockquote>
|
6347 |
|
|
|
6348 |
|
|
<p>This issue reflects concerns raised by the "Namespace issue
|
6349 |
|
|
with specialized swap" thread on comp.lang.c++.moderated. A
|
6350 |
|
|
similar set of concerns was earlier raised on the boost.org mailing
|
6351 |
|
|
list and the ACCU-general mailing list. Also see library reflector
|
6352 |
|
|
message c++std-lib-7354.</p>
|
6353 |
|
|
|
6354 |
|
|
<p>
|
6355 |
|
|
J. C. van Winkel points out (in c++std-lib-9565) another unexpected
|
6356 |
|
|
fact: it's impossible to output a container of std::pair's using copy
|
6357 |
|
|
and an ostream_iterator, as long as both pair-members are built-in or
|
6358 |
|
|
std:: types. That's because a user-defined operator<< for (for
|
6359 |
|
|
example) std::pair<const std::string, int> will not be found:
|
6360 |
|
|
lookup for operator<< will be performed only in namespace std.
|
6361 |
|
|
Opinions differed on whether or not this was a defect, and, if so,
|
6362 |
|
|
whether the defect is that something is wrong with user-defined
|
6363 |
|
|
functionality and std, or whether it's that the standard library does
|
6364 |
|
|
not provide an operator<< for std::pair<>.
|
6365 |
|
|
</p>
|
6366 |
|
|
|
6367 |
|
|
<p><b>Proposed resolution:</b></p>
|
6368 |
|
|
|
6369 |
|
|
<p>Adopt the wording proposed in Howard Hinnant's paper
|
6370 |
|
|
N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
|
6371 |
|
|
|
6372 |
|
|
|
6373 |
|
|
<p><i>[Tokyo: Summary, "There is no conforming way to extend
|
6374 |
|
|
std::swap for user defined templates." The LWG agrees that
|
6375 |
|
|
there is a problem. Would like more information before
|
6376 |
|
|
proceeding. This may be a core issue. Core issue 229 has been opened
|
6377 |
|
|
to discuss the core aspects of this problem. It was also noted that
|
6378 |
|
|
submissions regarding this issue have been received from several
|
6379 |
|
|
sources, but too late to be integrated into the issues list.
|
6380 |
|
|
]</i></p>
|
6381 |
|
|
|
6382 |
|
|
<p><i>[Post-Tokyo: A paper with several proposed resolutions,
|
6383 |
|
|
J16/00-0029==WG21/N1252, "Shades of namespace std functions
|
6384 |
|
|
" by Alan Griffiths, is in the Post-Tokyo mailing. It
|
6385 |
|
|
should be considered a part of this issue.]</i></p>
|
6386 |
|
|
|
6387 |
|
|
<p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
|
6388 |
|
|
resolution that involves core changes: it would add partial
|
6389 |
|
|
specialization of function template. The Core Working Group is
|
6390 |
|
|
reluctant to add partial specialization of function templates. It is
|
6391 |
|
|
viewed as a large change, CWG believes that proposal presented leaves
|
6392 |
|
|
some syntactic issues unanswered; if the CWG does add partial
|
6393 |
|
|
specialization of function templates, it wishes to develop its own
|
6394 |
|
|
proposal. The LWG continues to believe that there is a serious
|
6395 |
|
|
problem: there is no good way for users to force the library to use
|
6396 |
|
|
user specializations of generic standard library functions, and in
|
6397 |
|
|
certain cases (e.g. transcendental functions called by
|
6398 |
|
|
<tt>valarray</tt> and <tt>complex</tt>) this is important. Koenig
|
6399 |
|
|
lookup isn't adequate, since names within the library must be
|
6400 |
|
|
qualified with <tt>std</tt> (see issue 225), specialization doesn't
|
6401 |
|
|
work (we don't have partial specialization of function templates), and
|
6402 |
|
|
users aren't permitted to add overloads within namespace std.
|
6403 |
|
|
]</i></p>
|
6404 |
|
|
|
6405 |
|
|
<p><i>[Copenhagen: Discussed at length, with no consensus. Relevant
|
6406 |
|
|
papers in the pre-Copenhagen mailing: N1289, N1295, N1296. Discussion
|
6407 |
|
|
focused on four options. (1) Relax restrictions on overloads within
|
6408 |
|
|
namespace std. (2) Mandate that the standard library use unqualified
|
6409 |
|
|
calls for <tt>swap</tt> and possibly other functions. (3) Introduce
|
6410 |
|
|
helper class templates for <tt>swap</tt> and possibly other functions.
|
6411 |
|
|
(4) Introduce partial specialization of function templates. Every
|
6412 |
|
|
option had both support and opposition. Straw poll (first number is
|
6413 |
|
|
support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
|
6414 |
|
|
(4) 4, 4.]</i></p>
|
6415 |
|
|
|
6416 |
|
|
<p><i>[Redmond: Discussed, again no consensus. Herb presented an
|
6417 |
|
|
argument that a user who is defining a type <tt>T</tt> with an
|
6418 |
|
|
associated <tt>swap</tt> should not be expected to put that
|
6419 |
|
|
<tt>swap</tt> in namespace std, either by overloading or by partial
|
6420 |
|
|
specialization. The argument is that <tt>swap</tt> is part of
|
6421 |
|
|
<tt>T</tt>'s interface, and thus should to in the same namespace as
|
6422 |
|
|
<tt>T</tt> and only in that namespace. If we accept this argument,
|
6423 |
|
|
the consequence is that standard library functions should use
|
6424 |
|
|
unqualified call of <tt>swap</tt>. (And which other functions? Any?)
|
6425 |
|
|
A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
|
6426 |
|
|
try to put together a proposal before the next meeting.]</i></p>
|
6427 |
|
|
|
6428 |
|
|
<p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
|
6429 |
|
|
225, 226, and 229. Their conclusion was that the issues should be
|
6430 |
|
|
separated into an LWG portion (Howard's paper, N1387=02-0045), and a
|
6431 |
|
|
EWG portion (Dave will write a proposal). The LWG and EWG had
|
6432 |
|
|
(separate) discussions of this plan the next day. The proposed
|
6433 |
|
|
resolution is the one proposed by Howard.]</i></p>
|
6434 |
|
|
|
6435 |
|
|
<p><i>[Santa Cruz: the LWG agreed with the general direction of
|
6436 |
|
|
Howard's paper, N1387. (Roughly: Koenig lookup is disabled unless
|
6437 |
|
|
we say otherwise; this issue is about when we do say otherwise.)
|
6438 |
|
|
However, there were concerns about wording. Howard will provide new
|
6439 |
|
|
wording. Bill and Jeremy will review it.]</i></p>
|
6440 |
|
|
|
6441 |
|
|
<p><i>[Kona: Howard proposed the new wording. The LWG accepted his
|
6442 |
|
|
proposed resolution.]</i></p>
|
6443 |
|
|
|
6444 |
|
|
<p><b>Rationale:</b></p>
|
6445 |
|
|
<p>Informally: introduce a Swappable concept, and specify that the
|
6446 |
|
|
value types of the iterators passed to certain standard algorithms
|
6447 |
|
|
(such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
|
6448 |
|
|
to that concept. The Swappable concept will make it clear that
|
6449 |
|
|
these algorithms use unqualified lookup for the calls
|
6450 |
|
|
to <tt>swap</tt>. Also, in 26.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.transcend"> [lib.valarray.transcend]</a> paragraph 1,
|
6451 |
|
|
state that the valarray transcendentals use unqualified lookup.</p>
|
6452 |
|
|
<hr>
|
6453 |
|
|
<a name="227"><h3>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p><b>Section:</b> 25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 09 Apr 2000</p>
|
6454 |
|
|
<p>25.2.2 reads:</p>
|
6455 |
|
|
<blockquote>
|
6456 |
|
|
<p><tt> template<class T> void swap(T& a, T& b);</tt><br>
|
6457 |
|
|
<br>
|
6458 |
|
|
Requires: Type T is Assignable (_lib.container.requirements_).<br>
|
6459 |
|
|
Effects: Exchanges values stored in two locations.</p>
|
6460 |
|
|
</blockquote>
|
6461 |
|
|
<p>The only reasonable** generic implementation of swap requires construction of a
|
6462 |
|
|
new temporary copy of one of its arguments:</p>
|
6463 |
|
|
<blockquote>
|
6464 |
|
|
<pre>template<class T> void swap(T& a, T& b);
|
6465 |
|
|
{
|
6466 |
|
|
T tmp(a);
|
6467 |
|
|
a = b;
|
6468 |
|
|
b = tmp;
|
6469 |
|
|
}</pre>
|
6470 |
|
|
</blockquote>
|
6471 |
|
|
<p>But a type which is only Assignable cannot be swapped by this implementation.</p>
|
6472 |
|
|
<p>**Yes, there's also an unreasonable implementation which would require T to be
|
6473 |
|
|
DefaultConstructible instead of CopyConstructible. I don't think this is worthy
|
6474 |
|
|
of consideration:</p>
|
6475 |
|
|
<blockquote>
|
6476 |
|
|
<pre>template<class T> void swap(T& a, T& b);
|
6477 |
|
|
{
|
6478 |
|
|
T tmp;
|
6479 |
|
|
tmp = a;
|
6480 |
|
|
a = b;
|
6481 |
|
|
b = tmp;
|
6482 |
|
|
}</pre>
|
6483 |
|
|
</blockquote>
|
6484 |
|
|
<p><b>Proposed resolution:</b></p>
|
6485 |
|
|
<p>Change 25.2.2 paragraph 1 from:</p>
|
6486 |
|
|
<blockquote>
|
6487 |
|
|
<p> Requires: Type T is Assignable (23.1).</p>
|
6488 |
|
|
</blockquote>
|
6489 |
|
|
<p>to:</p>
|
6490 |
|
|
<blockquote>
|
6491 |
|
|
<p> Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
|
6492 |
|
|
</blockquote>
|
6493 |
|
|
<hr>
|
6494 |
|
|
<a name="228"><h3>228. Incorrect specification of "..._byname" facets</h3></a><p><b>Section:</b> 22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Apr 2000</p>
|
6495 |
|
|
<p>The sections 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>, 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a>,
|
6496 |
|
|
22.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, 22.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>, 22.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.collate.byname"> [lib.locale.collate.byname]</a>, 22.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.byname"> [lib.locale.time.put.byname]</a>, 22.2.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a>, and 22.2.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.messages.byname"> [lib.locale.messages.byname]</a> overspecify the
|
6497 |
|
|
definitions of the "..._byname" classes by listing a bunch
|
6498 |
|
|
of virtual functions. At the same time, no semantics of these
|
6499 |
|
|
functions are defined. Real implementations do not define these
|
6500 |
|
|
functions because the functional part of the facets is actually
|
6501 |
|
|
implemented in the corresponding base classes and the constructor of
|
6502 |
|
|
the "..._byname" version just provides suitable date used by
|
6503 |
|
|
these implementations. For example, the 'numpunct' methods just return
|
6504 |
|
|
values from a struct. The base class uses a statically initialized
|
6505 |
|
|
struct while the derived version reads the contents of this struct
|
6506 |
|
|
from a table. However, no virtual function is defined in
|
6507 |
|
|
'numpunct_byname'.</p>
|
6508 |
|
|
|
6509 |
|
|
<p>For most classes this does not impose a problem but specifically
|
6510 |
|
|
for 'ctype' it does: The specialization for 'ctype_byname<char>'
|
6511 |
|
|
is required because otherwise the semantics would change due to the
|
6512 |
|
|
virtual functions defined in the general version for 'ctype_byname':
|
6513 |
|
|
In 'ctype<char>' the method 'do_is()' is not virtual but it is
|
6514 |
|
|
made virtual in both 'ctype<cT>' and 'ctype_byname<cT>'.
|
6515 |
|
|
Thus, a class derived from 'ctype_byname<char>' can tell whether
|
6516 |
|
|
this class is specialized or not under the current specification:
|
6517 |
|
|
Without the specialization, 'do_is()' is virtual while with
|
6518 |
|
|
specialization it is not virtual.</p>
|
6519 |
|
|
<p><b>Proposed resolution:</b></p>
|
6520 |
|
|
<p> Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
|
6521 |
|
|
<pre> namespace std {
|
6522 |
|
|
template <class charT>
|
6523 |
|
|
class ctype_byname : public ctype<charT> {
|
6524 |
|
|
public:
|
6525 |
|
|
typedef ctype<charT>::mask mask;
|
6526 |
|
|
explicit ctype_byname(const char*, size_t refs = 0);
|
6527 |
|
|
protected:
|
6528 |
|
|
~ctype_byname(); // virtual
|
6529 |
|
|
};
|
6530 |
|
|
}</pre>
|
6531 |
|
|
<p> Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
|
6532 |
|
|
<pre> namespace std {
|
6533 |
|
|
template <class internT, class externT, class stateT>
|
6534 |
|
|
class codecvt_byname : public codecvt<internT, externT, stateT> {
|
6535 |
|
|
public:
|
6536 |
|
|
explicit codecvt_byname(const char*, size_t refs = 0);
|
6537 |
|
|
protected:
|
6538 |
|
|
~codecvt_byname(); // virtual
|
6539 |
|
|
};
|
6540 |
|
|
}
|
6541 |
|
|
</pre>
|
6542 |
|
|
<p> Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
|
6543 |
|
|
<pre> namespace std {
|
6544 |
|
|
template <class charT>
|
6545 |
|
|
class numpunct_byname : public numpunct<charT> {
|
6546 |
|
|
// this class is specialized for char and wchar_t.
|
6547 |
|
|
public:
|
6548 |
|
|
typedef charT char_type;
|
6549 |
|
|
typedef basic_string<charT> string_type;
|
6550 |
|
|
explicit numpunct_byname(const char*, size_t refs = 0);
|
6551 |
|
|
protected:
|
6552 |
|
|
~numpunct_byname(); // virtual
|
6553 |
|
|
};
|
6554 |
|
|
}</pre>
|
6555 |
|
|
<p> Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
|
6556 |
|
|
<pre> namespace std {
|
6557 |
|
|
template <class charT>
|
6558 |
|
|
class collate_byname : public collate<charT> {
|
6559 |
|
|
public:
|
6560 |
|
|
typedef basic_string<charT> string_type;
|
6561 |
|
|
explicit collate_byname(const char*, size_t refs = 0);
|
6562 |
|
|
protected:
|
6563 |
|
|
~collate_byname(); // virtual
|
6564 |
|
|
};
|
6565 |
|
|
}</pre>
|
6566 |
|
|
<p> Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
|
6567 |
|
|
<pre> namespace std {
|
6568 |
|
|
template <class charT, class InputIterator = istreambuf_iterator<charT> >
|
6569 |
|
|
class time_get_byname : public time_get<charT, InputIterator> {
|
6570 |
|
|
public:
|
6571 |
|
|
typedef time_base::dateorder dateorder;
|
6572 |
|
|
typedef InputIterator iter_type</pre>
|
6573 |
|
|
<pre> explicit time_get_byname(const char*, size_t refs = 0);
|
6574 |
|
|
protected:
|
6575 |
|
|
~time_get_byname(); // virtual
|
6576 |
|
|
};
|
6577 |
|
|
}</pre>
|
6578 |
|
|
<p> Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
|
6579 |
|
|
<pre> namespace std {
|
6580 |
|
|
template <class charT, class OutputIterator = ostreambuf_iterator<charT> >
|
6581 |
|
|
class time_put_byname : public time_put<charT, OutputIterator>
|
6582 |
|
|
{
|
6583 |
|
|
public:
|
6584 |
|
|
typedef charT char_type;
|
6585 |
|
|
typedef OutputIterator iter_type;</pre>
|
6586 |
|
|
<pre> explicit time_put_byname(const char*, size_t refs = 0);
|
6587 |
|
|
protected:
|
6588 |
|
|
~time_put_byname(); // virtual
|
6589 |
|
|
};
|
6590 |
|
|
}"</pre>
|
6591 |
|
|
<p> Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
|
6592 |
|
|
<pre> namespace std {
|
6593 |
|
|
template <class charT, bool Intl = false>
|
6594 |
|
|
class moneypunct_byname : public moneypunct<charT, Intl> {
|
6595 |
|
|
public:
|
6596 |
|
|
typedef money_base::pattern pattern;
|
6597 |
|
|
typedef basic_string<charT> string_type;</pre>
|
6598 |
|
|
<pre> explicit moneypunct_byname(const char*, size_t refs = 0);
|
6599 |
|
|
protected:
|
6600 |
|
|
~moneypunct_byname(); // virtual
|
6601 |
|
|
};
|
6602 |
|
|
}</pre>
|
6603 |
|
|
<p> Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
|
6604 |
|
|
<pre> namespace std {
|
6605 |
|
|
template <class charT>
|
6606 |
|
|
class messages_byname : public messages<charT> {
|
6607 |
|
|
public:
|
6608 |
|
|
typedef messages_base::catalog catalog;
|
6609 |
|
|
typedef basic_string<charT> string_type;</pre>
|
6610 |
|
|
<pre> explicit messages_byname(const char*, size_t refs = 0);
|
6611 |
|
|
protected:
|
6612 |
|
|
~messages_byname(); // virtual
|
6613 |
|
|
};
|
6614 |
|
|
}</pre>
|
6615 |
|
|
<p>Remove section 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> completely (because in
|
6616 |
|
|
this case only those members are defined to be virtual which are
|
6617 |
|
|
defined to be virtual in 'ctype<cT>'.)</p>
|
6618 |
|
|
|
6619 |
|
|
<p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
|
6620 |
|
|
the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>.]</i></p>
|
6621 |
|
|
|
6622 |
|
|
<p><i>[Copenhagen: proposed resolution was revised slightly, to remove
|
6623 |
|
|
three last virtual functions from <tt>messages_byname</tt>.]</i></p>
|
6624 |
|
|
|
6625 |
|
|
<hr>
|
6626 |
|
|
<a name="229"><h3>229. Unqualified references of other library entities</h3></a><p><b>Section:</b> 17.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.contents"> [lib.contents]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 19 Apr 2000</p>
|
6627 |
|
|
<p>Throughout the library chapters, the descriptions of library entities refer
|
6628 |
|
|
to other library entities without necessarily qualifying the names.</p>
|
6629 |
|
|
|
6630 |
|
|
<p>For example, section 25.2.2 "Swap" describes the effect of
|
6631 |
|
|
swap_ranges in terms of the unqualified name "swap". This section
|
6632 |
|
|
could reasonably be interpreted to mean that the library must be implemented so
|
6633 |
|
|
as to do a lookup of the unqualified name "swap", allowing users to
|
6634 |
|
|
override any ::std::swap function when Koenig lookup applies.</p>
|
6635 |
|
|
|
6636 |
|
|
<p>Although it would have been best to use explicit qualification with
|
6637 |
|
|
"::std::" throughout, too many lines in the standard would have to be
|
6638 |
|
|
adjusted to make that change in a Technical Corrigendum.</p>
|
6639 |
|
|
|
6640 |
|
|
<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
|
6641 |
|
|
<tt>size_t</tt>, is a special case of this.
|
6642 |
|
|
</p>
|
6643 |
|
|
<p><b>Proposed resolution:</b></p>
|
6644 |
|
|
<p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
|
6645 |
|
|
<blockquote>
|
6646 |
|
|
<p>Whenever a name x defined in the standard library is mentioned, the name x
|
6647 |
|
|
is assumed to be fully qualified as ::std::x, unless explicitly described
|
6648 |
|
|
otherwise. For example, if the Effects section for library function F is
|
6649 |
|
|
described as calling library function G, the function ::std::G is meant.</p>
|
6650 |
|
|
</blockquote>
|
6651 |
|
|
|
6652 |
|
|
<p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
|
6653 |
|
|
the LWG to solve a problem in the standard itself similar to the
|
6654 |
|
|
problem within implementations of library identified by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>. Any resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be
|
6655 |
|
|
coordinated with the resolution of this issue.]</i></p>
|
6656 |
|
|
|
6657 |
|
|
<p><i>[post-Toronto: Howard is undecided about whether it is
|
6658 |
|
|
appropriate for all standard library function names referred to in
|
6659 |
|
|
other standard library functions to be explicitly qualified by
|
6660 |
|
|
<tt>std</tt>: it is common advice that users should define global
|
6661 |
|
|
functions that operate on their class in the same namespace as the
|
6662 |
|
|
class, and this requires argument-dependent lookup if those functions
|
6663 |
|
|
are intended to be called by library code. Several LWG members are
|
6664 |
|
|
concerned that valarray appears to require argument-dependent lookup,
|
6665 |
|
|
but that the wording may not be clear enough to fall under
|
6666 |
|
|
"unless explicitly described otherwise".]</i></p>
|
6667 |
|
|
|
6668 |
|
|
<p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
|
6669 |
|
|
225, 226, and 229. Their conclusion was that the issues should be
|
6670 |
|
|
separated into an LWG portion (Howard's paper, N1387=02-0045), and a
|
6671 |
|
|
EWG portion (Dave will write a proposal). The LWG and EWG had
|
6672 |
|
|
(separate) discussions of this plan the next day. This paper resolves
|
6673 |
|
|
issues 225 and 226. In light of that resolution, the proposed
|
6674 |
|
|
resolution for the current issue makes sense.]</i></p>
|
6675 |
|
|
|
6676 |
|
|
<hr>
|
6677 |
|
|
<a name="230"><h3>230. Assignable specified without also specifying CopyConstructible</h3></a><p><b>Section:</b> 17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 26 Apr 2000</p>
|
6678 |
|
|
<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> identified an instance (std::swap) where
|
6679 |
|
|
Assignable was specified without also specifying
|
6680 |
|
|
CopyConstructible. The LWG asked that the standard be searched to
|
6681 |
|
|
determine if the same defect existed elsewhere.</p>
|
6682 |
|
|
|
6683 |
|
|
<p>There are a number of places (see proposed resolution below) where
|
6684 |
|
|
Assignable is specified without also specifying
|
6685 |
|
|
CopyConstructible. There are also several cases where both are
|
6686 |
|
|
specified. For example, 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
|
6687 |
|
|
<p><b>Proposed resolution:</b></p>
|
6688 |
|
|
<p>In 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> table 65 for value_type:
|
6689 |
|
|
change "T is Assignable" to "T is CopyConstructible and
|
6690 |
|
|
Assignable"
|
6691 |
|
|
</p>
|
6692 |
|
|
|
6693 |
|
|
<p>In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> table 69 X::key_type; change
|
6694 |
|
|
"Key is Assignable" to "Key is
|
6695 |
|
|
CopyConstructible and Assignable"<br>
|
6696 |
|
|
</p>
|
6697 |
|
|
|
6698 |
|
|
<p>In 24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> paragraph 1, change:
|
6699 |
|
|
</p>
|
6700 |
|
|
<blockquote>
|
6701 |
|
|
<p> A class or a built-in type X satisfies the requirements of an
|
6702 |
|
|
output iterator if X is an Assignable type (23.1) and also the
|
6703 |
|
|
following expressions are valid, as shown in Table 73:
|
6704 |
|
|
</p>
|
6705 |
|
|
</blockquote>
|
6706 |
|
|
<p>to:
|
6707 |
|
|
</p>
|
6708 |
|
|
<blockquote>
|
6709 |
|
|
<p> A class or a built-in type X satisfies the requirements of an
|
6710 |
|
|
output iterator if X is a CopyConstructible (20.1.3) and Assignable
|
6711 |
|
|
type (23.1) and also the following expressions are valid, as shown in
|
6712 |
|
|
Table 73:
|
6713 |
|
|
</p>
|
6714 |
|
|
</blockquote>
|
6715 |
|
|
|
6716 |
|
|
<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
|
6717 |
|
|
the LWG. He asks that the 25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> and 25.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a> changes be studied carefully, as it is not clear that
|
6718 |
|
|
CopyConstructible is really a requirement and may be
|
6719 |
|
|
overspecification.]</i></p>
|
6720 |
|
|
|
6721 |
|
|
<p><i>[Portions of the resolution for issue 230 have been superceded by
|
6722 |
|
|
the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
|
6723 |
|
|
|
6724 |
|
|
<p><b>Rationale:</b></p>
|
6725 |
|
|
<p>The original proposed resolution also included changes to input
|
6726 |
|
|
iterator, fill, and replace. The LWG believes that those changes are
|
6727 |
|
|
not necessary. The LWG considered some blanket statement, where an
|
6728 |
|
|
Assignable type was also required to be Copy Constructible, but
|
6729 |
|
|
decided against this because fill and replace really don't require the
|
6730 |
|
|
Copy Constructible property.</p>
|
6731 |
|
|
<hr>
|
6732 |
|
|
<a name="231"><h3>231. Precision in iostream?</h3></a><p><b>Section:</b> 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 25 Apr 2000</p>
|
6733 |
|
|
<p>What is the following program supposed to output?</p>
|
6734 |
|
|
<pre>#include <iostream>
|
6735 |
|
|
|
6736 |
|
|
int
|
6737 |
|
|
main()
|
6738 |
|
|
{
|
6739 |
|
|
std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
|
6740 |
|
|
std::cout.precision( 0 ) ;
|
6741 |
|
|
std::cout << 1.00 << '\n' ;
|
6742 |
|
|
return 0 ;
|
6743 |
|
|
}</pre>
|
6744 |
|
|
<p>From my C experience, I would expect "1e+00"; this is what
|
6745 |
|
|
<tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
|
6746 |
|
|
"1.000000e+00".</p>
|
6747 |
|
|
|
6748 |
|
|
<p>The only indication I can find in the standard is 22.2.2.2.2/11,
|
6749 |
|
|
where it says "For conversion from a floating-point type, if
|
6750 |
|
|
(flags & fixed) != 0 or if str.precision() > 0, then
|
6751 |
|
|
str.precision() is specified in the conversion specification."
|
6752 |
|
|
This is an obvious error, however, fixed is not a mask for a field,
|
6753 |
|
|
but a value that a multi-bit field may take -- the results of and'ing
|
6754 |
|
|
fmtflags with ios::fixed are not defined, at least not if
|
6755 |
|
|
ios::scientific has been set. G++'s behavior corresponds to what might
|
6756 |
|
|
happen if you do use (flags & fixed) != 0 with a typical
|
6757 |
|
|
implementation (floatfield == 3 << something, fixed == 1
|
6758 |
|
|
<< something, and scientific == 2 << something).</p>
|
6759 |
|
|
|
6760 |
|
|
<p>Presumably, the intent is either (flags & floatfield) != 0, or
|
6761 |
|
|
(flags & floatfield) == fixed; the first gives something more or
|
6762 |
|
|
less like the effect of precision in a printf floating point
|
6763 |
|
|
conversion. Only more or less, of course. In order to implement printf
|
6764 |
|
|
formatting correctly, you must know whether the precision was
|
6765 |
|
|
explicitly set or not. Say by initializing it to -1, instead of 6, and
|
6766 |
|
|
stating that for floating point conversions, if precision < -1, 6
|
6767 |
|
|
will be used, for fixed point, if precision < -1, 1 will be used,
|
6768 |
|
|
etc. Plus, of course, if precision == 0 and flags & floatfield ==
|
6769 |
|
|
0, 1 should be = used. But it probably isn't necessary to emulate all
|
6770 |
|
|
of the anomalies of printf:-).</p>
|
6771 |
|
|
<p><b>Proposed resolution:</b></p>
|
6772 |
|
|
<p>
|
6773 |
|
|
Replace 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 11, with the following
|
6774 |
|
|
sentence:
|
6775 |
|
|
</p>
|
6776 |
|
|
<blockquote>
|
6777 |
|
|
For conversion from a floating-point type,
|
6778 |
|
|
<tt><i>str</i>.precision()</tt> is specified in the conversion
|
6779 |
|
|
specification.
|
6780 |
|
|
</blockquote>
|
6781 |
|
|
<p><b>Rationale:</b></p>
|
6782 |
|
|
<p>The floatfield determines whether numbers are formatted as if
|
6783 |
|
|
with %f, %e, or %g. If the <tt>fixed</tt> bit is set, it's %f,
|
6784 |
|
|
if <tt>scientific</tt> it's %e, and if both bits are set, or
|
6785 |
|
|
neither, it's %g.</p>
|
6786 |
|
|
<p>Turning to the C standard, a precision of 0 is meaningful
|
6787 |
|
|
for %f and %e. For %g, precision 0 is taken to be the same as
|
6788 |
|
|
precision 1.</p>
|
6789 |
|
|
<p>The proposed resolution has the effect that if neither
|
6790 |
|
|
<tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
|
6791 |
|
|
specifying a precision of 0, which will be internally
|
6792 |
|
|
turned into 1. There's no need to call it out as a special
|
6793 |
|
|
case.</p>
|
6794 |
|
|
<p>The output of the above program will be "1e+00".</p>
|
6795 |
|
|
|
6796 |
|
|
<p><i>[Post-Curaçao: Howard provided improved wording covering the case
|
6797 |
|
|
where precision is 0 and mode is %g.]</i></p>
|
6798 |
|
|
|
6799 |
|
|
<hr>
|
6800 |
|
|
<a name="232"><h3>232. "depends" poorly defined in 17.4.3.1</h3></a><p><b>Section:</b> 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 18 Apr 2000</p>
|
6801 |
|
|
<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
|
6802 |
|
|
specializations of standard templates to those that "depend on a
|
6803 |
|
|
user-defined name of external linkage."</p>
|
6804 |
|
|
<p>This term, however, is not adequately defined, making it possible to
|
6805 |
|
|
construct a specialization that is, I believe, technically legal according to
|
6806 |
|
|
17.4.3.1/1, but that specializes a standard template for a built-in type such as
|
6807 |
|
|
'int'.</p>
|
6808 |
|
|
<p>The following code demonstrates the problem:</p>
|
6809 |
|
|
<blockquote>
|
6810 |
|
|
<pre>#include <algorithm></pre>
|
6811 |
|
|
<pre>template<class T> struct X
|
6812 |
|
|
{
|
6813 |
|
|
typedef T type;
|
6814 |
|
|
};</pre>
|
6815 |
|
|
<pre>namespace std
|
6816 |
|
|
{
|
6817 |
|
|
template<> void swap(::X<int>::type& i, ::X<int>::type& j);
|
6818 |
|
|
}</pre>
|
6819 |
|
|
</blockquote>
|
6820 |
|
|
<p><b>Proposed resolution:</b></p>
|
6821 |
|
|
<p>Change "user-defined name" to "user-defined
|
6822 |
|
|
type".</p>
|
6823 |
|
|
<p><b>Rationale:</b></p>
|
6824 |
|
|
<p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
|
6825 |
|
|
Programming Language</i>. It disallows the example in the issue,
|
6826 |
|
|
since the underlying type itself is not user-defined. The only
|
6827 |
|
|
possible problem I can see is for non-type templates, but there's no
|
6828 |
|
|
possible way for a user to come up with a specialization for bitset,
|
6829 |
|
|
for example, that might not have already been specialized by the
|
6830 |
|
|
implementor?</p>
|
6831 |
|
|
|
6832 |
|
|
<p><i>[Toronto: this may be related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>.]</i></p>
|
6833 |
|
|
|
6834 |
|
|
<p><i>[post-Toronto: Judy provided the above proposed resolution and
|
6835 |
|
|
rationale.]</i></p>
|
6836 |
|
|
<hr>
|
6837 |
|
|
<a name="234"><h3>234. Typos in allocator definition</h3></a><p><b>Section:</b> 20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
|
6838 |
|
|
<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
|
6839 |
|
|
<tt>destruct()</tt> are described as returns but the functions actually
|
6840 |
|
|
return <tt>void</tt>.</p>
|
6841 |
|
|
<p><b>Proposed resolution:</b></p>
|
6842 |
|
|
<p>Substitute "Returns" by "Effect".</p>
|
6843 |
|
|
<hr>
|
6844 |
|
|
<a name="235"><h3>235. No specification of default ctor for reverse_iterator</h3></a><p><b>Section:</b> 24.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
|
6845 |
|
|
<p>The declaration of <tt>reverse_iterator</tt> lists a default
|
6846 |
|
|
constructor. However, no specification is given what this constructor
|
6847 |
|
|
should do.</p>
|
6848 |
|
|
<p><b>Proposed resolution:</b></p>
|
6849 |
|
|
<p>In section 24.4.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.cons"> [lib.reverse.iter.cons]</a> add the following
|
6850 |
|
|
paragraph:</p>
|
6851 |
|
|
<blockquote>
|
6852 |
|
|
<p><tt>reverse_iterator()</tt></p>
|
6853 |
|
|
|
6854 |
|
|
<p>Default initializes <tt>current</tt>. Iterator operations
|
6855 |
|
|
applied to the resulting iterator have defined behavior if and
|
6856 |
|
|
only if the corresponding operations are defined on a default
|
6857 |
|
|
constructed iterator of type <tt>Iterator</tt>.</p>
|
6858 |
|
|
</blockquote>
|
6859 |
|
|
<p><i>[pre-Copenhagen: Dietmar provide wording for proposed
|
6860 |
|
|
resolution.]</i></p>
|
6861 |
|
|
<hr>
|
6862 |
|
|
<a name="237"><h3>237. Undefined expression in complexity specification</h3></a><p><b>Section:</b> 23.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
|
6863 |
|
|
<p>The complexity specification in paragraph 6 says that the complexity
|
6864 |
|
|
is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
|
6865 |
|
|
defined on iterators this term is in general undefined because it
|
6866 |
|
|
would have to be <tt>last - first</tt>.</p>
|
6867 |
|
|
<p><b>Proposed resolution:</b></p>
|
6868 |
|
|
<p>Change paragraph 6 from</p>
|
6869 |
|
|
<blockquote>Linear in <i>first - last</i>.</blockquote>
|
6870 |
|
|
<p>to become</p>
|
6871 |
|
|
<blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
|
6872 |
|
|
<hr>
|
6873 |
|
|
<a name="238"><h3>238. Contradictory results of stringbuf initialization.</h3></a><p><b>Section:</b> 27.7.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.cons"> [lib.stringbuf.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 11 May 2000</p>
|
6874 |
|
|
<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
|
6875 |
|
|
'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
|
6876 |
|
|
that far but consider this code:</p>
|
6877 |
|
|
|
6878 |
|
|
<pre> std::basic_stringbuf<char> sbuf("hello, world", std::ios_base::openmode(0));
|
6879 |
|
|
std::cout << "'" << sbuf.str() << "'\n";
|
6880 |
|
|
</pre>
|
6881 |
|
|
|
6882 |
|
|
<p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
|
6883 |
|
|
the output sequence nor the input sequence is initialized and
|
6884 |
|
|
paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
|
6885 |
|
|
returns the input or the output sequence. None of them is initialized,
|
6886 |
|
|
ie. both are empty, in which case the return from <tt>str()</tt> is
|
6887 |
|
|
defined to be <tt>basic_string<cT>()</tt>.</p>
|
6888 |
|
|
|
6889 |
|
|
<p>However, probably only test cases in some testsuites will detect this
|
6890 |
|
|
"problem"...</p>
|
6891 |
|
|
<p><b>Proposed resolution:</b></p>
|
6892 |
|
|
<p>Remove 27.7.1.1 paragraph 4.</p>
|
6893 |
|
|
<p><b>Rationale:</b></p>
|
6894 |
|
|
<p>We could fix 27.7.1.1 paragraph 4, but there would be no point. If
|
6895 |
|
|
we fixed it, it would say just the same thing as text that's already
|
6896 |
|
|
in the standard.</p>
|
6897 |
|
|
<hr>
|
6898 |
|
|
<a name="239"><h3>239. Complexity of unique() and/or unique_copy incorrect</h3></a><p><b>Section:</b> 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
|
6899 |
|
|
<p>The complexity of unique and unique_copy are inconsistent with each
|
6900 |
|
|
other and inconsistent with the implementations. The standard
|
6901 |
|
|
specifies:</p>
|
6902 |
|
|
|
6903 |
|
|
<p>for unique():</p>
|
6904 |
|
|
|
6905 |
|
|
<blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
|
6906 |
|
|
(last - first) - 1 applications of the corresponding predicate, otherwise
|
6907 |
|
|
no applications of the predicate.</blockquote>
|
6908 |
|
|
|
6909 |
|
|
<p>for unique_copy():</p>
|
6910 |
|
|
|
6911 |
|
|
<blockquote>-7- Complexity: Exactly last - first applications of the corresponding
|
6912 |
|
|
predicate.</blockquote>
|
6913 |
|
|
|
6914 |
|
|
<p>
|
6915 |
|
|
The implementations do it the other way round: unique() applies the
|
6916 |
|
|
predicate last-first times and unique_copy() applies it last-first-1
|
6917 |
|
|
times.</p>
|
6918 |
|
|
|
6919 |
|
|
<p>As both algorithms use the predicate for pair-wise comparison of
|
6920 |
|
|
sequence elements I don't see a justification for unique_copy()
|
6921 |
|
|
applying the predicate last-first times, especially since it is not
|
6922 |
|
|
specified to which pair in the sequence the predicate is applied
|
6923 |
|
|
twice.</p>
|
6924 |
|
|
<p><b>Proposed resolution:</b></p>
|
6925 |
|
|
<p>Change both complexity sections in 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> to:</p>
|
6926 |
|
|
|
6927 |
|
|
<blockquote>Complexity: For nonempty ranges, exactly last - first - 1
|
6928 |
|
|
applications of the corresponding predicate.</blockquote>
|
6929 |
|
|
|
6930 |
|
|
<hr>
|
6931 |
|
|
<a name="240"><h3>240. Complexity of adjacent_find() is meaningless</h3></a><p><b>Section:</b> 25.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
|
6932 |
|
|
<p>The complexity section of adjacent_find is defective:</p>
|
6933 |
|
|
|
6934 |
|
|
<blockquote>
|
6935 |
|
|
<pre>template <class ForwardIterator>
|
6936 |
|
|
ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
|
6937 |
|
|
BinaryPredicate pred);
|
6938 |
|
|
</pre>
|
6939 |
|
|
|
6940 |
|
|
<p>-1- Returns: The first iterator i such that both i and i + 1 are in
|
6941 |
|
|
the range [first, last) for which the following corresponding
|
6942 |
|
|
conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
|
6943 |
|
|
last if no such iterator is found.</p>
|
6944 |
|
|
|
6945 |
|
|
<p>-2- Complexity: Exactly find(first, last, value) - first applications
|
6946 |
|
|
of the corresponding predicate.
|
6947 |
|
|
</p>
|
6948 |
|
|
</blockquote>
|
6949 |
|
|
|
6950 |
|
|
<p>In the Complexity section, it is not defined what "value"
|
6951 |
|
|
is supposed to mean. My best guess is that "value" means an
|
6952 |
|
|
object for which one of the conditions pred(*i,value) or
|
6953 |
|
|
pred(value,*i) is true, where i is the iterator defined in the Returns
|
6954 |
|
|
section. However, the value type of the input sequence need not be
|
6955 |
|
|
equality-comparable and for this reason the term find(first, last,
|
6956 |
|
|
value) - first is meaningless.</p>
|
6957 |
|
|
|
6958 |
|
|
<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
|
6959 |
|
|
find_if(first, last, bind1st(pred,*i)) - first might come closer to
|
6960 |
|
|
the intended specification. Binders can only be applied to function
|
6961 |
|
|
objects that have the function call operator declared const, which is
|
6962 |
|
|
not required of predicates because they can have non-const data
|
6963 |
|
|
members. For this reason, a specification using a binder could only be
|
6964 |
|
|
an "as-if" specification.</p>
|
6965 |
|
|
<p><b>Proposed resolution:</b></p>
|
6966 |
|
|
<p>Change the complexity section in 25.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> to:</p>
|
6967 |
|
|
<blockquote>
|
6968 |
|
|
For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
|
6969 |
|
|
(<i>last</i> - <i>first</i>) - 1)</tt> applications of the
|
6970 |
|
|
corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
|
6971 |
|
|
return value.
|
6972 |
|
|
</blockquote>
|
6973 |
|
|
|
6974 |
|
|
<p><i>[Copenhagen: the original resolution specified an upper
|
6975 |
|
|
bound. The LWG preferred an exact count.]</i></p>
|
6976 |
|
|
|
6977 |
|
|
<hr>
|
6978 |
|
|
<a name="241"><h3>241. Does unique_copy() require CopyConstructible and Assignable?</h3></a><p><b>Section:</b> 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
|
6979 |
|
|
|
6980 |
|
|
<p>Some popular implementations of unique_copy() create temporary
|
6981 |
|
|
copies of values in the input sequence, at least if the input iterator
|
6982 |
|
|
is a pointer. Such an implementation is built on the assumption that
|
6983 |
|
|
the value type is CopyConstructible and Assignable.</p>
|
6984 |
|
|
|
6985 |
|
|
<p>It is common practice in the standard that algorithms explicitly
|
6986 |
|
|
specify any additional requirements that they impose on any of the
|
6987 |
|
|
types used by the algorithm. An example of an algorithm that creates
|
6988 |
|
|
temporary copies and correctly specifies the additional requirements
|
6989 |
|
|
is accumulate(), 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.accumulate"> [lib.accumulate]</a>.</p>
|
6990 |
|
|
|
6991 |
|
|
<p>Since the specifications of unique() and unique_copy() do not
|
6992 |
|
|
require CopyConstructible and Assignable of the InputIterator's value
|
6993 |
|
|
type the above mentioned implementations are not standard-compliant. I
|
6994 |
|
|
cannot judge whether this is a defect in the standard or a defect in
|
6995 |
|
|
the implementations.</p>
|
6996 |
|
|
<p><b>Proposed resolution:</b></p>
|
6997 |
|
|
<p>In 25.2.8 change:</p>
|
6998 |
|
|
|
6999 |
|
|
<blockquote>
|
7000 |
|
|
-4- Requires: The ranges [first, last) and [result, result+(last-first))
|
7001 |
|
|
shall not overlap.
|
7002 |
|
|
</blockquote>
|
7003 |
|
|
|
7004 |
|
|
<p>to:</p>
|
7005 |
|
|
|
7006 |
|
|
<blockquote>
|
7007 |
|
|
<p>-4- Requires: The ranges [first, last) and [result,
|
7008 |
|
|
result+(last-first)) shall not overlap. The expression *result =
|
7009 |
|
|
*first must be valid. If neither InputIterator nor OutputIterator
|
7010 |
|
|
meets the requirements of forward iterator then the value type of
|
7011 |
|
|
InputIterator must be copy constructible. Otherwise copy
|
7012 |
|
|
constructible is not required. </p>
|
7013 |
|
|
</blockquote>
|
7014 |
|
|
|
7015 |
|
|
<p><i>[Redmond: the original proposed resolution didn't impose an
|
7016 |
|
|
explicit requirement that the iterator's value type must be copy
|
7017 |
|
|
constructible, on the grounds that an input iterator's value type must
|
7018 |
|
|
always be copy constructible. Not everyone in the LWG thought that
|
7019 |
|
|
this requirement was clear from table 72. It has been suggested that
|
7020 |
|
|
it might be possible to implement <tt>unique_copy</tt> without
|
7021 |
|
|
requiring assignability, although current implementations do impose
|
7022 |
|
|
that requirement. Howard provided new wording.]</i></p>
|
7023 |
|
|
|
7024 |
|
|
<p><i>[
|
7025 |
|
|
Curaçao: The LWG changed the PR editorially to specify
|
7026 |
|
|
"neither...nor...meet..." as clearer than
|
7027 |
|
|
"both...and...do not meet...". Change believed to be so
|
7028 |
|
|
minor as not to require re-review.
|
7029 |
|
|
]</i></p>
|
7030 |
|
|
|
7031 |
|
|
<hr>
|
7032 |
|
|
<a name="242"><h3>242. Side effects of function objects</h3></a><p><b>Section:</b> 25.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> May 15 2000</p>
|
7033 |
|
|
<p>The algorithms transform(), accumulate(), inner_product(),
|
7034 |
|
|
partial_sum(), and adjacent_difference() require that the function
|
7035 |
|
|
object supplied to them shall not have any side effects.</p>
|
7036 |
|
|
|
7037 |
|
|
<p>The standard defines a side effect in 1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.execution"> [intro.execution]</a> as:</p>
|
7038 |
|
|
<blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
|
7039 |
|
|
modifying an object, calling a library I/O function, or calling a function
|
7040 |
|
|
that does any of those operations are all side effects, which are changes
|
7041 |
|
|
in the state of the execution environment.</blockquote>
|
7042 |
|
|
|
7043 |
|
|
<p>As a consequence, the function call operator of a function object supplied
|
7044 |
|
|
to any of the algorithms listed above cannot modify data members, cannot
|
7045 |
|
|
invoke any function that has a side effect, and cannot even create and
|
7046 |
|
|
modify temporary objects. It is difficult to imagine a function object
|
7047 |
|
|
that is still useful under these severe limitations. For instance, any
|
7048 |
|
|
non-trivial transformator supplied to transform() might involve creation
|
7049 |
|
|
and modification of temporaries, which is prohibited according to the current
|
7050 |
|
|
wording of the standard.</p>
|
7051 |
|
|
|
7052 |
|
|
<p>On the other hand, popular implementations of these algorithms exhibit
|
7053 |
|
|
uniform and predictable behavior when invoked with a side-effect-producing
|
7054 |
|
|
function objects. It looks like the strong requirement is not needed for
|
7055 |
|
|
efficient implementation of these algorithms.</p>
|
7056 |
|
|
|
7057 |
|
|
<p>The requirement of side-effect-free function objects could be
|
7058 |
|
|
replaced by a more relaxed basic requirement (which would hold for all
|
7059 |
|
|
function objects supplied to any algorithm in the standard library):</p>
|
7060 |
|
|
<blockquote>A function objects supplied to an algorithm shall not invalidate
|
7061 |
|
|
any iterator or sequence that is used by the algorithm. Invalidation of
|
7062 |
|
|
the sequence includes destruction of the sorting order if the algorithm
|
7063 |
|
|
relies on the sorting order (see section 25.3 - Sorting and related operations
|
7064 |
|
|
[lib.alg.sorting]).</blockquote>
|
7065 |
|
|
|
7066 |
|
|
<p>I can't judge whether it is intended that the function objects supplied
|
7067 |
|
|
to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
|
7068 |
|
|
shall not modify sequence elements through dereferenced iterators.</p>
|
7069 |
|
|
|
7070 |
|
|
<p>It is debatable whether this issue is a defect or a change request.
|
7071 |
|
|
Since the consequences for user-supplied function objects are drastic and
|
7072 |
|
|
limit the usefulness of the algorithms significantly I would consider it
|
7073 |
|
|
a defect.</p>
|
7074 |
|
|
<p><b>Proposed resolution:</b></p>
|
7075 |
|
|
|
7076 |
|
|
<p><i>Things to notice about these changes:</i></p>
|
7077 |
|
|
|
7078 |
|
|
<ol>
|
7079 |
|
|
<li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
|
7080 |
|
|
are intentional. we want to prevent side-effects from
|
7081 |
|
|
invalidating the end iterators.</i>
|
7082 |
|
|
</li>
|
7083 |
|
|
|
7084 |
|
|
<li> <i>That has the unintentional side-effect of prohibiting
|
7085 |
|
|
modification of the end element as a side-effect. This could
|
7086 |
|
|
conceivably be significant in some cases.</i>
|
7087 |
|
|
</li>
|
7088 |
|
|
|
7089 |
|
|
<li> <i>The wording also prevents side-effects from modifying elements
|
7090 |
|
|
of the output sequence. I can't imagine why anyone would want
|
7091 |
|
|
to do this, but it is arguably a restriction that implementors
|
7092 |
|
|
don't need to place on users.</i>
|
7093 |
|
|
</li>
|
7094 |
|
|
|
7095 |
|
|
<li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
|
7096 |
|
|
and simple, but would require more verbiage.</i>
|
7097 |
|
|
</li>
|
7098 |
|
|
</ol>
|
7099 |
|
|
|
7100 |
|
|
<p>Change 25.2.3/2 from:</p>
|
7101 |
|
|
|
7102 |
|
|
<blockquote>
|
7103 |
|
|
-2- Requires: op and binary_op shall not have any side effects.
|
7104 |
|
|
</blockquote>
|
7105 |
|
|
|
7106 |
|
|
<p>to:</p>
|
7107 |
|
|
|
7108 |
|
|
<blockquote>
|
7109 |
|
|
-2- Requires: in the ranges [first1, last1], [first2, first2 +
|
7110 |
|
|
(last1 - first1)] and [result, result + (last1- first1)], op and
|
7111 |
|
|
binary_op shall neither modify elements nor invalidate iterators or
|
7112 |
|
|
subranges.
|
7113 |
|
|
[Footnote: The use of fully closed ranges is intentional --end footnote]
|
7114 |
|
|
</blockquote>
|
7115 |
|
|
|
7116 |
|
|
|
7117 |
|
|
<p>Change 25.2.3/2 from:</p>
|
7118 |
|
|
|
7119 |
|
|
<blockquote>
|
7120 |
|
|
-2- Requires: op and binary_op shall not have any side effects.
|
7121 |
|
|
</blockquote>
|
7122 |
|
|
|
7123 |
|
|
<p>to:</p>
|
7124 |
|
|
|
7125 |
|
|
<blockquote>
|
7126 |
|
|
-2- Requires: op and binary_op shall not invalidate iterators or
|
7127 |
|
|
subranges, or modify elements in the ranges [first1, last1],
|
7128 |
|
|
[first2, first2 + (last1 - first1)], and [result, result + (last1
|
7129 |
|
|
- first1)].
|
7130 |
|
|
[Footnote: The use of fully closed ranges is intentional --end footnote]
|
7131 |
|
|
</blockquote>
|
7132 |
|
|
|
7133 |
|
|
|
7134 |
|
|
<p>Change 26.4.1/2 from:</p>
|
7135 |
|
|
|
7136 |
|
|
<blockquote>
|
7137 |
|
|
-2- Requires: T must meet the requirements of CopyConstructible
|
7138 |
|
|
(lib.copyconstructible) and Assignable (lib.container.requirements)
|
7139 |
|
|
types. binary_op shall not cause side effects.
|
7140 |
|
|
</blockquote>
|
7141 |
|
|
|
7142 |
|
|
<p>to:</p>
|
7143 |
|
|
|
7144 |
|
|
<blockquote>
|
7145 |
|
|
-2- Requires: T must meet the requirements of CopyConstructible
|
7146 |
|
|
(lib.copyconstructible) and Assignable
|
7147 |
|
|
(lib.container.requirements) types. In the range [first, last],
|
7148 |
|
|
binary_op shall neither modify elements nor invalidate iterators
|
7149 |
|
|
or subranges.
|
7150 |
|
|
[Footnote: The use of a fully closed range is intentional --end footnote]
|
7151 |
|
|
</blockquote>
|
7152 |
|
|
|
7153 |
|
|
<p>Change 26.4.2/2 from:</p>
|
7154 |
|
|
|
7155 |
|
|
<blockquote>
|
7156 |
|
|
-2- Requires: T must meet the requirements of CopyConstructible
|
7157 |
|
|
(lib.copyconstructible) and Assignable (lib.container.requirements)
|
7158 |
|
|
types. binary_op1 and binary_op2 shall not cause side effects.
|
7159 |
|
|
</blockquote>
|
7160 |
|
|
|
7161 |
|
|
<p>to:</p>
|
7162 |
|
|
|
7163 |
|
|
<blockquote>
|
7164 |
|
|
-2- Requires: T must meet the requirements of CopyConstructible
|
7165 |
|
|
(lib.copyconstructible) and Assignable (lib.container.requirements)
|
7166 |
|
|
types. In the ranges [first, last] and [first2, first2 + (last -
|
7167 |
|
|
first)], binary_op1 and binary_op2 shall neither modify elements
|
7168 |
|
|
nor invalidate iterators or subranges.
|
7169 |
|
|
[Footnote: The use of fully closed ranges is intentional --end footnote]
|
7170 |
|
|
</blockquote>
|
7171 |
|
|
|
7172 |
|
|
|
7173 |
|
|
<p>Change 26.4.3/4 from:</p>
|
7174 |
|
|
|
7175 |
|
|
<blockquote>
|
7176 |
|
|
-4- Requires: binary_op is expected not to have any side effects.
|
7177 |
|
|
</blockquote>
|
7178 |
|
|
|
7179 |
|
|
<p>to:</p>
|
7180 |
|
|
|
7181 |
|
|
<blockquote>
|
7182 |
|
|
-4- Requires: In the ranges [first, last] and [result, result +
|
7183 |
|
|
(last - first)], binary_op shall neither modify elements nor
|
7184 |
|
|
invalidate iterators or subranges.
|
7185 |
|
|
[Footnote: The use of fully closed ranges is intentional --end footnote]
|
7186 |
|
|
</blockquote>
|
7187 |
|
|
|
7188 |
|
|
<p>Change 26.4.4/2 from:</p>
|
7189 |
|
|
|
7190 |
|
|
<blockquote>
|
7191 |
|
|
-2- Requires: binary_op shall not have any side effects.
|
7192 |
|
|
</blockquote>
|
7193 |
|
|
|
7194 |
|
|
<p>to:</p>
|
7195 |
|
|
|
7196 |
|
|
<blockquote>
|
7197 |
|
|
-2- Requires: In the ranges [first, last] and [result, result +
|
7198 |
|
|
(last - first)], binary_op shall neither modify elements nor
|
7199 |
|
|
invalidate iterators or subranges.
|
7200 |
|
|
[Footnote: The use of fully closed ranges is intentional --end footnote]
|
7201 |
|
|
</blockquote>
|
7202 |
|
|
|
7203 |
|
|
<p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
|
7204 |
|
|
|
7205 |
|
|
<p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
|
7206 |
|
|
added footnotes pointing out that the use of closed ranges was
|
7207 |
|
|
intentional.]</i></p>
|
7208 |
|
|
|
7209 |
|
|
<hr>
|
7210 |
|
|
<a name="243"><h3>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> May 15 2000</p>
|
7211 |
|
|
<p>basic_istream<>::get(), and basic_istream<>::getline(),
|
7212 |
|
|
are unclear with respect to the behavior and side-effects of the named
|
7213 |
|
|
functions in case of an error.</p>
|
7214 |
|
|
|
7215 |
|
|
<p>27.6.1.3, p1 states that "... If the sentry object returns
|
7216 |
|
|
true, when converted to a value of type bool, the function endeavors
|
7217 |
|
|
to obtain the requested input..." It is not clear from this (or
|
7218 |
|
|
the rest of the paragraph) what precisely the behavior should be when
|
7219 |
|
|
the sentry ctor exits by throwing an exception or when the sentry
|
7220 |
|
|
object returns false. In particular, what is the number of characters
|
7221 |
|
|
extracted that gcount() returns supposed to be?</p>
|
7222 |
|
|
|
7223 |
|
|
<p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
|
7224 |
|
|
"... In any case, it then stores a null character (using
|
7225 |
|
|
charT()) into the next successive location of the array." Is not
|
7226 |
|
|
clear whether this sentence applies if either of the conditions above
|
7227 |
|
|
holds (i.e., when sentry fails).</p>
|
7228 |
|
|
<p><b>Proposed resolution:</b></p>
|
7229 |
|
|
<p>Add to 27.6.1.3, p1 after the sentence</p>
|
7230 |
|
|
|
7231 |
|
|
<blockquote>
|
7232 |
|
|
"... If the sentry object returns true, when converted to a value of
|
7233 |
|
|
type bool, the function endeavors to obtain the requested input."
|
7234 |
|
|
</blockquote>
|
7235 |
|
|
|
7236 |
|
|
<p>the following</p>
|
7237 |
|
|
|
7238 |
|
|
|
7239 |
|
|
<blockquote>
|
7240 |
|
|
"Otherwise, if the sentry constructor exits by throwing an exception or
|
7241 |
|
|
if the sentry object returns false, when converted to a value of type
|
7242 |
|
|
bool, the function returns without attempting to obtain any input. In
|
7243 |
|
|
either case the number of extracted characters is set to 0; unformatted
|
7244 |
|
|
input functions taking a character array of non-zero size as an argument
|
7245 |
|
|
shall also store a null character (using charT()) in the first location
|
7246 |
|
|
of the array."
|
7247 |
|
|
</blockquote>
|
7248 |
|
|
<p><b>Rationale:</b></p>
|
7249 |
|
|
<p>Although the general philosophy of the input functions is that the
|
7250 |
|
|
argument should not be modified upon failure, <tt>getline</tt>
|
7251 |
|
|
historically added a terminating null unconditionally. Most
|
7252 |
|
|
implementations still do that. Earlier versions of the draft standard
|
7253 |
|
|
had language that made this an unambiguous requirement; those words
|
7254 |
|
|
were moved to a place where their context made them less clear. See
|
7255 |
|
|
Jerry Schwarz's message c++std-lib-7618.</p>
|
7256 |
|
|
<hr>
|
7257 |
|
|
<a name="248"><h3>248. time_get fails to set eofbit</h3></a><p><b>Section:</b> 22.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.time"> [lib.category.time]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 22 June 2000</p>
|
7258 |
|
|
<p>There is no requirement that any of time_get member functions set
|
7259 |
|
|
ios::eofbit when they reach the end iterator while parsing their input.
|
7260 |
|
|
Since members of both the num_get and money_get facets are required to
|
7261 |
|
|
do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
|
7262 |
|
|
should follow the same requirement for consistency.</p>
|
7263 |
|
|
<p><b>Proposed resolution:</b></p>
|
7264 |
|
|
<p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
|
7265 |
|
|
|
7266 |
|
|
<blockquote>
|
7267 |
|
|
If the end iterator is reached during parsing by any of the get()
|
7268 |
|
|
member functions, the member sets ios_base::eofbit in err.
|
7269 |
|
|
</blockquote>
|
7270 |
|
|
<p><b>Rationale:</b></p>
|
7271 |
|
|
<p>Two alternative resolutions were proposed. The LWG chose this one
|
7272 |
|
|
because it was more consistent with the way eof is described for other
|
7273 |
|
|
input facets.</p>
|
7274 |
|
|
<hr>
|
7275 |
|
|
<a name="250"><h3>250. splicing invalidates iterators</h3></a><p><b>Section:</b> 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Brian Parker <b>Date:</b> 14 Jul 2000</p>
|
7276 |
|
|
<p>
|
7277 |
|
|
Section 23.2.2.4 [lib.list.ops] states that
|
7278 |
|
|
</p>
|
7279 |
|
|
<pre> void splice(iterator position, list<T, Allocator>& x);
|
7280 |
|
|
</pre>
|
7281 |
|
|
<p>
|
7282 |
|
|
<i>invalidates</i> all iterators and references to list <tt>x</tt>.
|
7283 |
|
|
</p>
|
7284 |
|
|
|
7285 |
|
|
<p>
|
7286 |
|
|
This is unnecessary and defeats an important feature of splice. In
|
7287 |
|
|
fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
|
7288 |
|
|
after <tt>splice</tt>.
|
7289 |
|
|
</p>
|
7290 |
|
|
<p><b>Proposed resolution:</b></p>
|
7291 |
|
|
|
7292 |
|
|
<p>Add a footnote to 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, paragraph 1:</p>
|
7293 |
|
|
<blockquote>
|
7294 |
|
|
[<i>Footnote:</i> As specified in 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, paragraphs
|
7295 |
|
|
4-5, the semantics described in this clause applies only to the case
|
7296 |
|
|
where allocators compare equal. --end footnote]
|
7297 |
|
|
</blockquote>
|
7298 |
|
|
|
7299 |
|
|
<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 4 with:</p>
|
7300 |
|
|
<blockquote>
|
7301 |
|
|
Effects: Inserts the contents of x before position and x becomes
|
7302 |
|
|
empty. Pointers and references to the moved elements of x now refer to
|
7303 |
|
|
those same elements but as members of *this. Iterators referring to the
|
7304 |
|
|
moved elements will continue to refer to their elements, but they now
|
7305 |
|
|
behave as iterators into *this, not into x.
|
7306 |
|
|
</blockquote>
|
7307 |
|
|
|
7308 |
|
|
<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 7 with:</p>
|
7309 |
|
|
<blockquote>
|
7310 |
|
|
Effects: Inserts an element pointed to by i from list x before
|
7311 |
|
|
position and removes the element from x. The result is unchanged if
|
7312 |
|
|
position == i or position == ++i. Pointers and references to *i continue
|
7313 |
|
|
to refer to this same element but as a member of *this. Iterators to *i
|
7314 |
|
|
(including i itself) continue to refer to the same element, but now
|
7315 |
|
|
behave as iterators into *this, not into x.
|
7316 |
|
|
</blockquote>
|
7317 |
|
|
|
7318 |
|
|
<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraph 12 with:</p>
|
7319 |
|
|
<blockquote>
|
7320 |
|
|
Requires: [first, last) is a valid range in x. The result is
|
7321 |
|
|
undefined if position is an iterator in the range [first, last).
|
7322 |
|
|
Pointers and references to the moved elements of x now refer to those
|
7323 |
|
|
same elements but as members of *this. Iterators referring to the moved
|
7324 |
|
|
elements will continue to refer to their elements, but they now behave as
|
7325 |
|
|
iterators into *this, not into x.
|
7326 |
|
|
</blockquote>
|
7327 |
|
|
|
7328 |
|
|
<p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
|
7329 |
|
|
<p><b>Rationale:</b></p>
|
7330 |
|
|
<p>The original proposed resolution said that iterators and references
|
7331 |
|
|
would remain "valid". The new proposed resolution clarifies what that
|
7332 |
|
|
means. Note that this only applies to the case of equal allocators.
|
7333 |
|
|
>From 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when
|
7334 |
|
|
allocators compare nonequal is outside the scope of the standard.</p>
|
7335 |
|
|
<hr>
|
7336 |
|
|
<a name="251"><h3>251. basic_stringbuf missing allocator_type</h3></a><p><b>Section:</b> 27.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p>
|
7337 |
|
|
<p>The synopsis for the template class <tt>basic_stringbuf</tt>
|
7338 |
|
|
doesn't list a typedef for the template parameter
|
7339 |
|
|
<tt>Allocator</tt>. This makes it impossible to determine the type of
|
7340 |
|
|
the allocator at compile time. It's also inconsistent with all other
|
7341 |
|
|
template classes in the library that do provide a typedef for the
|
7342 |
|
|
<tt>Allocator</tt> parameter.</p>
|
7343 |
|
|
<p><b>Proposed resolution:</b></p>
|
7344 |
|
|
<p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
|
7345 |
|
|
basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
|
7346 |
|
|
basic_stringstream (27.7.4) the typedef:</p>
|
7347 |
|
|
<pre> typedef Allocator allocator_type;
|
7348 |
|
|
</pre>
|
7349 |
|
|
<hr>
|
7350 |
|
|
<a name="252"><h3>252. missing casts/C-style casts used in iostreams</h3></a><p><b>Section:</b> 27.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jul 2000</p>
|
7351 |
|
|
<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
|
7352 |
|
|
const_cast<> in the Returns clause for basic_istringstream<>::rdbuf().
|
7353 |
|
|
The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
|
7354 |
|
|
D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
|
7355 |
|
|
the cast altogether.</p>
|
7356 |
|
|
|
7357 |
|
|
<p>C-style casts have not been deprecated, so the first part of this
|
7358 |
|
|
issue is stylistic rather than a matter of correctness.</p>
|
7359 |
|
|
<p><b>Proposed resolution:</b></p>
|
7360 |
|
|
<p>In 27.7.2.2, p1 replace </p>
|
7361 |
|
|
<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre>
|
7362 |
|
|
|
7363 |
|
|
<p>with</p>
|
7364 |
|
|
<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
|
7365 |
|
|
|
7366 |
|
|
|
7367 |
|
|
<p>In 27.7.3.2, p1 replace</p>
|
7368 |
|
|
<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre>
|
7369 |
|
|
|
7370 |
|
|
<p>with</p>
|
7371 |
|
|
<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
|
7372 |
|
|
|
7373 |
|
|
<p>In 27.7.6, p1, replace</p>
|
7374 |
|
|
<pre> -1- Returns: &sb</pre>
|
7375 |
|
|
|
7376 |
|
|
<p>with</p>
|
7377 |
|
|
<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre>
|
7378 |
|
|
|
7379 |
|
|
<p>In D.7.2.2, p1 replace</p>
|
7380 |
|
|
<pre> -2- Returns: &sb. </pre>
|
7381 |
|
|
|
7382 |
|
|
<p>with</p>
|
7383 |
|
|
<pre> -2- Returns: const_cast<strstreambuf*>(&sb).</pre>
|
7384 |
|
|
<hr>
|
7385 |
|
|
<a name="253"><h3>253. valarray helper functions are almost entirely useless</h3></a><p><b>Section:</b> 26.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.3.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 31 Jul 2000</p>
|
7386 |
|
|
<p>This discussion is adapted from message c++std-lib-7056 posted
|
7387 |
|
|
November 11, 1999. I don't think that anyone can reasonably claim
|
7388 |
|
|
that the problem described below is NAD.</p>
|
7389 |
|
|
|
7390 |
|
|
<p>These valarray constructors can never be called:</p>
|
7391 |
|
|
|
7392 |
|
|
<pre> template <class T>
|
7393 |
|
|
valarray<T>::valarray(const slice_array<T> &);
|
7394 |
|
|
template <class T>
|
7395 |
|
|
valarray<T>::valarray(const gslice_array<T> &);
|
7396 |
|
|
template <class T>
|
7397 |
|
|
valarray<T>::valarray(const mask_array<T> &);
|
7398 |
|
|
template <class T>
|
7399 |
|
|
valarray<T>::valarray(const indirect_array<T> &);
|
7400 |
|
|
</pre>
|
7401 |
|
|
|
7402 |
|
|
<p>Similarly, these valarray assignment operators cannot be
|
7403 |
|
|
called:</p>
|
7404 |
|
|
|
7405 |
|
|
<pre> template <class T>
|
7406 |
|
|
valarray<T> valarray<T>::operator=(const slice_array<T> &);
|
7407 |
|
|
template <class T>
|
7408 |
|
|
valarray<T> valarray<T>::operator=(const gslice_array<T> &);
|
7409 |
|
|
template <class T>
|
7410 |
|
|
valarray<T> valarray<T>::operator=(const mask_array<T> &);
|
7411 |
|
|
template <class T>
|
7412 |
|
|
valarray<T> valarray<T>::operator=(const indirect_array<T> &);
|
7413 |
|
|
</pre>
|
7414 |
|
|
|
7415 |
|
|
<p>Please consider the following example:</p>
|
7416 |
|
|
|
7417 |
|
|
<pre> #include <valarray>
|
7418 |
|
|
using namespace std;
|
7419 |
|
|
|
7420 |
|
|
int main()
|
7421 |
|
|
{
|
7422 |
|
|
valarray<double> va1(12);
|
7423 |
|
|
valarray<double> va2(va1[slice(1,4,3)]); // line 1
|
7424 |
|
|
}
|
7425 |
|
|
</pre>
|
7426 |
|
|
|
7427 |
|
|
|
7428 |
|
|
<p>Since the valarray va1 is non-const, the result of the sub-expression
|
7429 |
|
|
va1[slice(1,4,3)] at line 1 is an rvalue of type const
|
7430 |
|
|
std::slice_array<double>. This slice_array rvalue is then used to
|
7431 |
|
|
construct va2. The constructor that is used to construct va2 is
|
7432 |
|
|
declared like this:</p>
|
7433 |
|
|
|
7434 |
|
|
<pre> template <class T>
|
7435 |
|
|
valarray<T>::valarray(const slice_array<T> &);
|
7436 |
|
|
</pre>
|
7437 |
|
|
|
7438 |
|
|
<p>Notice the constructor's const reference parameter. When the
|
7439 |
|
|
constructor is called, a slice_array must be bound to this reference.
|
7440 |
|
|
The rules for binding an rvalue to a const reference are in 8.5.3,
|
7441 |
|
|
paragraph 5 (see also 13.3.3.1.4). Specifically, paragraph 5
|
7442 |
|
|
indicates that a second slice_array rvalue is constructed (in this
|
7443 |
|
|
case copy-constructed) from the first one; it is this second rvalue
|
7444 |
|
|
that is bound to the reference parameter. Paragraph 5 also requires
|
7445 |
|
|
that the constructor that is used for this purpose be callable,
|
7446 |
|
|
regardless of whether the second rvalue is elided. The
|
7447 |
|
|
copy-constructor in this case is not callable, however, because it is
|
7448 |
|
|
private. Therefore, the compiler should report an error.</p>
|
7449 |
|
|
|
7450 |
|
|
<p>Since slice_arrays are always rvalues, the valarray constructor that has a
|
7451 |
|
|
parameter of type const slice_array<T> & can never be called. The
|
7452 |
|
|
same reasoning applies to the three other constructors and the four
|
7453 |
|
|
assignment operators that are listed at the beginning of this post.
|
7454 |
|
|
Furthermore, since these functions cannot be called, the valarray helper
|
7455 |
|
|
classes are almost entirely useless.</p>
|
7456 |
|
|
<p><b>Proposed resolution:</b></p>
|
7457 |
|
|
<p>slice_array:</p>
|
7458 |
|
|
<ul>
|
7459 |
|
|
<li> Make the copy constructor and copy-assignment operator declarations
|
7460 |
|
|
public in the slice_array class template definition in 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> </li>
|
7461 |
|
|
<li> remove paragraph 3 of 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
|
7462 |
|
|
</li>
|
7463 |
|
|
<li> remove the copy constructor declaration from 26.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a>
|
7464 |
|
|
</li>
|
7465 |
|
|
<li> change paragraph 1 of 26.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> to read "This constructor is declared
|
7466 |
|
|
to be private. This constructor need not be defined."</li>
|
7467 |
|
|
<li> remove the first sentence of paragraph 1 of 26.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a>
|
7468 |
|
|
</li>
|
7469 |
|
|
<li> Change the first three words of the second sentence of paragraph 1 of
|
7470 |
|
|
26.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> to "These assignment operators have"</li>
|
7471 |
|
|
</ul>
|
7472 |
|
|
|
7473 |
|
|
<p>gslice_array:</p>
|
7474 |
|
|
<ul>
|
7475 |
|
|
<li> Make the copy constructor and copy-assignment operator declarations
|
7476 |
|
|
public in the gslice_array class template definition in 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> </li>
|
7477 |
|
|
<li> remove the note in paragraph 3 of 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
|
7478 |
|
|
</li>
|
7479 |
|
|
<li> remove the copy constructor declaration from 26.3.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a>
|
7480 |
|
|
</li>
|
7481 |
|
|
<li> change paragraph 1 of 26.3.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> to read "This constructor is declared
|
7482 |
|
|
to be private. This constructor need not be defined."</li>
|
7483 |
|
|
<li> remove the first sentence of paragraph 1 of 26.3.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a>
|
7484 |
|
|
</li>
|
7485 |
|
|
<li> Change the first three words of the second sentence of paragraph 1 of
|
7486 |
|
|
26.3.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> to "These assignment operators have"</li>
|
7487 |
|
|
</ul>
|
7488 |
|
|
|
7489 |
|
|
<p>mask_array:</p>
|
7490 |
|
|
<ul>
|
7491 |
|
|
<li> Make the copy constructor and copy-assignment operator declarations
|
7492 |
|
|
public in the mask_array class template definition in 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> </li>
|
7493 |
|
|
<li> remove the note in paragraph 2 of 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
|
7494 |
|
|
</li>
|
7495 |
|
|
<li> remove the copy constructor declaration from 26.3.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a>
|
7496 |
|
|
</li>
|
7497 |
|
|
<li> change paragraph 1 of 26.3.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> to read "This constructor is declared
|
7498 |
|
|
to be private. This constructor need not be defined."</li>
|
7499 |
|
|
<li> remove the first sentence of paragraph 1 of 26.3.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a>
|
7500 |
|
|
</li>
|
7501 |
|
|
<li> Change the first three words of the second sentence of paragraph 1 of
|
7502 |
|
|
26.3.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> to "These assignment operators have"</li>
|
7503 |
|
|
</ul>
|
7504 |
|
|
|
7505 |
|
|
<p>indirect_array:</p>
|
7506 |
|
|
<ul>
|
7507 |
|
|
<li>Make the copy constructor and copy-assignment operator declarations
|
7508 |
|
|
public in the indirect_array class definition in 26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
|
7509 |
|
|
</li>
|
7510 |
|
|
<li> remove the note in paragraph 2 of 26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
|
7511 |
|
|
</li>
|
7512 |
|
|
<li> remove the copy constructor declaration from 26.3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a>
|
7513 |
|
|
</li>
|
7514 |
|
|
<li> change the descriptive text in 26.3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> to read "This constructor is
|
7515 |
|
|
declared to be private. This constructor need not be defined."</li>
|
7516 |
|
|
<li> remove the first sentence of paragraph 1 of 26.3.9.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a>
|
7517 |
|
|
</li>
|
7518 |
|
|
<li> Change the first three words of the second sentence of paragraph 1 of
|
7519 |
|
|
26.3.9.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> to "These assignment operators have"</li>
|
7520 |
|
|
</ul>
|
7521 |
|
|
<p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
|
7522 |
|
|
copy constructor and copy assignment operators public, instead of
|
7523 |
|
|
removing them.]</i></p>
|
7524 |
|
|
<p><b>Rationale:</b></p>
|
7525 |
|
|
<p>Keeping the valarray constructors private is untenable. Merely
|
7526 |
|
|
making valarray a friend of the helper classes isn't good enough,
|
7527 |
|
|
because access to the copy constructor is checked in the user's
|
7528 |
|
|
environment.</p>
|
7529 |
|
|
|
7530 |
|
|
<p>Making the assignment operator public is not strictly necessary to
|
7531 |
|
|
solve this problem. A majority of the LWG <i>(straw poll: 13-4)</i>
|
7532 |
|
|
believed we should make the assignment operators public, in addition
|
7533 |
|
|
to the copy constructors, for reasons of symmetry and user
|
7534 |
|
|
expectation.</p>
|
7535 |
|
|
<hr>
|
7536 |
|
|
<a name="256"><h3>256. typo in 27.4.4.2, p17: copy_event does not exist</h3></a><p><b>Section:</b> 27.4.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 21 Aug 2000</p>
|
7537 |
|
|
<p>
|
7538 |
|
|
27.4.4.2, p17 says
|
7539 |
|
|
</p>
|
7540 |
|
|
|
7541 |
|
|
<blockquote>
|
7542 |
|
|
-17- Before copying any parts of rhs, calls each registered callback
|
7543 |
|
|
pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
|
7544 |
|
|
exceptions() have been replaced, calls each callback pair that was
|
7545 |
|
|
copied from rhs as (*fn)(copy_event,*this,index).
|
7546 |
|
|
</blockquote>
|
7547 |
|
|
|
7548 |
|
|
<p>
|
7549 |
|
|
The name copy_event isn't defined anywhere. The intended name was
|
7550 |
|
|
copyfmt_event.
|
7551 |
|
|
</p>
|
7552 |
|
|
<p><b>Proposed resolution:</b></p>
|
7553 |
|
|
<p>Replace copy_event with copyfmt_event in the named paragraph.</p>
|
7554 |
|
|
<hr>
|
7555 |
|
|
<a name="259"><h3>259. <tt>basic_string::operator[]</tt> and const correctness</h3></a><p><b>Section:</b> 21.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.access"> [lib.string.access]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Chris Newton <b>Date:</b> 27 Aug 2000</p>
|
7556 |
|
|
<p>
|
7557 |
|
|
<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
|
7558 |
|
|
</p>
|
7559 |
|
|
|
7560 |
|
|
<p>
|
7561 |
|
|
The standard's description of <tt>basic_string<>::operator[]</tt>
|
7562 |
|
|
seems to violate const correctness.
|
7563 |
|
|
</p>
|
7564 |
|
|
|
7565 |
|
|
<p>
|
7566 |
|
|
The standard (21.3.4/1) says that "If <tt>pos < size()</tt>,
|
7567 |
|
|
returns <tt>data()[pos]</tt>." The types don't work. The
|
7568 |
|
|
return value of <tt>data()</tt> is <tt>const charT*</tt>, but
|
7569 |
|
|
<tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
|
7570 |
|
|
</p>
|
7571 |
|
|
<p><b>Proposed resolution:</b></p>
|
7572 |
|
|
<p>
|
7573 |
|
|
In section 21.3.4, paragraph 1, change
|
7574 |
|
|
"<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
|
7575 |
|
|
<i>pos</i>)</tt>".
|
7576 |
|
|
</p>
|
7577 |
|
|
<hr>
|
7578 |
|
|
<a name="260"><h3>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
|
7579 |
|
|
</h3></a><p><b>Section:</b> 24.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p>
|
7580 |
|
|
<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
|
7581 |
|
|
it as returning the iterator by value. 24.5.1.2, p5 shows the same
|
7582 |
|
|
operator as returning the iterator by reference. That's incorrect
|
7583 |
|
|
given the Effects clause below (since a temporary is returned). The
|
7584 |
|
|
`&' is probably just a typo.</p>
|
7585 |
|
|
<p><b>Proposed resolution:</b></p>
|
7586 |
|
|
<p>Change the declaration in 24.5.1.2, p5 from</p>
|
7587 |
|
|
<pre> istream_iterator<T,charT,traits,Distance>& operator++(int);
|
7588 |
|
|
</pre>
|
7589 |
|
|
<p>to</p>
|
7590 |
|
|
<pre> istream_iterator<T,charT,traits,Distance> operator++(int);
|
7591 |
|
|
</pre>
|
7592 |
|
|
<p>(that is, remove the `&').</p>
|
7593 |
|
|
<hr>
|
7594 |
|
|
<a name="261"><h3>261. Missing description of <tt>istream_iterator::operator!=</tt>
|
7595 |
|
|
</h3></a><p><b>Section:</b> 24.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Aug 2000</p>
|
7596 |
|
|
<p>
|
7597 |
|
|
24.5.1, p3 lists the synopsis for
|
7598 |
|
|
</p>
|
7599 |
|
|
|
7600 |
|
|
<pre> template <class T, class charT, class traits, class Distance>
|
7601 |
|
|
bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
|
7602 |
|
|
const istream_iterator<T,charT,traits,Distance>& y);
|
7603 |
|
|
</pre>
|
7604 |
|
|
|
7605 |
|
|
<p>
|
7606 |
|
|
but there is no description of what the operator does (i.e., no Effects
|
7607 |
|
|
or Returns clause) in 24.5.1.2.
|
7608 |
|
|
</p>
|
7609 |
|
|
<p><b>Proposed resolution:</b></p>
|
7610 |
|
|
<p>
|
7611 |
|
|
Add paragraph 7 to the end of section 24.5.1.2 with the following text:
|
7612 |
|
|
</p>
|
7613 |
|
|
|
7614 |
|
|
<pre> template <class T, class charT, class traits, class Distance>
|
7615 |
|
|
bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
|
7616 |
|
|
const istream_iterator<T,charT,traits,Distance>& y);
|
7617 |
|
|
</pre>
|
7618 |
|
|
|
7619 |
|
|
<p>-7- Returns: !(x == y).</p>
|
7620 |
|
|
<hr>
|
7621 |
|
|
<a name="262"><h3>262. Bitmask operator ~ specified incorrectly</h3></a><p><b>Section:</b> 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 03 Sep 2000</p>
|
7622 |
|
|
<p>
|
7623 |
|
|
The ~ operation should be applied after the cast to int_type.
|
7624 |
|
|
</p>
|
7625 |
|
|
<p><b>Proposed resolution:</b></p>
|
7626 |
|
|
<p>
|
7627 |
|
|
Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
|
7628 |
|
|
</p>
|
7629 |
|
|
|
7630 |
|
|
<pre> bitmask operator~ ( bitmask X )
|
7631 |
|
|
{ return static_cast< bitmask>(static_cast<int_type>(~ X)); }
|
7632 |
|
|
</pre>
|
7633 |
|
|
|
7634 |
|
|
<p>
|
7635 |
|
|
to:
|
7636 |
|
|
</p>
|
7637 |
|
|
|
7638 |
|
|
<pre> bitmask operator~ ( bitmask X )
|
7639 |
|
|
{ return static_cast< bitmask>(~static_cast<int_type>(X)); }
|
7640 |
|
|
</pre>
|
7641 |
|
|
<hr>
|
7642 |
|
|
<a name="263"><h3>263. Severe restriction on <tt>basic_string</tt> reference counting</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Kevlin Henney <b>Date:</b> 04 Sep 2000</p>
|
7643 |
|
|
<p>
|
7644 |
|
|
The note in paragraph 6 suggests that the invalidation rules for
|
7645 |
|
|
references, pointers, and iterators in paragraph 5 permit a reference-
|
7646 |
|
|
counted implementation (actually, according to paragraph 6, they permit
|
7647 |
|
|
a "reference counted implementation", but this is a minor editorial fix).
|
7648 |
|
|
</p>
|
7649 |
|
|
|
7650 |
|
|
<p>
|
7651 |
|
|
However, the last sub-bullet is so worded as to make a reference-counted
|
7652 |
|
|
implementation unviable. In the following example none of the
|
7653 |
|
|
conditions for iterator invalidation are satisfied:
|
7654 |
|
|
</p>
|
7655 |
|
|
|
7656 |
|
|
<pre> // first example: "*******************" should be printed twice
|
7657 |
|
|
string original = "some arbitrary text", copy = original;
|
7658 |
|
|
const string & alias = original;
|
7659 |
|
|
|
7660 |
|
|
string::const_iterator i = alias.begin(), e = alias.end();
|
7661 |
|
|
for(string::iterator j = original.begin(); j != original.end(); ++j)
|
7662 |
|
|
*j = '*';
|
7663 |
|
|
while(i != e)
|
7664 |
|
|
cout << *i++;
|
7665 |
|
|
cout << endl;
|
7666 |
|
|
cout << original << endl;
|
7667 |
|
|
</pre>
|
7668 |
|
|
|
7669 |
|
|
<p>
|
7670 |
|
|
Similarly, in the following example:
|
7671 |
|
|
</p>
|
7672 |
|
|
|
7673 |
|
|
<pre> // second example: "some arbitrary text" should be printed out
|
7674 |
|
|
string original = "some arbitrary text", copy = original;
|
7675 |
|
|
const string & alias = original;
|
7676 |
|
|
|
7677 |
|
|
string::const_iterator i = alias.begin();
|
7678 |
|
|
original.begin();
|
7679 |
|
|
while(i != alias.end())
|
7680 |
|
|
cout << *i++;
|
7681 |
|
|
</pre>
|
7682 |
|
|
|
7683 |
|
|
<p>
|
7684 |
|
|
I have tested this on three string implementations, two of which were
|
7685 |
|
|
reference counted. The reference-counted implementations gave
|
7686 |
|
|
"surprising behavior" because they invalidated iterators on
|
7687 |
|
|
the first call to non-const begin since construction. The current
|
7688 |
|
|
wording does not permit such invalidation because it does not take
|
7689 |
|
|
into account the first call since construction, only the first call
|
7690 |
|
|
since various member and non-member function calls.
|
7691 |
|
|
</p>
|
7692 |
|
|
<p><b>Proposed resolution:</b></p>
|
7693 |
|
|
<p>
|
7694 |
|
|
Change the following sentence in 21.3 paragraph 5 from
|
7695 |
|
|
</p>
|
7696 |
|
|
|
7697 |
|
|
<blockquote>
|
7698 |
|
|
Subsequent to any of the above uses except the forms of insert() and
|
7699 |
|
|
erase() which return iterators, the first call to non-const member
|
7700 |
|
|
functions operator[](), at(), begin(), rbegin(), end(), or rend().
|
7701 |
|
|
</blockquote>
|
7702 |
|
|
|
7703 |
|
|
<p>to</p>
|
7704 |
|
|
|
7705 |
|
|
<blockquote>
|
7706 |
|
|
Following construction or any of the above uses, except the forms of
|
7707 |
|
|
insert() and erase() that return iterators, the first call to non-
|
7708 |
|
|
const member functions operator[](), at(), begin(), rbegin(), end(),
|
7709 |
|
|
or rend().
|
7710 |
|
|
</blockquote>
|
7711 |
|
|
<hr>
|
7712 |
|
|
<a name="264"><h3>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> John Potter <b>Date:</b> 07 Sep 2000</p>
|
7713 |
|
|
<p>
|
7714 |
|
|
Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient.
|
7715 |
|
|
Consider inserting a sorted range of even integers into a set<int> containing the odd
|
7716 |
|
|
integers in the same range.
|
7717 |
|
|
</p>
|
7718 |
|
|
|
7719 |
|
|
<p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
|
7720 |
|
|
<p><b>Proposed resolution:</b></p>
|
7721 |
|
|
<p>
|
7722 |
|
|
In Table 69, in section 23.1.2, change the complexity clause for
|
7723 |
|
|
insertion of a range from "N log(size() + N) (N is the distance
|
7724 |
|
|
from i to j) in general; linear if [i, j) is sorted according to
|
7725 |
|
|
value_comp()" to "N log(size() + N), where N is the distance
|
7726 |
|
|
from i to j".
|
7727 |
|
|
</p>
|
7728 |
|
|
|
7729 |
|
|
<p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
|
7730 |
|
|
parens in the revised wording.]</i></p>
|
7731 |
|
|
|
7732 |
|
|
<p><b>Rationale:</b></p>
|
7733 |
|
|
<p>
|
7734 |
|
|
Testing for valid insertions could be less efficient than simply
|
7735 |
|
|
inserting the elements when the range is not both sorted and between
|
7736 |
|
|
two adjacent existing elements; this could be a QOI issue.
|
7737 |
|
|
</p>
|
7738 |
|
|
|
7739 |
|
|
<p>
|
7740 |
|
|
The LWG considered two other options: (a) specifying that the
|
7741 |
|
|
complexity was linear if [i, j) is sorted according to value_comp()
|
7742 |
|
|
and between two adjacent existing elements; or (b) changing to
|
7743 |
|
|
Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
|
7744 |
|
|
number of elements which do not insert immediately after the previous
|
7745 |
|
|
element from [i, j) including the first). The LWG felt that, since
|
7746 |
|
|
we can't guarantee linear time complexity whenever the range to be
|
7747 |
|
|
inserted is sorted, it's more trouble than it's worth to say that it's
|
7748 |
|
|
linear in some special cases.
|
7749 |
|
|
</p>
|
7750 |
|
|
<hr>
|
7751 |
|
|
<a name="265"><h3>265. std::pair::pair() effects overly restrictive</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 11 Sep 2000</p>
|
7752 |
|
|
<p>
|
7753 |
|
|
I don't see any requirements on the types of the elements of the
|
7754 |
|
|
std::pair container in 20.2.2. From the descriptions of the member
|
7755 |
|
|
functions it appears that they must at least satisfy the requirements of
|
7756 |
|
|
20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
|
7757 |
|
|
the case of the [in]equality operators also the requirements of 20.1.1
|
7758 |
|
|
[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
|
7759 |
|
|
</p>
|
7760 |
|
|
|
7761 |
|
|
<p>
|
7762 |
|
|
I believe that the the CopyConstructible requirement is unnecessary in
|
7763 |
|
|
the case of 20.2.2, p2.
|
7764 |
|
|
</p>
|
7765 |
|
|
<p><b>Proposed resolution:</b></p>
|
7766 |
|
|
<p>Change the Effects clause in 20.2.2, p2 from</p>
|
7767 |
|
|
|
7768 |
|
|
<blockquote>
|
7769 |
|
|
-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
|
7770 |
|
|
first(T1()), second(T2()) {} </tt>
|
7771 |
|
|
</blockquote>
|
7772 |
|
|
|
7773 |
|
|
<p>to</p>
|
7774 |
|
|
|
7775 |
|
|
<blockquote>
|
7776 |
|
|
-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
|
7777 |
|
|
first(), second() {} </tt>
|
7778 |
|
|
</blockquote>
|
7779 |
|
|
<p><b>Rationale:</b></p>
|
7780 |
|
|
<p>The existing specification of pair's constructor appears to be a
|
7781 |
|
|
historical artifact: there was concern that pair's members be properly
|
7782 |
|
|
zero-initialized when they are built-in types. At one time there was
|
7783 |
|
|
uncertainty about whether they would be zero-initialized if the
|
7784 |
|
|
default constructor was written the obvious way. This has been
|
7785 |
|
|
clarified by core issue 178, and there is no longer any doubt that
|
7786 |
|
|
the straightforward implementation is correct.</p>
|
7787 |
|
|
<hr>
|
7788 |
|
|
<a name="266"><h3>266. bad_exception::~bad_exception() missing Effects clause</h3></a><p><b>Section:</b> 18.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 24 Sep 2000</p>
|
7789 |
|
|
<p>
|
7790 |
|
|
The synopsis for std::bad_exception lists the function ~bad_exception()
|
7791 |
|
|
but there is no description of what the function does (the Effects
|
7792 |
|
|
clause is missing).
|
7793 |
|
|
</p>
|
7794 |
|
|
<p><b>Proposed resolution:</b></p>
|
7795 |
|
|
<p>
|
7796 |
|
|
Remove the destructor from the class synopses of
|
7797 |
|
|
<tt>bad_alloc</tt> (18.4.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.alloc"> [lib.bad.alloc]</a>),
|
7798 |
|
|
<tt>bad_cast</tt> (18.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.cast"> [lib.bad.cast]</a>),
|
7799 |
|
|
<tt>bad_typeid</tt> (18.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.typeid"> [lib.bad.typeid]</a>),
|
7800 |
|
|
and <tt>bad_exception</tt> (18.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>).
|
7801 |
|
|
</p>
|
7802 |
|
|
<p><b>Rationale:</b></p>
|
7803 |
|
|
<p>
|
7804 |
|
|
This is a general problem with the exception classes in clause 18.
|
7805 |
|
|
The proposed resolution is to remove the destructors from the class
|
7806 |
|
|
synopses, rather than to document the destructors' behavior, because
|
7807 |
|
|
removing them is more consistent with how exception classes are
|
7808 |
|
|
described in clause 19.
|
7809 |
|
|
</p>
|
7810 |
|
|
<hr>
|
7811 |
|
|
<a name="268"><h3>268. Typo in locale synopsis</h3></a><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Oct 2000</p>
|
7812 |
|
|
<p>The synopsis of the class std::locale in 22.1.1 contains two typos:
|
7813 |
|
|
the semicolons after the declarations of the default ctor
|
7814 |
|
|
locale::locale() and the copy ctor locale::locale(const locale&)
|
7815 |
|
|
are missing.</p>
|
7816 |
|
|
<p><b>Proposed resolution:</b></p>
|
7817 |
|
|
<p>Add the missing semicolons, i.e., change</p>
|
7818 |
|
|
|
7819 |
|
|
<pre> // construct/copy/destroy:
|
7820 |
|
|
locale() throw()
|
7821 |
|
|
locale(const locale& other) throw()
|
7822 |
|
|
</pre>
|
7823 |
|
|
|
7824 |
|
|
<p>in the synopsis in 22.1.1 to</p>
|
7825 |
|
|
|
7826 |
|
|
<pre> // construct/copy/destroy:
|
7827 |
|
|
locale() throw();
|
7828 |
|
|
locale(const locale& other) throw();
|
7829 |
|
|
</pre>
|
7830 |
|
|
<hr>
|
7831 |
|
|
<a name="270"><h3>270. Binary search requirements overly strict</h3></a><p><b>Section:</b> 25.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.binary.search"> [lib.alg.binary.search]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Oct 2000</p>
|
7832 |
|
|
<p>
|
7833 |
|
|
Each of the four binary search algorithms (lower_bound, upper_bound,
|
7834 |
|
|
equal_range, binary_search) has a form that allows the user to pass a
|
7835 |
|
|
comparison function object. According to 25.3, paragraph 2, that
|
7836 |
|
|
comparison function object has to be a strict weak ordering.
|
7837 |
|
|
</p>
|
7838 |
|
|
|
7839 |
|
|
<p>
|
7840 |
|
|
This requirement is slightly too strict. Suppose we are searching
|
7841 |
|
|
through a sequence containing objects of type X, where X is some
|
7842 |
|
|
large record with an integer key. We might reasonably want to look
|
7843 |
|
|
up a record by key, in which case we would want to write something
|
7844 |
|
|
like this:
|
7845 |
|
|
</p>
|
7846 |
|
|
<pre> struct key_comp {
|
7847 |
|
|
bool operator()(const X& x, int n) const {
|
7848 |
|
|
return x.key() < n;
|
7849 |
|
|
}
|
7850 |
|
|
}
|
7851 |
|
|
|
7852 |
|
|
std::lower_bound(first, last, 47, key_comp());
|
7853 |
|
|
</pre>
|
7854 |
|
|
|
7855 |
|
|
<p>
|
7856 |
|
|
key_comp is not a strict weak ordering, but there is no reason to
|
7857 |
|
|
prohibit its use in lower_bound.
|
7858 |
|
|
</p>
|
7859 |
|
|
|
7860 |
|
|
<p>
|
7861 |
|
|
There's no difficulty in implementing lower_bound so that it allows
|
7862 |
|
|
the use of something like key_comp. (It will probably work unless an
|
7863 |
|
|
implementor takes special pains to forbid it.) What's difficult is
|
7864 |
|
|
formulating language in the standard to specify what kind of
|
7865 |
|
|
comparison function is acceptable. We need a notion that's slightly
|
7866 |
|
|
more general than that of a strict weak ordering, one that can encompass
|
7867 |
|
|
a comparison function that involves different types. Expressing that
|
7868 |
|
|
notion may be complicated.
|
7869 |
|
|
</p>
|
7870 |
|
|
|
7871 |
|
|
<p><i>Additional questions raised at the Toronto meeting:</i></p>
|
7872 |
|
|
<ul>
|
7873 |
|
|
<li> Do we really want to specify what ordering the implementor must
|
7874 |
|
|
use when calling the function object? The standard gives
|
7875 |
|
|
specific expressions when describing these algorithms, but it also
|
7876 |
|
|
says that other expressions (with different argument order) are
|
7877 |
|
|
equivalent.</li>
|
7878 |
|
|
<li> If we are specifying ordering, note that the standard uses both
|
7879 |
|
|
orderings when describing <tt>equal_range</tt>.</li>
|
7880 |
|
|
<li> Are we talking about requiring these algorithms to work properly
|
7881 |
|
|
when passed a binary function object whose two argument types
|
7882 |
|
|
are not the same, or are we talking about requirements when
|
7883 |
|
|
they are passed a binary function object with several overloaded
|
7884 |
|
|
versions of <tt>operator()</tt>?</li>
|
7885 |
|
|
<li> The definition of a strict weak ordering does not appear to give
|
7886 |
|
|
any guidance on issues of overloading; it only discusses expressions,
|
7887 |
|
|
and all of the values in these expressions are of the same type.
|
7888 |
|
|
Some clarification would seem to be in order.</li>
|
7889 |
|
|
</ul>
|
7890 |
|
|
|
7891 |
|
|
<p><i>Additional discussion from Copenhagen:</i></p>
|
7892 |
|
|
<ul>
|
7893 |
|
|
<li>It was generally agreed that there is a real defect here: if
|
7894 |
|
|
the predicate is merely required to be a Strict Weak Ordering, then
|
7895 |
|
|
it's possible to pass in a function object with an overloaded
|
7896 |
|
|
operator(), where the version that's actually called does something
|
7897 |
|
|
completely inappropriate. (Such as returning a random value.)</li>
|
7898 |
|
|
|
7899 |
|
|
<li>An alternative formulation was presented in a paper distributed by
|
7900 |
|
|
David Abrahams at the meeting, "Binary Search with Heterogeneous
|
7901 |
|
|
Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
|
7902 |
|
|
predicate as a Strict Weak Ordering acting on a sorted sequence, view
|
7903 |
|
|
the predicate/value pair as something that partitions a sequence.
|
7904 |
|
|
This is almost equivalent to saying that we should view binary search
|
7905 |
|
|
as if we are given a unary predicate and a sequence, such that f(*p)
|
7906 |
|
|
is true for all p below a specific point and false for all p above it.
|
7907 |
|
|
The proposed resolution is based on that alternative formulation.</li>
|
7908 |
|
|
</ul>
|
7909 |
|
|
<p><b>Proposed resolution:</b></p>
|
7910 |
|
|
|
7911 |
|
|
<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
|
7912 |
|
|
|
7913 |
|
|
<blockquote>
|
7914 |
|
|
3 For all algorithms that take Compare, there is a version that uses
|
7915 |
|
|
operator< instead. That is, comp(*i, *j) != false defaults to *i <
|
7916 |
|
|
*j != false. For the algorithms to work correctly, comp has to
|
7917 |
|
|
induce a strict weak ordering on the values.
|
7918 |
|
|
</blockquote>
|
7919 |
|
|
|
7920 |
|
|
<p>to:</p>
|
7921 |
|
|
|
7922 |
|
|
<blockquote>
|
7923 |
|
|
3 For all algorithms that take Compare, there is a version that uses
|
7924 |
|
|
operator< instead. That is, comp(*i, *j) != false defaults to *i
|
7925 |
|
|
< *j != false. For algorithms other than those described in
|
7926 |
|
|
lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
|
7927 |
|
|
a strict weak ordering on the values.
|
7928 |
|
|
</blockquote>
|
7929 |
|
|
|
7930 |
|
|
<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
|
7931 |
|
|
|
7932 |
|
|
<blockquote>
|
7933 |
|
|
-6- A sequence [start, finish) is partitioned with respect to an
|
7934 |
|
|
expression f(e) if there exists an integer n such that
|
7935 |
|
|
for all 0 <= i < distance(start, finish), f(*(begin+i)) is true if
|
7936 |
|
|
and only if i < n.
|
7937 |
|
|
</blockquote>
|
7938 |
|
|
|
7939 |
|
|
<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
|
7940 |
|
|
|
7941 |
|
|
<blockquote>
|
7942 |
|
|
-1- All of the algorithms in this section are versions of binary
|
7943 |
|
|
search and assume that the sequence being searched is in order
|
7944 |
|
|
according to the implied or explicit comparison function. They work
|
7945 |
|
|
on non-random access iterators minimizing the number of
|
7946 |
|
|
comparisons, which will be logarithmic for all types of
|
7947 |
|
|
iterators. They are especially appropriate for random access
|
7948 |
|
|
iterators, because these algorithms do a logarithmic number of
|
7949 |
|
|
steps through the data structure. For non-random access iterators
|
7950 |
|
|
they execute a linear number of steps.
|
7951 |
|
|
</blockquote>
|
7952 |
|
|
|
7953 |
|
|
<p>to:</p>
|
7954 |
|
|
|
7955 |
|
|
<blockquote>
|
7956 |
|
|
-1- All of the algorithms in this section are versions of binary
|
7957 |
|
|
search and assume that the sequence being searched is partitioned
|
7958 |
|
|
with respect to an expression formed by binding the search key to
|
7959 |
|
|
an argument of the implied or explicit comparison function. They
|
7960 |
|
|
work on non-random access iterators minimizing the number of
|
7961 |
|
|
comparisons, which will be logarithmic for all types of
|
7962 |
|
|
iterators. They are especially appropriate for random access
|
7963 |
|
|
iterators, because these algorithms do a logarithmic number of
|
7964 |
|
|
steps through the data structure. For non-random access iterators
|
7965 |
|
|
they execute a linear number of steps.
|
7966 |
|
|
</blockquote>
|
7967 |
|
|
|
7968 |
|
|
<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
|
7969 |
|
|
|
7970 |
|
|
<blockquote>
|
7971 |
|
|
-1- Requires: Type T is LessThanComparable
|
7972 |
|
|
(lib.lessthancomparable).
|
7973 |
|
|
</blockquote>
|
7974 |
|
|
|
7975 |
|
|
<p>to:</p>
|
7976 |
|
|
|
7977 |
|
|
<blockquote>
|
7978 |
|
|
-1- Requires: The elements e of [first, last) are partitioned with
|
7979 |
|
|
respect to the expression e < value or comp(e, value)
|
7980 |
|
|
</blockquote>
|
7981 |
|
|
|
7982 |
|
|
|
7983 |
|
|
<p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
|
7984 |
|
|
|
7985 |
|
|
<blockquote>
|
7986 |
|
|
-2- Effects: Finds the first position into which value can be
|
7987 |
|
|
inserted without violating the ordering.
|
7988 |
|
|
</blockquote>
|
7989 |
|
|
|
7990 |
|
|
<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
|
7991 |
|
|
|
7992 |
|
|
<blockquote>
|
7993 |
|
|
-1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
|
7994 |
|
|
</blockquote>
|
7995 |
|
|
|
7996 |
|
|
<p>to:</p>
|
7997 |
|
|
|
7998 |
|
|
<blockquote>
|
7999 |
|
|
-1- Requires: The elements e of [first, last) are partitioned with
|
8000 |
|
|
respect to the expression !(value < e) or !comp(value, e)
|
8001 |
|
|
</blockquote>
|
8002 |
|
|
|
8003 |
|
|
<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
|
8004 |
|
|
|
8005 |
|
|
<blockquote>
|
8006 |
|
|
-2- Effects: Finds the furthermost position into which value can be
|
8007 |
|
|
inserted without violating the ordering.
|
8008 |
|
|
</blockquote>
|
8009 |
|
|
|
8010 |
|
|
<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
|
8011 |
|
|
|
8012 |
|
|
<blockquote>
|
8013 |
|
|
-1- Requires: Type T is LessThanComparable
|
8014 |
|
|
(lib.lessthancomparable).
|
8015 |
|
|
</blockquote>
|
8016 |
|
|
|
8017 |
|
|
<p>to:</p>
|
8018 |
|
|
|
8019 |
|
|
<blockquote>
|
8020 |
|
|
-1- Requires: The elements e of [first, last) are partitioned with
|
8021 |
|
|
respect to the expressions e < value and !(value < e) or
|
8022 |
|
|
comp(e, value) and !comp(value, e). Also, for all elements e of
|
8023 |
|
|
[first, last), e < value implies !(value < e) or comp(e,
|
8024 |
|
|
value) implies !comp(value, e)
|
8025 |
|
|
</blockquote>
|
8026 |
|
|
|
8027 |
|
|
<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
|
8028 |
|
|
|
8029 |
|
|
<blockquote>
|
8030 |
|
|
-2- Effects: Finds the largest subrange [i, j) such that the value
|
8031 |
|
|
can be inserted at any iterator k in it without violating the
|
8032 |
|
|
ordering. k satisfies the corresponding conditions: !(*k < value)
|
8033 |
|
|
&& !(value < *k) or comp(*k, value) == false && comp(value, *k) ==
|
8034 |
|
|
false.
|
8035 |
|
|
</blockquote>
|
8036 |
|
|
|
8037 |
|
|
<p>to:</p>
|
8038 |
|
|
|
8039 |
|
|
<pre> -2- Returns:
|
8040 |
|
|
make_pair(lower_bound(first, last, value),
|
8041 |
|
|
upper_bound(first, last, value))
|
8042 |
|
|
or
|
8043 |
|
|
make_pair(lower_bound(first, last, value, comp),
|
8044 |
|
|
upper_bound(first, last, value, comp))
|
8045 |
|
|
</pre>
|
8046 |
|
|
|
8047 |
|
|
<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
|
8048 |
|
|
|
8049 |
|
|
<blockquote>
|
8050 |
|
|
-1- Requires: Type T is LessThanComparable
|
8051 |
|
|
(lib.lessthancomparable).
|
8052 |
|
|
</blockquote>
|
8053 |
|
|
|
8054 |
|
|
<p>to:</p>
|
8055 |
|
|
|
8056 |
|
|
<blockquote>
|
8057 |
|
|
-1- Requires: The elements e of [first, last) are partitioned with
|
8058 |
|
|
respect to the expressions e < value and !(value < e) or comp(e,
|
8059 |
|
|
value) and !comp(value, e). Also, for all elements e of [first,
|
8060 |
|
|
last), e < value implies !(value < e) or comp(e, value) implies
|
8061 |
|
|
!comp(value, e)
|
8062 |
|
|
</blockquote>
|
8063 |
|
|
|
8064 |
|
|
<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
|
8065 |
|
|
|
8066 |
|
|
<p><i>[Redmond: Minor changes in wording. (Removed "non-negative", and
|
8067 |
|
|
changed the "other than those described in" wording.) Also, the LWG
|
8068 |
|
|
decided to accept the "optional" part.]</i></p>
|
8069 |
|
|
|
8070 |
|
|
<p><b>Rationale:</b></p>
|
8071 |
|
|
<p>The proposed resolution reinterprets binary search. Instead of
|
8072 |
|
|
thinking about searching for a value in a sorted range, we view that
|
8073 |
|
|
as an important special case of a more general algorithm: searching
|
8074 |
|
|
for the partition point in a partitioned range.</p>
|
8075 |
|
|
|
8076 |
|
|
<p>We also add a guarantee that the old wording did not: we ensure
|
8077 |
|
|
that the upper bound is no earlier than the lower bound, that
|
8078 |
|
|
the pair returned by equal_range is a valid range, and that the first
|
8079 |
|
|
part of that pair is the lower bound.</p>
|
8080 |
|
|
<hr>
|
8081 |
|
|
<a name="271"><h3>271. basic_iostream missing typedefs</h3></a><p><b>Section:</b> 27.6.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
|
8082 |
|
|
<p>
|
8083 |
|
|
Class template basic_iostream has no typedefs. The typedefs it
|
8084 |
|
|
inherits from its base classes can't be used, since (for example)
|
8085 |
|
|
basic_iostream<T>::traits_type is ambiguous.
|
8086 |
|
|
</p>
|
8087 |
|
|
<p><b>Proposed resolution:</b></p>
|
8088 |
|
|
|
8089 |
|
|
<p>Add the following to basic_iostream's class synopsis in
|
8090 |
|
|
27.6.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>, immediately after <tt>public</tt>:</p>
|
8091 |
|
|
|
8092 |
|
|
<pre> // types:
|
8093 |
|
|
typedef charT char_type;
|
8094 |
|
|
typedef typename traits::int_type int_type;
|
8095 |
|
|
typedef typename traits::pos_type pos_type;
|
8096 |
|
|
typedef typename traits::off_type off_type;
|
8097 |
|
|
typedef traits traits_type;
|
8098 |
|
|
</pre>
|
8099 |
|
|
<hr>
|
8100 |
|
|
<a name="272"><h3>272. Missing parentheses around subexpression</h3></a><p><b>Section:</b> 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
|
8101 |
|
|
<p>
|
8102 |
|
|
27.4.4.3, p4 says about the postcondition of the function: If
|
8103 |
|
|
rdbuf()!=0 then state == rdstate(); otherwise
|
8104 |
|
|
rdstate()==state|ios_base::badbit.
|
8105 |
|
|
</p>
|
8106 |
|
|
|
8107 |
|
|
<p>
|
8108 |
|
|
The expression on the right-hand-side of the operator==() needs to be
|
8109 |
|
|
parenthesized in order for the whole expression to ever evaluate to
|
8110 |
|
|
anything but non-zero.
|
8111 |
|
|
</p>
|
8112 |
|
|
<p><b>Proposed resolution:</b></p>
|
8113 |
|
|
<p>
|
8114 |
|
|
Add parentheses like so: rdstate()==(state|ios_base::badbit).
|
8115 |
|
|
</p>
|
8116 |
|
|
<hr>
|
8117 |
|
|
<a name="273"><h3>273. Missing ios_base qualification on members of a dependent class</h3></a><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
|
8118 |
|
|
<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
|
8119 |
|
|
27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
|
8120 |
|
|
That's incorrect since the names are members of a dependent base
|
8121 |
|
|
class (14.6.2 [temp.dep]) and thus not visible.</p>
|
8122 |
|
|
<p><b>Proposed resolution:</b></p>
|
8123 |
|
|
<p>Qualify the names with the name of the class of which they are
|
8124 |
|
|
members, i.e., ios_base.</p>
|
8125 |
|
|
<hr>
|
8126 |
|
|
<a name="274"><h3>274. a missing/impossible allocator requirement</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Nov 2000</p>
|
8127 |
|
|
<p>
|
8128 |
|
|
I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of
|
8129 |
|
|
any type. But the synopsis in 20.4.1 calls for allocator<>::address() to
|
8130 |
|
|
be overloaded on reference and const_reference, which is ill-formed for
|
8131 |
|
|
all T = const U. In other words, this won't work:
|
8132 |
|
|
</p>
|
8133 |
|
|
|
8134 |
|
|
<p>
|
8135 |
|
|
template class std::allocator<const int>;
|
8136 |
|
|
</p>
|
8137 |
|
|
|
8138 |
|
|
<p>
|
8139 |
|
|
The obvious solution is to disallow specializations of allocators on
|
8140 |
|
|
const types. However, while containers' elements are required to be
|
8141 |
|
|
assignable (which rules out specializations on const T's), I think that
|
8142 |
|
|
allocators might perhaps be potentially useful for const values in other
|
8143 |
|
|
contexts. So if allocators are to allow const types a partial
|
8144 |
|
|
specialization of std::allocator<const T> would probably have to be
|
8145 |
|
|
provided.
|
8146 |
|
|
</p>
|
8147 |
|
|
<p><b>Proposed resolution:</b></p>
|
8148 |
|
|
<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
|
8149 |
|
|
|
8150 |
|
|
<blockquote>
|
8151 |
|
|
any type
|
8152 |
|
|
</blockquote>
|
8153 |
|
|
|
8154 |
|
|
<p>to</p>
|
8155 |
|
|
<blockquote>
|
8156 |
|
|
any non-const, non-reference type
|
8157 |
|
|
</blockquote>
|
8158 |
|
|
|
8159 |
|
|
<p><i>[Redmond: previous proposed resolution was "any non-const,
|
8160 |
|
|
non-volatile, non-reference type". Got rid of the "non-volatile".]</i></p>
|
8161 |
|
|
|
8162 |
|
|
<p><b>Rationale:</b></p>
|
8163 |
|
|
<p>
|
8164 |
|
|
Two resolutions were originally proposed: one that partially
|
8165 |
|
|
specialized std::allocator for const types, and one that said an
|
8166 |
|
|
allocator's value type may not be const. The LWG chose the second.
|
8167 |
|
|
The first wouldn't be appropriate, because allocators are intended for
|
8168 |
|
|
use by containers, and const value types don't work in containers.
|
8169 |
|
|
Encouraging the use of allocators with const value types would only
|
8170 |
|
|
lead to unsafe code.
|
8171 |
|
|
</p>
|
8172 |
|
|
<p>
|
8173 |
|
|
The original text for proposed resolution 2 was modified so that it
|
8174 |
|
|
also forbids volatile types and reference types.
|
8175 |
|
|
</p>
|
8176 |
|
|
|
8177 |
|
|
<p><i>[Curaçao: LWG double checked and believes volatile is correctly
|
8178 |
|
|
excluded from the PR.]</i></p>
|
8179 |
|
|
|
8180 |
|
|
<hr>
|
8181 |
|
|
<a name="275"><h3>275. Wrong type in num_get::get() overloads</h3></a><p><b>Section:</b> 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 02 Nov 2000</p>
|
8182 |
|
|
<p>
|
8183 |
|
|
In 22.2.2.1.1, we have a list of overloads for num_get<>::get().
|
8184 |
|
|
There are eight overloads, all of which are identical except for the
|
8185 |
|
|
last parameter. The overloads are:
|
8186 |
|
|
</p>
|
8187 |
|
|
<ul>
|
8188 |
|
|
<li> long& </li>
|
8189 |
|
|
<li> unsigned short& </li>
|
8190 |
|
|
<li> unsigned int& </li>
|
8191 |
|
|
<li> unsigned long& </li>
|
8192 |
|
|
<li> short& </li>
|
8193 |
|
|
<li> double& </li>
|
8194 |
|
|
<li> long double& </li>
|
8195 |
|
|
<li> void*& </li>
|
8196 |
|
|
</ul>
|
8197 |
|
|
|
8198 |
|
|
<p>
|
8199 |
|
|
There is a similar list, in 22.2.2.1.2, of overloads for
|
8200 |
|
|
num_get<>::do_get(). In this list, the last parameter has
|
8201 |
|
|
the types:
|
8202 |
|
|
</p>
|
8203 |
|
|
<ul>
|
8204 |
|
|
<li> long& </li>
|
8205 |
|
|
<li> unsigned short& </li>
|
8206 |
|
|
<li> unsigned int& </li>
|
8207 |
|
|
<li> unsigned long& </li>
|
8208 |
|
|
<li> float& </li>
|
8209 |
|
|
<li> double& </li>
|
8210 |
|
|
<li> long double& </li>
|
8211 |
|
|
<li> void*& </li>
|
8212 |
|
|
</ul>
|
8213 |
|
|
|
8214 |
|
|
<p>
|
8215 |
|
|
These two lists are not identical. They should be, since
|
8216 |
|
|
<tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
|
8217 |
|
|
the arguments it was given.
|
8218 |
|
|
</p>
|
8219 |
|
|
<p><b>Proposed resolution:</b></p>
|
8220 |
|
|
<p>In 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, change</p>
|
8221 |
|
|
<pre> iter_type get(iter_type in, iter_type end, ios_base& str,
|
8222 |
|
|
ios_base::iostate& err, short& val) const;
|
8223 |
|
|
</pre>
|
8224 |
|
|
<p>to</p>
|
8225 |
|
|
<pre> iter_type get(iter_type in, iter_type end, ios_base& str,
|
8226 |
|
|
ios_base::iostate& err, float& val) const;
|
8227 |
|
|
</pre>
|
8228 |
|
|
<hr>
|
8229 |
|
|
<a name="276"><h3>276. Assignable requirement for container value type overly strict</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 07 Nov 2000</p>
|
8230 |
|
|
<p>
|
8231 |
|
|
23.1/3 states that the objects stored in a container must be
|
8232 |
|
|
Assignable. 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
|
8233 |
|
|
states that map satisfies all requirements for a container, while in
|
8234 |
|
|
the same time defining value_type as pair<const Key, T> - a type
|
8235 |
|
|
that is not Assignable.
|
8236 |
|
|
</p>
|
8237 |
|
|
|
8238 |
|
|
<p>
|
8239 |
|
|
It should be noted that there exists a valid and non-contradictory
|
8240 |
|
|
interpretation of the current text. The wording in 23.1/3 avoids
|
8241 |
|
|
mentioning value_type, referring instead to "objects stored in a
|
8242 |
|
|
container." One might argue that map does not store objects of
|
8243 |
|
|
type map::value_type, but of map::mapped_type instead, and that the
|
8244 |
|
|
Assignable requirement applies to map::mapped_type, not
|
8245 |
|
|
map::value_type.
|
8246 |
|
|
</p>
|
8247 |
|
|
|
8248 |
|
|
<p>
|
8249 |
|
|
However, this makes map a special case (other containers store objects of
|
8250 |
|
|
type value_type) and the Assignable requirement is needlessly restrictive in
|
8251 |
|
|
general.
|
8252 |
|
|
</p>
|
8253 |
|
|
|
8254 |
|
|
<p>
|
8255 |
|
|
For example, the proposed resolution of active library issue
|
8256 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
|
8257 |
|
|
means that no set operations can exploit the fact that the stored
|
8258 |
|
|
objects are Assignable.
|
8259 |
|
|
</p>
|
8260 |
|
|
|
8261 |
|
|
<p>
|
8262 |
|
|
This is related to, but slightly broader than, closed issue
|
8263 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
|
8264 |
|
|
</p>
|
8265 |
|
|
<p><b>Proposed resolution:</b></p>
|
8266 |
|
|
<p>23.1/3: Strike the trailing part of the sentence:</p>
|
8267 |
|
|
<blockquote>
|
8268 |
|
|
, and the additional requirements of Assignable types from 23.1/3
|
8269 |
|
|
</blockquote>
|
8270 |
|
|
<p>so that it reads:</p>
|
8271 |
|
|
<blockquote>
|
8272 |
|
|
-3- The type of objects stored in these components must meet the
|
8273 |
|
|
requirements of CopyConstructible types (lib.copyconstructible).
|
8274 |
|
|
</blockquote>
|
8275 |
|
|
|
8276 |
|
|
<p>23.1/4: Modify to make clear that this requirement is not for all
|
8277 |
|
|
containers. Change to:</p>
|
8278 |
|
|
|
8279 |
|
|
<blockquote>
|
8280 |
|
|
-4- Table 64 defines the Assignable requirement. Some containers
|
8281 |
|
|
require this property of the types to be stored in the container. T is
|
8282 |
|
|
the type used to instantiate the container. t is a value of T, and u is
|
8283 |
|
|
a value of (possibly const) T.
|
8284 |
|
|
</blockquote>
|
8285 |
|
|
|
8286 |
|
|
<p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
|
8287 |
|
|
CopyConstructible".</p>
|
8288 |
|
|
|
8289 |
|
|
<p>23.2.1/2: Add sentence for Assignable requirement. Change to:</p>
|
8290 |
|
|
|
8291 |
|
|
<blockquote>
|
8292 |
|
|
-2- A deque satisfies all of the requirements of a container and of a
|
8293 |
|
|
reversible container (given in tables in lib.container.requirements) and
|
8294 |
|
|
of a sequence, including the optional sequence requirements
|
8295 |
|
|
(lib.sequence.reqmts). In addition to the requirements on the stored
|
8296 |
|
|
object described in 23.1[lib.container.requirements], the stored object
|
8297 |
|
|
must also meet the requirements of Assignable. Descriptions are
|
8298 |
|
|
provided here only for operations on deque that are not described in one
|
8299 |
|
|
of these tables or for operations where there is additional semantic
|
8300 |
|
|
information.
|
8301 |
|
|
</blockquote>
|
8302 |
|
|
|
8303 |
|
|
<p>23.2.2/2: Add Assignable requirement to specific methods of list.
|
8304 |
|
|
Change to:</p>
|
8305 |
|
|
|
8306 |
|
|
<blockquote>
|
8307 |
|
|
<p>-2- A list satisfies all of the requirements of a container and of a
|
8308 |
|
|
reversible container (given in two tables in lib.container.requirements)
|
8309 |
|
|
and of a sequence, including most of the the optional sequence
|
8310 |
|
|
requirements (lib.sequence.reqmts). The exceptions are the operator[]
|
8311 |
|
|
and at member functions, which are not provided.
|
8312 |
|
|
|
8313 |
|
|
[Footnote: These member functions are only provided by containers whose
|
8314 |
|
|
iterators are random access iterators. --- end foonote]
|
8315 |
|
|
</p>
|
8316 |
|
|
|
8317 |
|
|
<p>list does not require the stored type T to be Assignable unless the
|
8318 |
|
|
following methods are instantiated:
|
8319 |
|
|
|
8320 |
|
|
[Footnote: Implementors are permitted but not required to take advantage
|
8321 |
|
|
of T's Assignable properties for these methods. -- end foonote]
|
8322 |
|
|
</p>
|
8323 |
|
|
<pre> list<T,Allocator>& operator=(const list<T,Allocator>& x );
|
8324 |
|
|
template <class InputIterator>
|
8325 |
|
|
void assign(InputIterator first, InputIterator last);
|
8326 |
|
|
void assign(size_type n, const T& t);
|
8327 |
|
|
</pre>
|
8328 |
|
|
|
8329 |
|
|
|
8330 |
|
|
<p>Descriptions are provided here only for operations on list that are not
|
8331 |
|
|
described in one of these tables or for operations where there is
|
8332 |
|
|
additional semantic information.</p>
|
8333 |
|
|
</blockquote>
|
8334 |
|
|
|
8335 |
|
|
<p>23.2.4/2: Add sentence for Assignable requirement. Change to:</p>
|
8336 |
|
|
|
8337 |
|
|
<blockquote>
|
8338 |
|
|
-2- A vector satisfies all of the requirements of a container and of a
|
8339 |
|
|
reversible container (given in two tables in lib.container.requirements)
|
8340 |
|
|
and of a sequence, including most of the optional sequence requirements
|
8341 |
|
|
(lib.sequence.reqmts). The exceptions are the push_front and pop_front
|
8342 |
|
|
member functions, which are not provided. In addition to the
|
8343 |
|
|
requirements on the stored object described in
|
8344 |
|
|
23.1[lib.container.requirements], the stored object must also meet the
|
8345 |
|
|
requirements of Assignable. Descriptions are provided here only for
|
8346 |
|
|
operations on vector that are not described in one of these tables or
|
8347 |
|
|
for operations where there is additional semantic information.
|
8348 |
|
|
</blockquote>
|
8349 |
|
|
<p><b>Rationale:</b></p>
|
8350 |
|
|
<p>list, set, multiset, map, multimap are able to store non-Assignables.
|
8351 |
|
|
However, there is some concern about <tt>list<T></tt>:
|
8352 |
|
|
although in general there's no reason for T to be Assignable, some
|
8353 |
|
|
implementations of the member functions <tt>operator=</tt> and
|
8354 |
|
|
<tt>assign</tt> do rely on that requirement. The LWG does not want
|
8355 |
|
|
to forbid such implementations.</p>
|
8356 |
|
|
|
8357 |
|
|
<p>Note that the type stored in a standard container must still satisfy
|
8358 |
|
|
the requirements of the container's allocator; this rules out, for
|
8359 |
|
|
example, such types as "const int". See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>
|
8360 |
|
|
for more details.
|
8361 |
|
|
</p>
|
8362 |
|
|
|
8363 |
|
|
<p>In principle we could also relax the "Assignable" requirement for
|
8364 |
|
|
individual <tt>vector</tt> member functions, such as
|
8365 |
|
|
<tt>push_back</tt>. However, the LWG did not see great value in such
|
8366 |
|
|
selective relaxation. Doing so would remove implementors' freedom to
|
8367 |
|
|
implement <tt>vector::push_back</tt> in terms of
|
8368 |
|
|
<tt>vector::insert</tt>.</p>
|
8369 |
|
|
|
8370 |
|
|
<hr>
|
8371 |
|
|
<a name="278"><h3>278. What does iterator validity mean?</h3></a><p><b>Section:</b> 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 27 Nov 2000</p>
|
8372 |
|
|
<p>
|
8373 |
|
|
Section 23.2.2.4 [lib.list.ops] states that
|
8374 |
|
|
</p>
|
8375 |
|
|
<pre> void splice(iterator position, list<T, Allocator>& x);
|
8376 |
|
|
</pre>
|
8377 |
|
|
<p>
|
8378 |
|
|
<i>invalidates</i> all iterators and references to list <tt>x</tt>.
|
8379 |
|
|
</p>
|
8380 |
|
|
|
8381 |
|
|
<p>
|
8382 |
|
|
But what does the C++ Standard mean by "invalidate"? You
|
8383 |
|
|
can still dereference the iterator to a spliced list element, but
|
8384 |
|
|
you'd better not use it to delimit a range within the original
|
8385 |
|
|
list. For the latter operation, it has definitely lost some of its
|
8386 |
|
|
validity.
|
8387 |
|
|
</p>
|
8388 |
|
|
|
8389 |
|
|
<p>
|
8390 |
|
|
If we accept the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>,
|
8391 |
|
|
then we'd better clarify that a "valid" iterator need no
|
8392 |
|
|
longer designate an element within the same container as it once did.
|
8393 |
|
|
We then have to clarify what we mean by invalidating a past-the-end
|
8394 |
|
|
iterator, as when a vector or string grows by reallocation. Clearly,
|
8395 |
|
|
such an iterator has a different kind of validity. Perhaps we should
|
8396 |
|
|
introduce separate terms for the two kinds of "validity."
|
8397 |
|
|
</p>
|
8398 |
|
|
<p><b>Proposed resolution:</b></p>
|
8399 |
|
|
<p>Add the following text to the end of section 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>,
|
8400 |
|
|
after paragraph 5:</p>
|
8401 |
|
|
<blockquote>
|
8402 |
|
|
An <i>invalid</i> iterator is an iterator that may be
|
8403 |
|
|
singular. [Footnote: This definition applies to pointers, since
|
8404 |
|
|
pointers are iterators. The effect of dereferencing an iterator that
|
8405 |
|
|
has been invalidated is undefined.]
|
8406 |
|
|
</blockquote>
|
8407 |
|
|
|
8408 |
|
|
<p><i>[post-Copenhagen: Matt provided wording.]</i></p>
|
8409 |
|
|
|
8410 |
|
|
<p><i>[Redmond: General agreement with the intent, some objections to
|
8411 |
|
|
the wording. Dave provided new wording.]</i></p>
|
8412 |
|
|
<p><b>Rationale:</b></p>
|
8413 |
|
|
<p>This resolution simply defines a term that the Standard uses but
|
8414 |
|
|
never defines, "invalid", in terms of a term that is defined,
|
8415 |
|
|
"singular".</p>
|
8416 |
|
|
|
8417 |
|
|
<p>Why do we say "may be singular", instead of "is singular"? That's
|
8418 |
|
|
becuase a valid iterator is one that is known to be nonsingular.
|
8419 |
|
|
Invalidating an iterator means changing it in such a way that it's
|
8420 |
|
|
no longer known to be nonsingular. An example: inserting an
|
8421 |
|
|
element into the middle of a vector is correctly said to invalidate
|
8422 |
|
|
all iterators pointing into the vector. That doesn't necessarily
|
8423 |
|
|
mean they all become singular.</p>
|
8424 |
|
|
<hr>
|
8425 |
|
|
<a name="280"><h3>280. Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b> 24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Steve Cleary <b>Date:</b> 27 Nov 2000</p>
|
8426 |
|
|
<p>
|
8427 |
|
|
This came from an email from Steve Cleary to Fergus in reference to
|
8428 |
|
|
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
|
8429 |
|
|
this in Toronto and believed it should be a separate issue. There was
|
8430 |
|
|
also some reservations about whether this was a worthwhile problem to
|
8431 |
|
|
fix.
|
8432 |
|
|
</p>
|
8433 |
|
|
|
8434 |
|
|
<p>
|
8435 |
|
|
Steve said: "Fixing reverse_iterator. std::reverse_iterator can
|
8436 |
|
|
(and should) be changed to preserve these additional
|
8437 |
|
|
requirements." He also said in email that it can be done without
|
8438 |
|
|
breaking user's code: "If you take a look at my suggested
|
8439 |
|
|
solution, reverse_iterator doesn't have to take two parameters; there
|
8440 |
|
|
is no danger of breaking existing code, except someone taking the
|
8441 |
|
|
address of one of the reverse_iterator global operator functions, and
|
8442 |
|
|
I have to doubt if anyone has ever done that. . . <i>But</i>, just in
|
8443 |
|
|
case they have, you can leave the old global functions in as well --
|
8444 |
|
|
they won't interfere with the two-template-argument functions. With
|
8445 |
|
|
that, I don't see how <i>any</i> user code could break."
|
8446 |
|
|
</p>
|
8447 |
|
|
<p><b>Proposed resolution:</b></p>
|
8448 |
|
|
<p>
|
8449 |
|
|
<b>Section:</b> 24.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
|
8450 |
|
|
add/change the following declarations:</p>
|
8451 |
|
|
<pre> A) Add a templated assignment operator, after the same manner
|
8452 |
|
|
as the templated copy constructor, i.e.:
|
8453 |
|
|
|
8454 |
|
|
template < class U >
|
8455 |
|
|
reverse_iterator < Iterator >& operator=(const reverse_iterator< U >& u);
|
8456 |
|
|
|
8457 |
|
|
B) Make all global functions (except the operator+) have
|
8458 |
|
|
two template parameters instead of one, that is, for
|
8459 |
|
|
operator ==, !=, <, >, <=, >=, - replace:
|
8460 |
|
|
|
8461 |
|
|
template < class Iterator >
|
8462 |
|
|
typename reverse_iterator< Iterator >::difference_type operator-(
|
8463 |
|
|
const reverse_iterator< Iterator >& x,
|
8464 |
|
|
const reverse_iterator< Iterator >& y);
|
8465 |
|
|
|
8466 |
|
|
with:
|
8467 |
|
|
|
8468 |
|
|
template < class Iterator1, class Iterator2 >
|
8469 |
|
|
typename reverse_iterator < Iterator1 >::difference_type operator-(
|
8470 |
|
|
const reverse_iterator < Iterator1 > & x,
|
8471 |
|
|
const reverse_iterator < Iterator2 > & y);
|
8472 |
|
|
</pre>
|
8473 |
|
|
<p>
|
8474 |
|
|
Also make the addition/changes for these signatures in
|
8475 |
|
|
24.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
|
8476 |
|
|
</p>
|
8477 |
|
|
|
8478 |
|
|
<p><i>[
|
8479 |
|
|
Copenhagen: The LWG is concerned that the proposed resolution
|
8480 |
|
|
introduces new overloads. Experience shows that introducing
|
8481 |
|
|
overloads is always risky, and that it would be inappropriate to
|
8482 |
|
|
make this change without implementation experience. It may be
|
8483 |
|
|
desirable to provide this feature in a different way.
|
8484 |
|
|
]</i></p>
|
8485 |
|
|
|
8486 |
|
|
<p><i>[
|
8487 |
|
|
Lillehammer: We now have implementation experience, and agree that
|
8488 |
|
|
this solution is safe and correct.
|
8489 |
|
|
]</i></p>
|
8490 |
|
|
|
8491 |
|
|
<hr>
|
8492 |
|
|
<a name="281"><h3>281. std::min() and max() requirements overly restrictive</h3></a><p><b>Section:</b> 25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Dec 2000</p>
|
8493 |
|
|
<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
|
8494 |
|
|
requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>)
|
8495 |
|
|
and <tt>CopyConstructible</tt> (20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>).
|
8496 |
|
|
Since the functions take and return their arguments and result by
|
8497 |
|
|
const reference, I believe the <tt>CopyConstructible</tt> requirement
|
8498 |
|
|
is unnecessary.
|
8499 |
|
|
</p>
|
8500 |
|
|
<p><b>Proposed resolution:</b></p>
|
8501 |
|
|
<p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
|
8502 |
|
|
25.3.7, p1 with</p>
|
8503 |
|
|
<p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
|
8504 |
|
|
(20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
|
8505 |
|
|
</p>
|
8506 |
|
|
<p>and replace 25.3.7, p4 with</p>
|
8507 |
|
|
<p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
|
8508 |
|
|
(20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
|
8509 |
|
|
</p>
|
8510 |
|
|
<hr>
|
8511 |
|
|
<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 5 Dec 2000</p>
|
8512 |
|
|
<p>
|
8513 |
|
|
Paragraph 16 mistakenly singles out integral types for inserting
|
8514 |
|
|
thousands_sep() characters. This conflicts with the syntax for floating
|
8515 |
|
|
point numbers described under 22.2.3.1/2.
|
8516 |
|
|
</p>
|
8517 |
|
|
<p><b>Proposed resolution:</b></p>
|
8518 |
|
|
<p>Change paragraph 16 from:</p>
|
8519 |
|
|
|
8520 |
|
|
<blockquote>
|
8521 |
|
|
For integral types, punct.thousands_sep() characters are inserted into
|
8522 |
|
|
the sequence as determined by the value returned by punct.do_grouping()
|
8523 |
|
|
using the method described in 22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
|
8524 |
|
|
</blockquote>
|
8525 |
|
|
|
8526 |
|
|
<p>To:</p>
|
8527 |
|
|
|
8528 |
|
|
<blockquote>
|
8529 |
|
|
For arithmetic types, punct.thousands_sep() characters are inserted into
|
8530 |
|
|
the sequence as determined by the value returned by punct.do_grouping()
|
8531 |
|
|
using the method described in 22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>.
|
8532 |
|
|
</blockquote>
|
8533 |
|
|
|
8534 |
|
|
<p><i>[
|
8535 |
|
|
Copenhagen: Opinions were divided about whether this is actually an
|
8536 |
|
|
inconsistency, but at best it seems to have been unintentional. This
|
8537 |
|
|
is only an issue for floating-point output: The standard is
|
8538 |
|
|
unambiguous that implementations must parse thousands_sep characters
|
8539 |
|
|
when performing floating-point. The standard is also unambiguous that
|
8540 |
|
|
this requirement does not apply to the "C" locale.
|
8541 |
|
|
]</i></p>
|
8542 |
|
|
|
8543 |
|
|
<p><i>[
|
8544 |
|
|
A survey of existing practice is needed; it is believed that some
|
8545 |
|
|
implementations do insert thousands_sep characters for floating-point
|
8546 |
|
|
output and others fail to insert thousands_sep characters for
|
8547 |
|
|
floating-point input even though this is unambiguously required by the
|
8548 |
|
|
standard.
|
8549 |
|
|
]</i></p>
|
8550 |
|
|
|
8551 |
|
|
<p><i>[Post-Curaçao: the above proposed resolution is the consensus of
|
8552 |
|
|
Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
|
8553 |
|
|
|
8554 |
|
|
<hr>
|
8555 |
|
|
<a name="283"><h3>283. std::replace() requirement incorrect/insufficient</h3></a><p><b>Section:</b> 25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Dec 2000</p>
|
8556 |
|
|
<p>
|
8557 |
|
|
(revision of the further discussion)
|
8558 |
|
|
There are a number of problems with the requires clauses for the
|
8559 |
|
|
algorithms in 25.1 and 25.2. The requires clause of each algorithm
|
8560 |
|
|
should describe the necessary and sufficient requirements on the inputs
|
8561 |
|
|
to the algorithm such that the algorithm compiles and runs properly.
|
8562 |
|
|
Many of the requires clauses fail to do this. Here is a summary of the kinds
|
8563 |
|
|
of mistakes:
|
8564 |
|
|
</p>
|
8565 |
|
|
|
8566 |
|
|
<ol>
|
8567 |
|
|
<li>
|
8568 |
|
|
Use of EqualityComparable, which only puts requirements on a single
|
8569 |
|
|
type, when in fact an equality operator is required between two
|
8570 |
|
|
different types, typically either T and the iterator's value type
|
8571 |
|
|
or between the value types of two different iterators.
|
8572 |
|
|
</li>
|
8573 |
|
|
<li>
|
8574 |
|
|
Use of Assignable for T when in fact what was needed is Assignable
|
8575 |
|
|
for the value_type of the iterator, and convertability from T to the
|
8576 |
|
|
value_type of the iterator. Or for output iterators, the requirement
|
8577 |
|
|
should be that T is writable to the iterator (output iterators do
|
8578 |
|
|
not have value types).
|
8579 |
|
|
</li>
|
8580 |
|
|
</ol>
|
8581 |
|
|
|
8582 |
|
|
<p>
|
8583 |
|
|
Here is the list of algorithms that contain mistakes:
|
8584 |
|
|
</p>
|
8585 |
|
|
|
8586 |
|
|
<ul>
|
8587 |
|
|
<li>25.1.2 std::find</li>
|
8588 |
|
|
<li>25.1.6 std::count</li>
|
8589 |
|
|
<li>25.1.8 std::equal</li>
|
8590 |
|
|
<li>25.1.9 std::search, std::search_n</li>
|
8591 |
|
|
<li>25.2.4 std::replace, std::replace_copy</li>
|
8592 |
|
|
<li>25.2.5 std::fill</li>
|
8593 |
|
|
<li>25.2.7 std::remove, std::remove_copy</li>
|
8594 |
|
|
</ul>
|
8595 |
|
|
|
8596 |
|
|
<p>
|
8597 |
|
|
Also, in the requirements for EqualityComparable, the requirement that
|
8598 |
|
|
the operator be defined for const objects is lacking.
|
8599 |
|
|
</p>
|
8600 |
|
|
|
8601 |
|
|
<p><b>Proposed resolution:</b></p>
|
8602 |
|
|
|
8603 |
|
|
<p>20.1.1 Change p1 from</p>
|
8604 |
|
|
|
8605 |
|
|
<p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
|
8606 |
|
|
instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
|
8607 |
|
|
values of type <tt>T</tt>.
|
8608 |
|
|
</p>
|
8609 |
|
|
|
8610 |
|
|
<p>to</p>
|
8611 |
|
|
|
8612 |
|
|
<p>
|
8613 |
|
|
In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
|
8614 |
|
|
instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
|
8615 |
|
|
values of type <tt>const T</tt>.
|
8616 |
|
|
</p>
|
8617 |
|
|
|
8618 |
|
|
<p>25 Between p8 and p9</p>
|
8619 |
|
|
|
8620 |
|
|
<p>Add the following sentence:</p>
|
8621 |
|
|
|
8622 |
|
|
<p>When the description of an algorithm gives an expression such as
|
8623 |
|
|
<tt>*first == value</tt> for a condition, it is required that the expression
|
8624 |
|
|
evaluate to either true or false in boolean contexts.</p>
|
8625 |
|
|
|
8626 |
|
|
<p>25.1.2 Change p1 by deleting the requires clause.</p>
|
8627 |
|
|
|
8628 |
|
|
<p>25.1.6 Change p1 by deleting the requires clause.</p>
|
8629 |
|
|
|
8630 |
|
|
<p>25.1.9</p>
|
8631 |
|
|
|
8632 |
|
|
<p>Change p4 from</p>
|
8633 |
|
|
|
8634 |
|
|
<p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
|
8635 |
|
|
(20.1.1), type Size is convertible to integral type (4.7.12.3).
|
8636 |
|
|
</p>
|
8637 |
|
|
|
8638 |
|
|
<p>to</p>
|
8639 |
|
|
|
8640 |
|
|
<p>-4- Requires: The type <tt>Size</tt> is convertible to integral
|
8641 |
|
|
type (4.7.12.3).</p>
|
8642 |
|
|
|
8643 |
|
|
<p>25.2.4 Change p1 from</p>
|
8644 |
|
|
|
8645 |
|
|
<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1 ) (and, for <tt>replace()</tt>, <tt>EqualityComparable</tt> (20.1.1 )).</p>
|
8646 |
|
|
|
8647 |
|
|
<p>to</p>
|
8648 |
|
|
|
8649 |
|
|
<p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
|
8650 |
|
|
|
8651 |
|
|
<p>and change p4 from</p>
|
8652 |
|
|
|
8653 |
|
|
<p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
|
8654 |
|
|
for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
|
8655 |
|
|
(20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
|
8656 |
|
|
(last - first))</tt> shall not overlap.</p>
|
8657 |
|
|
|
8658 |
|
|
<p>to</p>
|
8659 |
|
|
|
8660 |
|
|
<p>-4- Requires: The results of the expressions <tt>*first</tt> and
|
8661 |
|
|
<tt>new_value</tt> must be writable to the result output iterator. The
|
8662 |
|
|
ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
|
8663 |
|
|
first))</tt> shall not overlap.</p>
|
8664 |
|
|
|
8665 |
|
|
|
8666 |
|
|
<p>25.2.5 Change p1 from</p>
|
8667 |
|
|
|
8668 |
|
|
<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
|
8669 |
|
|
type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
|
8670 |
|
|
|
8671 |
|
|
<p>to</p>
|
8672 |
|
|
|
8673 |
|
|
<p>-1- Requires: The expression <tt>value</tt> must be is writable to
|
8674 |
|
|
the output iterator. The type <tt>Size</tt> is convertible to an
|
8675 |
|
|
integral type (4.7.12.3).</p>
|
8676 |
|
|
|
8677 |
|
|
<p>25.2.7 Change p1 from</p>
|
8678 |
|
|
|
8679 |
|
|
<p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
|
8680 |
|
|
|
8681 |
|
|
<p>to</p>
|
8682 |
|
|
|
8683 |
|
|
<p>
|
8684 |
|
|
-1- Requires: The value type of the iterator must be
|
8685 |
|
|
<tt>Assignable</tt> (23.1).
|
8686 |
|
|
</p>
|
8687 |
|
|
|
8688 |
|
|
<p><b>Rationale:</b></p>
|
8689 |
|
|
<p>
|
8690 |
|
|
The general idea of the proposed solution is to remove the faulty
|
8691 |
|
|
requires clauses and let the returns and effects clauses speak for
|
8692 |
|
|
themselves. That is, the returns clauses contain expressions that must
|
8693 |
|
|
be valid, and therefore already imply the correct requirements. In
|
8694 |
|
|
addition, a sentence is added at the beginning of chapter 25 saying
|
8695 |
|
|
that expressions given as conditions must evaluate to true or false in
|
8696 |
|
|
a boolean context. An alternative would be to say that the type of
|
8697 |
|
|
these condition expressions must be literally bool, but that would be
|
8698 |
|
|
imposing a greater restriction that what the standard currently says
|
8699 |
|
|
(which is convertible to bool).
|
8700 |
|
|
</p>
|
8701 |
|
|
<hr>
|
8702 |
|
|
<a name="284"><h3>284. unportable example in 20.3.7, p6</h3></a><p><b>Section:</b> 20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 26 Dec 2000</p>
|
8703 |
|
|
<p>The example in 20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a>, p6 shows how to use the C
|
8704 |
|
|
library function <tt>strcmp()</tt> with the function pointer adapter
|
8705 |
|
|
<tt>ptr_fun()</tt>. But since it's unspecified whether the C library
|
8706 |
|
|
functions have <tt>extern "C"</tt> or <tt>extern
|
8707 |
|
|
"C++"</tt> linkage [17.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>], and since
|
8708 |
|
|
function pointers with different the language linkage specifications
|
8709 |
|
|
(7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.link"> [dcl.link]</a>) are incompatible, whether this example is
|
8710 |
|
|
well-formed is unspecified.
|
8711 |
|
|
</p>
|
8712 |
|
|
<p><b>Proposed resolution:</b></p>
|
8713 |
|
|
<p>Change 20.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.function.pointer.adaptors"> [lib.function.pointer.adaptors]</a> paragraph 6 from:</p>
|
8714 |
|
|
<blockquote>
|
8715 |
|
|
<p>[<i>Example:</i></p>
|
8716 |
|
|
<pre> replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
|
8717 |
|
|
</pre>
|
8718 |
|
|
<p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
|
8719 |
|
|
</blockquote>
|
8720 |
|
|
|
8721 |
|
|
|
8722 |
|
|
<p>to:</p>
|
8723 |
|
|
<blockquote>
|
8724 |
|
|
<p>[<i>Example:</i></p>
|
8725 |
|
|
<pre> int compare(const char*, const char*);
|
8726 |
|
|
replace_if(v.begin(), v.end(),
|
8727 |
|
|
not1(bind2nd(ptr_fun(compare), "abc")), "def");
|
8728 |
|
|
</pre>
|
8729 |
|
|
<p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
|
8730 |
|
|
</blockquote>
|
8731 |
|
|
|
8732 |
|
|
<p>Also, remove footnote 215 in that same paragraph.</p>
|
8733 |
|
|
|
8734 |
|
|
<p><i>[Copenhagen: Minor change in the proposed resolution. Since this
|
8735 |
|
|
issue deals in part with C and C++ linkage, it was believed to be too
|
8736 |
|
|
confusing for the strings in the example to be "C" and "C++".
|
8737 |
|
|
]</i></p>
|
8738 |
|
|
|
8739 |
|
|
<p><i>[Redmond: More minor changes. Got rid of the footnote (which
|
8740 |
|
|
seems to make a sweeping normative requirement, even though footnotes
|
8741 |
|
|
aren't normative), and changed the sentence after the footnote so that
|
8742 |
|
|
it corresponds to the new code fragment.]</i></p>
|
8743 |
|
|
|
8744 |
|
|
<hr>
|
8745 |
|
|
<a name="285"><h3>285. minor editorial errors in fstream ctors</h3></a><p><b>Section:</b> 27.8.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 31 Dec 2000</p>
|
8746 |
|
|
<p>27.8.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>, p2, 27.8.1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.cons"> [lib.ofstream.cons]</a>, p2, and
|
8747 |
|
|
27.8.1.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, p2 say about the effects of each constructor:
|
8748 |
|
|
</p>
|
8749 |
|
|
|
8750 |
|
|
<p>... If that function returns a null pointer, calls
|
8751 |
|
|
<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
|
8752 |
|
|
</p>
|
8753 |
|
|
|
8754 |
|
|
<p>The parenthetical note doesn't apply since the ctors cannot throw an
|
8755 |
|
|
exception due to the requirement in 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, p3
|
8756 |
|
|
that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
|
8757 |
|
|
</p>
|
8758 |
|
|
<p><b>Proposed resolution:</b></p>
|
8759 |
|
|
<p>
|
8760 |
|
|
Strike the parenthetical note from the Effects clause in each of the
|
8761 |
|
|
paragraphs mentioned above.
|
8762 |
|
|
</p>
|
8763 |
|
|
<hr>
|
8764 |
|
|
<a name="286"><h3>286. <cstdlib> requirements missing size_t typedef</h3></a><p><b>Section:</b> 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p>
|
8765 |
|
|
<p>
|
8766 |
|
|
The <cstdlib> header file contains prototypes for bsearch and
|
8767 |
|
|
qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
|
8768 |
|
|
prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
|
8769 |
|
|
require the typedef size_t. Yet size_t is not listed in the
|
8770 |
|
|
<cstdlib> synopsis table 78 in section 25.4.
|
8771 |
|
|
</p>
|
8772 |
|
|
<p><b>Proposed resolution:</b></p>
|
8773 |
|
|
<p>
|
8774 |
|
|
Add the type size_t to Table 78 (section 25.4) and add
|
8775 |
|
|
the type size_t <cstdlib> to Table 97 (section C.2).
|
8776 |
|
|
</p>
|
8777 |
|
|
<p><b>Rationale:</b></p>
|
8778 |
|
|
<p>Since size_t is in <stdlib.h>, it must also be in <cstdlib>.</p>
|
8779 |
|
|
<hr>
|
8780 |
|
|
<a name="288"><h3>288. <cerrno> requirements missing macro EILSEQ</h3></a><p><b>Section:</b> 19.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p>
|
8781 |
|
|
<p>
|
8782 |
|
|
ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
|
8783 |
|
|
of macros defined in <errno.h> is adjusted to include a new
|
8784 |
|
|
macro, EILSEQ"
|
8785 |
|
|
</p>
|
8786 |
|
|
|
8787 |
|
|
<p>
|
8788 |
|
|
ISO/IEC 14882:1998(E) section 19.3 does not refer
|
8789 |
|
|
to the above amendment.
|
8790 |
|
|
</p>
|
8791 |
|
|
|
8792 |
|
|
<p><b>Proposed resolution:</b></p>
|
8793 |
|
|
<p>
|
8794 |
|
|
Update Table 26 (section 19.3) "Header <cerrno> synopsis"
|
8795 |
|
|
and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
|
8796 |
|
|
</p>
|
8797 |
|
|
<hr>
|
8798 |
|
|
<a name="291"><h3>291. Underspecification of set algorithms</h3></a><p><b>Section:</b> 25.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 03 Jan 2001</p>
|
8799 |
|
|
<p>
|
8800 |
|
|
The standard library contains four algorithms that compute set
|
8801 |
|
|
operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
|
8802 |
|
|
<tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>. Each
|
8803 |
|
|
of these algorithms takes two sorted ranges as inputs, and writes the
|
8804 |
|
|
output of the appropriate set operation to an output range. The elements
|
8805 |
|
|
in the output range are sorted.
|
8806 |
|
|
</p>
|
8807 |
|
|
|
8808 |
|
|
<p>
|
8809 |
|
|
The ordinary mathematical definitions are generalized so that they
|
8810 |
|
|
apply to ranges containing multiple copies of a given element. Two
|
8811 |
|
|
elements are considered to be "the same" if, according to an
|
8812 |
|
|
ordering relation provided by the user, neither one is less than the
|
8813 |
|
|
other. So, for example, if one input range contains five copies of an
|
8814 |
|
|
element and another contains three, the output range of <tt>set_union</tt>
|
8815 |
|
|
will contain five copies, the output range of
|
8816 |
|
|
<tt>set_intersection</tt> will contain three, the output range of
|
8817 |
|
|
<tt>set_difference</tt> will contain two, and the output range of
|
8818 |
|
|
<tt>set_symmetric_difference</tt> will contain two.
|
8819 |
|
|
</p>
|
8820 |
|
|
|
8821 |
|
|
<p>
|
8822 |
|
|
Because two elements can be "the same" for the purposes
|
8823 |
|
|
of these set algorithms, without being identical in other respects
|
8824 |
|
|
(consider, for example, strings under case-insensitive comparison),
|
8825 |
|
|
this raises a number of unanswered questions:
|
8826 |
|
|
</p>
|
8827 |
|
|
|
8828 |
|
|
<ul>
|
8829 |
|
|
<li>If we're copying an element that's present in both of the
|
8830 |
|
|
input ranges, which one do we copy it from?</li>
|
8831 |
|
|
<li>If there are <i>n</i> copies of an element in the relevant
|
8832 |
|
|
input range, and the output range will contain fewer copies (say
|
8833 |
|
|
<i>m</i>) which ones do we choose? The first <i>m</i>, or the last
|
8834 |
|
|
<i>m</i>, or something else?</li>
|
8835 |
|
|
<li>Are these operations stable? That is, does a run of equivalent
|
8836 |
|
|
elements appear in the output range in the same order as as it
|
8837 |
|
|
appeared in the input range(s)?</li>
|
8838 |
|
|
</ul>
|
8839 |
|
|
|
8840 |
|
|
<p>
|
8841 |
|
|
The standard should either answer these questions, or explicitly
|
8842 |
|
|
say that the answers are unspecified. I prefer the former option,
|
8843 |
|
|
since, as far as I know, all existing implementations behave the
|
8844 |
|
|
same way.
|
8845 |
|
|
</p>
|
8846 |
|
|
|
8847 |
|
|
<p><b>Proposed resolution:</b></p>
|
8848 |
|
|
|
8849 |
|
|
<p>Add the following to the end of 25.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.set.union"> [lib.set.union]</a> paragraph 5:</p>
|
8850 |
|
|
<blockquote>
|
8851 |
|
|
If [first1, last1) contains <i>m</i> elements that are equivalent to
|
8852 |
|
|
each other and [first2, last2) contains <i>n</i> elements that are
|
8853 |
|
|
equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
|
8854 |
|
|
will be copied to the output range: all <i>m</i> of these elements
|
8855 |
|
|
from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
|
8856 |
|
|
[first2, last2), in that order.
|
8857 |
|
|
</blockquote>
|
8858 |
|
|
|
8859 |
|
|
<p>Add the following to the end of 25.3.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.set.intersection"> [lib.set.intersection]</a> paragraph 5:</p>
|
8860 |
|
|
<blockquote>
|
8861 |
|
|
If [first1, last1) contains <i>m</i> elements that are equivalent to each
|
8862 |
|
|
other and [first2, last2) contains <i>n</i> elements that are
|
8863 |
|
|
equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
|
8864 |
|
|
elements from [first1, last1) are copied to the output range.
|
8865 |
|
|
</blockquote>
|
8866 |
|
|
|
8867 |
|
|
<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.set.difference"> [lib.set.difference]</a>
|
8868 |
|
|
paragraph 4:</p>
|
8869 |
|
|
<blockquote>
|
8870 |
|
|
If [first1, last1) contains <i>m</i> elements that are equivalent to each
|
8871 |
|
|
other and [first2, last2) contains <i>n</i> elements that are
|
8872 |
|
|
equivalent to them, the last max(<i>m-n</i>, 0) elements from
|
8873 |
|
|
[first1, last1) are copied to the output range.
|
8874 |
|
|
</blockquote>
|
8875 |
|
|
|
8876 |
|
|
<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.set.symmetric.difference"> [lib.set.symmetric.difference]</a>
|
8877 |
|
|
paragraph 4:</p>
|
8878 |
|
|
<blockquote>
|
8879 |
|
|
If [first1, last1) contains <i>m</i> elements that are equivalent to
|
8880 |
|
|
each other and [first2, last2) contains <i>n</i> elements that are
|
8881 |
|
|
equivalent to them, then |<i>m - n</i>| of those elements will be
|
8882 |
|
|
copied to the output range: the last <i>m - n</i> of these elements
|
8883 |
|
|
from [first1, last1) if <i>m</i> > <i>n</i>, and the last <i>n -
|
8884 |
|
|
m</i> of these elements from [first2, last2) if <i>m</i> < <i>n</i>.
|
8885 |
|
|
</blockquote>
|
8886 |
|
|
|
8887 |
|
|
<p><i>[Santa Cruz: it's believed that this language is clearer than
|
8888 |
|
|
what's in the Standard. However, it's also believed that the
|
8889 |
|
|
Standard may already make these guarantees (although not quite in
|
8890 |
|
|
these words). Bill and Howard will check and see whether they think
|
8891 |
|
|
that some or all of these changes may be redundant. If so, we may
|
8892 |
|
|
close this issue as NAD.]</i></p>
|
8893 |
|
|
|
8894 |
|
|
<p><b>Rationale:</b></p>
|
8895 |
|
|
<p>For simple cases, these descriptions are equivalent to what's
|
8896 |
|
|
already in the Standard. For more complicated cases, they describe
|
8897 |
|
|
the behavior of existing implementations.</p>
|
8898 |
|
|
<hr>
|
8899 |
|
|
<a name="292"><h3>292. effects of a.copyfmt (a)</h3></a><p><b>Section:</b> 27.4.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 05 Jan 2001</p>
|
8900 |
|
|
<p>The Effects clause of the member function <tt>copyfmt()</tt> in
|
8901 |
|
|
27.4.4.2, p15 doesn't consider the case where the left-hand side
|
8902 |
|
|
argument is identical to the argument on the right-hand side, that is
|
8903 |
|
|
<tt>(this == &rhs)</tt>. If the two arguments are identical there
|
8904 |
|
|
is no need to copy any of the data members or call any callbacks
|
8905 |
|
|
registered with <tt>register_callback()</tt>. Also, as Howard Hinnant
|
8906 |
|
|
points out in message c++std-lib-8149 it appears to be incorrect to
|
8907 |
|
|
allow the object to fire <tt>erase_event</tt> followed by
|
8908 |
|
|
<tt>copyfmt_event</tt> since the callback handling the latter event
|
8909 |
|
|
may inadvertently attempt to access memory freed by the former.
|
8910 |
|
|
</p>
|
8911 |
|
|
<p><b>Proposed resolution:</b></p>
|
8912 |
|
|
<p>Change the Effects clause in 27.4.4.2, p15 from</p>
|
8913 |
|
|
|
8914 |
|
|
<blockquote>
|
8915 |
|
|
<b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
|
8916 |
|
|
the corresponding member objects of <tt>rhs</tt>, except that...
|
8917 |
|
|
</blockquote>
|
8918 |
|
|
|
8919 |
|
|
<p>to</p>
|
8920 |
|
|
|
8921 |
|
|
<blockquote>
|
8922 |
|
|
<b>-15- Effects:</b>If <tt>(this == &rhs)</tt> does nothing. Otherwise
|
8923 |
|
|
assigns to the member objects of <tt>*this</tt> the corresponding member
|
8924 |
|
|
objects of <tt>rhs</tt>, except that...
|
8925 |
|
|
</blockquote>
|
8926 |
|
|
<hr>
|
8927 |
|
|
<a name="295"><h3>295. Is abs defined in <cmath>?</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Jens Maurer <b>Date:</b> 12 Jan 2001</p>
|
8928 |
|
|
<p>
|
8929 |
|
|
Table 80 lists the contents of the <cmath> header. It does not
|
8930 |
|
|
list <tt>abs()</tt>. However, 26.5, paragraph 6, which lists added
|
8931 |
|
|
signatures present in <cmath>, does say that several overloads
|
8932 |
|
|
of <tt>abs()</tt> should be defined in <cmath>.
|
8933 |
|
|
</p>
|
8934 |
|
|
<p><b>Proposed resolution:</b></p>
|
8935 |
|
|
<p>
|
8936 |
|
|
Add <tt>abs</tt> to Table 80. Also, remove the parenthetical list
|
8937 |
|
|
of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a>,
|
8938 |
|
|
paragraph 1.
|
8939 |
|
|
</p>
|
8940 |
|
|
|
8941 |
|
|
<p><i>[Copenhagen: Modified proposed resolution so that it also gets
|
8942 |
|
|
rid of that vestigial list of functions in paragraph 1.]</i></p>
|
8943 |
|
|
|
8944 |
|
|
<p><b>Rationale:</b></p>
|
8945 |
|
|
<p>All this DR does is fix a typo; it's uncontroversial. A
|
8946 |
|
|
separate question is whether we're doing the right thing in
|
8947 |
|
|
putting some overloads in <cmath> that we aren't also
|
8948 |
|
|
putting in <cstdlib>. That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p>
|
8949 |
|
|
<hr>
|
8950 |
|
|
<a name="297"><h3>297. const_mem_fun_t<>::argument_type should be const T*</h3></a><p><b>Section:</b> 20.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.member.pointer.adaptors"> [lib.member.pointer.adaptors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Jan 2001</p>
|
8951 |
|
|
<p>The class templates <tt>const_mem_fun_t</tt> in 20.3.8, p8 and
|
8952 |
|
|
<tt>const_mem_fun1_t</tt>
|
8953 |
|
|
in 20.3.8, p9 derive from <tt>unary_function<T*, S></tt>, and
|
8954 |
|
|
<tt>binary_function<T*,
|
8955 |
|
|
A, S></tt>, respectively. Consequently, their <tt>argument_type</tt>, and
|
8956 |
|
|
<tt>first_argument_type</tt>
|
8957 |
|
|
members, respectively, are both defined to be <tt>T*</tt> (non-const).
|
8958 |
|
|
However, their function call member operator takes a <tt>const T*</tt>
|
8959 |
|
|
argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
|
8960 |
|
|
T*</tt> instead, so that one can easily refer to it in generic code. The
|
8961 |
|
|
example below derived from existing code fails to compile due to the
|
8962 |
|
|
discrepancy:
|
8963 |
|
|
</p>
|
8964 |
|
|
|
8965 |
|
|
<p><tt>template <class T></tt>
|
8966 |
|
|
<br><tt>void foo (typename T::argument_type arg) // #1</tt>
|
8967 |
|
|
<br><tt>{</tt>
|
8968 |
|
|
<br><tt> typename T::result_type (T::*pf) (typename
|
8969 |
|
|
T::argument_type)
|
8970 |
|
|
const = // #2</tt>
|
8971 |
|
|
<br><tt> &T::operator();</tt>
|
8972 |
|
|
<br><tt>}</tt>
|
8973 |
|
|
</p>
|
8974 |
|
|
|
8975 |
|
|
<p><tt>struct X { /* ... */ };</tt></p>
|
8976 |
|
|
|
8977 |
|
|
<p><tt>int main ()</tt>
|
8978 |
|
|
<br><tt>{</tt>
|
8979 |
|
|
<br><tt> const X x;</tt>
|
8980 |
|
|
<br><tt> foo<std::const_mem_fun_t<void, X>
|
8981 |
|
|
>(&x);
|
8982 |
|
|
// #3</tt>
|
8983 |
|
|
<br><tt>}</tt>
|
8984 |
|
|
</p>
|
8985 |
|
|
|
8986 |
|
|
<p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
|
8987 |
|
|
<br>#2 the type of the pointer is incompatible with the type of the member
|
8988 |
|
|
function
|
8989 |
|
|
<br>#3 the address of a constant being passed to a function taking a non-const
|
8990 |
|
|
<tt>X*</tt>
|
8991 |
|
|
</p>
|
8992 |
|
|
<p><b>Proposed resolution:</b></p>
|
8993 |
|
|
<p>Replace the top portion of the definition of the class template
|
8994 |
|
|
const_mem_fun_t in 20.3.8, p8
|
8995 |
|
|
</p>
|
8996 |
|
|
<p><tt>template <class S, class T> class const_mem_fun_t</tt>
|
8997 |
|
|
<br><tt> : public
|
8998 |
|
|
unary_function<T*, S> {</tt>
|
8999 |
|
|
</p>
|
9000 |
|
|
<p>with</p>
|
9001 |
|
|
<p><tt>template <class S, class T> class const_mem_fun_t</tt>
|
9002 |
|
|
<br><tt> : public
|
9003 |
|
|
unary_function<<b>const</b> T*, S> {</tt>
|
9004 |
|
|
</p>
|
9005 |
|
|
<p>Also replace the top portion of the definition of the class template
|
9006 |
|
|
const_mem_fun1_t in 20.3.8, p9</p>
|
9007 |
|
|
<p><tt>template <class S, class T, class A> class const_mem_fun1_t</tt>
|
9008 |
|
|
<br><tt> : public
|
9009 |
|
|
binary_function<T*, A, S> {</tt>
|
9010 |
|
|
</p>
|
9011 |
|
|
<p>with</p>
|
9012 |
|
|
<p><tt>template <class S, class T, class A> class const_mem_fun1_t</tt>
|
9013 |
|
|
<br><tt> : public
|
9014 |
|
|
binary_function<<b>const</b> T*, A, S> {</tt>
|
9015 |
|
|
</p>
|
9016 |
|
|
<p><b>Rationale:</b></p>
|
9017 |
|
|
<p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
|
9018 |
|
|
and the argument type itself, are not the same.</p>
|
9019 |
|
|
<hr>
|
9020 |
|
|
<a name="298"><h3>298. ::operator delete[] requirement incorrect/insufficient</h3></a><p><b>Section:</b> 18.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> John A. Pedretti <b>Date:</b> 10 Jan 2001</p>
|
9021 |
|
|
<p>
|
9022 |
|
|
The default behavior of <tt>operator delete[]</tt> described in 18.4.1.2, p12 -
|
9023 |
|
|
namely that for non-null value of <i>ptr</i>, the operator reclaims storage
|
9024 |
|
|
allocated by the earlier call to the default <tt>operator new[]</tt> - is not
|
9025 |
|
|
correct in all cases. Since the specified <tt>operator new[]</tt> default
|
9026 |
|
|
behavior is to call <tt>operator new</tt> (18.4.1.2, p4, p8), which can be
|
9027 |
|
|
replaced, along with <tt>operator delete</tt>, by the user, to implement their
|
9028 |
|
|
own memory management, the specified default behavior of<tt> operator
|
9029 |
|
|
delete[]</tt> must be to call <tt>operator delete</tt>.
|
9030 |
|
|
</p>
|
9031 |
|
|
<p><b>Proposed resolution:</b></p>
|
9032 |
|
|
<p>Change 18.4.1.2, p12 from</p>
|
9033 |
|
|
<blockquote>
|
9034 |
|
|
<b>-12-</b> <b>Default behavior:</b>
|
9035 |
|
|
<ul>
|
9036 |
|
|
<li>
|
9037 |
|
|
For a null value of <i><tt>ptr</tt></i> , does nothing.
|
9038 |
|
|
</li>
|
9039 |
|
|
<li>
|
9040 |
|
|
Any other value of <i><tt>ptr</tt></i> shall be a value returned
|
9041 |
|
|
earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
|
9042 |
|
|
[Footnote: The value must not have been invalidated by an intervening
|
9043 |
|
|
call to <tt>operator delete[](void*)</tt> (17.4.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.arguments"> [lib.res.on.arguments]</a>).
|
9044 |
|
|
--- end footnote]
|
9045 |
|
|
For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
|
9046 |
|
|
allocated by the earlier call to the default <tt>operator new[]</tt>.
|
9047 |
|
|
</li>
|
9048 |
|
|
</ul>
|
9049 |
|
|
</blockquote>
|
9050 |
|
|
|
9051 |
|
|
<p>to</p>
|
9052 |
|
|
|
9053 |
|
|
<blockquote>
|
9054 |
|
|
<b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
|
9055 |
|
|
delete(</tt><i>ptr</i>)
|
9056 |
|
|
or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
|
9057 |
|
|
</blockquote>
|
9058 |
|
|
<p>and expunge paragraph 13.</p>
|
9059 |
|
|
<hr>
|
9060 |
|
|
<a name="300"><h3>300. list::merge() specification incomplete</h3></a><p><b>Section:</b> 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> John Pedretti <b>Date:</b> 23 Jan 2001</p>
|
9061 |
|
|
<p>
|
9062 |
|
|
The "Effects" clause for list::merge() (23.2.2.4, p23)
|
9063 |
|
|
appears to be incomplete: it doesn't cover the case where the argument
|
9064 |
|
|
list is identical to *this (i.e., this == &x). The requirement in the
|
9065 |
|
|
note in p24 (below) is that x be empty after the merge which is surely
|
9066 |
|
|
unintended in this case.
|
9067 |
|
|
</p>
|
9068 |
|
|
<p><b>Proposed resolution:</b></p>
|
9069 |
|
|
<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraps 23-25 with:</p>
|
9070 |
|
|
<blockquote>
|
9071 |
|
|
<p>
|
9072 |
|
|
23 Effects: if (&x == this) does nothing; otherwise, merges the two
|
9073 |
|
|
sorted ranges [begin(), end()) and [x.begin(), x.end()). The result
|
9074 |
|
|
is a range in which the elements will be sorted in non-decreasing
|
9075 |
|
|
order according to the ordering defined by comp; that is, for every
|
9076 |
|
|
iterator i in the range other than the first, the condition comp(*i,
|
9077 |
|
|
*(i - 1)) will be false.
|
9078 |
|
|
</p>
|
9079 |
|
|
|
9080 |
|
|
<p>
|
9081 |
|
|
24 Notes: Stable: if (&x != this), then for equivalent elements in the
|
9082 |
|
|
two original ranges, the elements from the original range [begin(),
|
9083 |
|
|
end()) always precede the elements from the original range [x.begin(),
|
9084 |
|
|
x.end()). If (&x != this) the range [x.begin(), x.end()) is empty
|
9085 |
|
|
after the merge.
|
9086 |
|
|
</p>
|
9087 |
|
|
|
9088 |
|
|
<p>
|
9089 |
|
|
25 Complexity: At most size() + x.size() - 1 applications of comp if
|
9090 |
|
|
(&x ! = this); otherwise, no applications of comp are performed. If
|
9091 |
|
|
an exception is thrown other than by a comparison there are no
|
9092 |
|
|
effects.
|
9093 |
|
|
</p>
|
9094 |
|
|
|
9095 |
|
|
</blockquote>
|
9096 |
|
|
|
9097 |
|
|
<p><i>[Copenhagen: The original proposed resolution did not fix all of
|
9098 |
|
|
the problems in 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25. Three different
|
9099 |
|
|
paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
|
9100 |
|
|
Changing p23, without changing the other two, appears to introduce
|
9101 |
|
|
contradictions. Additionally, "merges the argument list into the
|
9102 |
|
|
list" is excessively vague.]</i></p>
|
9103 |
|
|
|
9104 |
|
|
<p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
|
9105 |
|
|
|
9106 |
|
|
<hr>
|
9107 |
|
|
<a name="301"><h3>301. basic_string template ctor effects clause omits allocator argument</h3></a><p><b>Section:</b> 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Jan 2001</p>
|
9108 |
|
|
<p>
|
9109 |
|
|
The effects clause for the basic_string template ctor in 21.3.1, p15
|
9110 |
|
|
leaves out the third argument of type Allocator. I believe this to be
|
9111 |
|
|
a mistake.
|
9112 |
|
|
</p>
|
9113 |
|
|
<p><b>Proposed resolution:</b></p>
|
9114 |
|
|
<p>Replace</p>
|
9115 |
|
|
|
9116 |
|
|
<blockquote>
|
9117 |
|
|
<p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
|
9118 |
|
|
type, equivalent to</p>
|
9119 |
|
|
|
9120 |
|
|
<blockquote><tt>basic_string(static_cast<size_type>(begin),
|
9121 |
|
|
static_cast<value_type>(end))</tt></blockquote>
|
9122 |
|
|
</blockquote>
|
9123 |
|
|
|
9124 |
|
|
<p>with</p>
|
9125 |
|
|
|
9126 |
|
|
<blockquote>
|
9127 |
|
|
<p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
|
9128 |
|
|
type, equivalent to</p>
|
9129 |
|
|
|
9130 |
|
|
<blockquote><tt>basic_string(static_cast<size_type>(begin),
|
9131 |
|
|
static_cast<value_type>(end), <b>a</b>)</tt></blockquote>
|
9132 |
|
|
</blockquote>
|
9133 |
|
|
<hr>
|
9134 |
|
|
<a name="303"><h3>303. Bitset input operator underspecified</h3></a><p><b>Section:</b> 23.3.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.operators"> [lib.bitset.operators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 5 Feb 2001</p>
|
9135 |
|
|
<p>
|
9136 |
|
|
In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
|
9137 |
|
|
"Extracts up to <i>N</i> (single-byte) characters from
|
9138 |
|
|
<i>is</i>.", where <i>is</i> is a stream of type
|
9139 |
|
|
<tt>basic_istream<charT, traits></tt>.
|
9140 |
|
|
</p>
|
9141 |
|
|
|
9142 |
|
|
<p>
|
9143 |
|
|
The standard does not say what it means to extract single byte
|
9144 |
|
|
characters from a stream whose character type, <tt>charT</tt>, is in
|
9145 |
|
|
general not a single-byte character type. Existing implementations
|
9146 |
|
|
differ.
|
9147 |
|
|
</p>
|
9148 |
|
|
|
9149 |
|
|
<p>
|
9150 |
|
|
A reasonable solution will probably involve <tt>widen()</tt> and/or
|
9151 |
|
|
<tt>narrow()</tt>, since they are the supplied mechanism for
|
9152 |
|
|
converting a single character between <tt>char</tt> and
|
9153 |
|
|
arbitrary <tt>charT</tt>.
|
9154 |
|
|
</p>
|
9155 |
|
|
|
9156 |
|
|
<p>Narrowing the input characters is not the same as widening the
|
9157 |
|
|
literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
|
9158 |
|
|
locales in which more than one wide character maps to the narrow
|
9159 |
|
|
character <tt>'0'</tt>. Narrowing means that alternate
|
9160 |
|
|
representations may be used for bitset input, widening means that
|
9161 |
|
|
they may not be.</p>
|
9162 |
|
|
|
9163 |
|
|
<p>Note that for numeric input, <tt>num_get<></tt>
|
9164 |
|
|
(22.2.2.1.2/8) compares input characters to widened version of narrow
|
9165 |
|
|
character literals.</p>
|
9166 |
|
|
|
9167 |
|
|
<p>From Pete Becker, in c++std-lib-8224:</p>
|
9168 |
|
|
<blockquote>
|
9169 |
|
|
<p>
|
9170 |
|
|
Different writing systems can have different representations for the
|
9171 |
|
|
digits that represent 0 and 1. For example, in the Unicode representation
|
9172 |
|
|
of the Devanagari script (used in many of the Indic languages) the digit 0
|
9173 |
|
|
is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
|
9174 |
|
|
into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
|
9175 |
|
|
0x0031 for for the Latin representations of '0' and '1', as well as code
|
9176 |
|
|
points for the same numeric values in several other scripts (Tamil has no
|
9177 |
|
|
character for 0, but does have the digits 1-9), and any of these values
|
9178 |
|
|
would also be narrowed to '0' and '1'.
|
9179 |
|
|
</p>
|
9180 |
|
|
|
9181 |
|
|
<p>...</p>
|
9182 |
|
|
|
9183 |
|
|
<p>
|
9184 |
|
|
It's fairly common to intermix both native and Latin
|
9185 |
|
|
representations of numbers in a document. So I think the rule has to be
|
9186 |
|
|
that if a wide character represents a digit whose value is 0 then the bit
|
9187 |
|
|
should be cleared; if it represents a digit whose value is 1 then the bit
|
9188 |
|
|
should be set; otherwise throw an exception. So in a Devanagari locale,
|
9189 |
|
|
both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
|
9190 |
|
|
would set it. Widen can't do that. It would pick one of those two values,
|
9191 |
|
|
and exclude the other one.
|
9192 |
|
|
</p>
|
9193 |
|
|
|
9194 |
|
|
</blockquote>
|
9195 |
|
|
|
9196 |
|
|
<p>From Jens Maurer, in c++std-lib-8233:</p>
|
9197 |
|
|
|
9198 |
|
|
<blockquote>
|
9199 |
|
|
<p>
|
9200 |
|
|
Whatever we decide, I would find it most surprising if
|
9201 |
|
|
bitset conversion worked differently from int conversion
|
9202 |
|
|
with regard to alternate local representations of
|
9203 |
|
|
numbers.
|
9204 |
|
|
</p>
|
9205 |
|
|
|
9206 |
|
|
<p>Thus, I think the options are:</p>
|
9207 |
|
|
<ul>
|
9208 |
|
|
<li> Have a new defect issue for 22.2.2.1.2/8 so that it will
|
9209 |
|
|
require the use of narrow().</li>
|
9210 |
|
|
|
9211 |
|
|
<li> Have a defect issue for bitset() which describes clearly
|
9212 |
|
|
that widen() is to be used.</li>
|
9213 |
|
|
</ul>
|
9214 |
|
|
</blockquote>
|
9215 |
|
|
<p><b>Proposed resolution:</b></p>
|
9216 |
|
|
|
9217 |
|
|
<p>Replace the first two sentences of paragraph 5 with:</p>
|
9218 |
|
|
|
9219 |
|
|
<blockquote>
|
9220 |
|
|
Extracts up to <i>N</i> characters from <i>is</i>. Stores these
|
9221 |
|
|
characters in a temporary object <i>str</i> of type
|
9222 |
|
|
<tt>basic_string<charT, traits></tt>, then evaluates the
|
9223 |
|
|
expression <tt><i>x</i> = bitset<N>(<i>str</i>)</tt>.
|
9224 |
|
|
</blockquote>
|
9225 |
|
|
|
9226 |
|
|
<p>Replace the third bullet item in paragraph 5 with:</p>
|
9227 |
|
|
<ul><li>
|
9228 |
|
|
the next input character is neither <tt><i>is</i>.widen(0)</tt>
|
9229 |
|
|
nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
|
9230 |
|
|
is not extracted).
|
9231 |
|
|
</li></ul>
|
9232 |
|
|
|
9233 |
|
|
<p><b>Rationale:</b></p>
|
9234 |
|
|
<p>Input for <tt>bitset</tt> should work the same way as numeric
|
9235 |
|
|
input. Using <tt>widen</tt> does mean that alternative digit
|
9236 |
|
|
representations will not be recognized, but this was a known
|
9237 |
|
|
consequence of the design choice.</p>
|
9238 |
|
|
<hr>
|
9239 |
|
|
<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 24 Jan 2001</p>
|
9240 |
|
|
<p>22.2.1.5/3 introduces codecvt in part with:</p>
|
9241 |
|
|
|
9242 |
|
|
<blockquote>
|
9243 |
|
|
codecvt<wchar_t,char,mbstate_t> converts between the native
|
9244 |
|
|
character sets for tiny and wide characters. Instantiations on
|
9245 |
|
|
mbstate_t perform conversion between encodings known to the library
|
9246 |
|
|
implementor.
|
9247 |
|
|
</blockquote>
|
9248 |
|
|
|
9249 |
|
|
<p>But 22.2.1.5.2/10 describes do_length in part with:</p>
|
9250 |
|
|
|
9251 |
|
|
<blockquote>
|
9252 |
|
|
... codecvt<wchar_t, char, mbstate_t> ... return(s) the lesser of max and
|
9253 |
|
|
(from_end-from).
|
9254 |
|
|
</blockquote>
|
9255 |
|
|
|
9256 |
|
|
<p>
|
9257 |
|
|
The semantics of do_in and do_length are linked. What one does must
|
9258 |
|
|
be consistent with what the other does. 22.2.1.5/3 leads me to
|
9259 |
|
|
believe that the vendor is allowed to choose the algorithm that
|
9260 |
|
|
codecvt<wchar_t,char,mbstate_t>::do_in performs so that it makes
|
9261 |
|
|
his customers happy on a given platform. But 22.2.1.5.2/10 explicitly
|
9262 |
|
|
says what codecvt<wchar_t,char,mbstate_t>::do_length must
|
9263 |
|
|
return. And thus indirectly specifies the algorithm that
|
9264 |
|
|
codecvt<wchar_t,char,mbstate_t>::do_in must perform. I believe
|
9265 |
|
|
that this is not what was intended and is a defect.
|
9266 |
|
|
</p>
|
9267 |
|
|
|
9268 |
|
|
<p>Discussion from the -lib reflector:
|
9269 |
|
|
|
9270 |
|
|
<br>This proposal would have the effect of making the semantics of
|
9271 |
|
|
all of the virtual functions in <tt>codecvt<wchar_t, char,
|
9272 |
|
|
mbstate_t></tt> implementation specified. Is that what we want, or
|
9273 |
|
|
do we want to mandate specific behavior for the base class virtuals
|
9274 |
|
|
and leave the implementation specified behavior for the codecvt_byname
|
9275 |
|
|
derived class? The tradeoff is that former allows implementors to
|
9276 |
|
|
write a base class that actually does something useful, while the
|
9277 |
|
|
latter gives users a way to get known and specified---albeit
|
9278 |
|
|
useless---behavior, and is consistent with the way the standard
|
9279 |
|
|
handles other facets. It is not clear what the original intention
|
9280 |
|
|
was.</p>
|
9281 |
|
|
|
9282 |
|
|
<p>
|
9283 |
|
|
Nathan has suggest a compromise: a character that is a widened version
|
9284 |
|
|
of the characters in the basic execution character set must be
|
9285 |
|
|
converted to a one-byte sequence, but there is no such requirement
|
9286 |
|
|
for characters that are not part of the basic execution character set.
|
9287 |
|
|
</p>
|
9288 |
|
|
<p><b>Proposed resolution:</b></p>
|
9289 |
|
|
<p>
|
9290 |
|
|
Change 22.2.1.5.2/5 from:
|
9291 |
|
|
</p>
|
9292 |
|
|
<p>
|
9293 |
|
|
The instantiations required in Table 51 (lib.locale.category), namely
|
9294 |
|
|
codecvt<wchar_t,char,mbstate_t> and
|
9295 |
|
|
codecvt<char,char,mbstate_t>, store no characters. Stores no more
|
9296 |
|
|
than (to_limit-to) destination elements. It always leaves the to_next
|
9297 |
|
|
pointer pointing one beyond the last element successfully stored.
|
9298 |
|
|
</p>
|
9299 |
|
|
<p>
|
9300 |
|
|
to:
|
9301 |
|
|
</p>
|
9302 |
|
|
<p>
|
9303 |
|
|
Stores no more than (to_limit-to) destination elements, and leaves the
|
9304 |
|
|
to_next pointer pointing one beyond the last element successfully
|
9305 |
|
|
stored. codecvt<char,char,mbstate_t> stores no characters.
|
9306 |
|
|
</p>
|
9307 |
|
|
|
9308 |
|
|
<p>Change 22.2.1.5.2/10 from:</p>
|
9309 |
|
|
|
9310 |
|
|
<blockquote>
|
9311 |
|
|
-10- Returns: (from_next-from) where from_next is the largest value in
|
9312 |
|
|
the range [from,from_end] such that the sequence of values in the
|
9313 |
|
|
range [from,from_next) represents max or fewer valid complete
|
9314 |
|
|
characters of type internT. The instantiations required in Table 51
|
9315 |
|
|
(21.1.1.1.1), namely codecvt<wchar_t, char, mbstate_t> and
|
9316 |
|
|
codecvt<char, char, mbstate_t>, return the lesser of max and
|
9317 |
|
|
(from_end-from).
|
9318 |
|
|
</blockquote>
|
9319 |
|
|
|
9320 |
|
|
<p>to:</p>
|
9321 |
|
|
|
9322 |
|
|
<blockquote>
|
9323 |
|
|
-10- Returns: (from_next-from) where from_next is the largest value in
|
9324 |
|
|
the range [from,from_end] such that the sequence of values in the range
|
9325 |
|
|
[from,from_next) represents max or fewer valid complete characters of
|
9326 |
|
|
type internT. The instantiation codecvt<char, char, mbstate_t> returns
|
9327 |
|
|
the lesser of max and (from_end-from).
|
9328 |
|
|
</blockquote>
|
9329 |
|
|
|
9330 |
|
|
<p><i>[Redmond: Nathan suggested an alternative resolution: same as
|
9331 |
|
|
above, but require that, in the default encoding, a character from the
|
9332 |
|
|
basic execution character set would map to a single external
|
9333 |
|
|
character. The straw poll was 8-1 in favor of the proposed
|
9334 |
|
|
resolution.]</i></p>
|
9335 |
|
|
|
9336 |
|
|
<p><b>Rationale:</b></p>
|
9337 |
|
|
<p>The default encoding should be whatever users of a given platform
|
9338 |
|
|
would expect to be the most natural. This varies from platform to
|
9339 |
|
|
platform. In many cases there is a preexisting C library, and users
|
9340 |
|
|
would expect the default encoding to be whatever C uses in the default
|
9341 |
|
|
"C" locale. We could impose a guarantee like the one Nathan suggested
|
9342 |
|
|
(a character from the basic execution character set must map to a
|
9343 |
|
|
single external character), but this would rule out important
|
9344 |
|
|
encodings that are in common use: it would rule out JIS, for
|
9345 |
|
|
example, and it would rule out a fixed-width encoding of UCS-4.</p>
|
9346 |
|
|
|
9347 |
|
|
<p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
|
9348 |
|
|
"shift-JIS" changed to "JIS".]</i></p>
|
9349 |
|
|
|
9350 |
|
|
<hr>
|
9351 |
|
|
<a name="306"><h3>306. offsetof macro and non-POD types</h3></a><p><b>Section:</b> 18.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 21 Feb 2001</p>
|
9352 |
|
|
<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
|
9353 |
|
|
|
9354 |
|
|
<p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
|
9355 |
|
|
accepts a restricted set of <i>type</i> arguments in this
|
9356 |
|
|
International Standard. <i>type</i> shall be a POD structure or a POD
|
9357 |
|
|
union (clause 9). The result of applying the offsetof macro to a field
|
9358 |
|
|
that is a static data member or a function member is
|
9359 |
|
|
undefined."</p>
|
9360 |
|
|
|
9361 |
|
|
<p>For the POD requirement, it doesn't say "no diagnostic
|
9362 |
|
|
required" or "undefined behavior". I read 1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.compliance"> [intro.compliance]</a>, paragraph 1, to mean that a diagnostic is required.
|
9363 |
|
|
It's not clear whether this requirement was intended. While it's
|
9364 |
|
|
possible to provide such a diagnostic, the extra complication doesn't
|
9365 |
|
|
seem to add any value.
|
9366 |
|
|
</p>
|
9367 |
|
|
<p><b>Proposed resolution:</b></p>
|
9368 |
|
|
<p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
|
9369 |
|
|
structure or a POD union the results are undefined."</p>
|
9370 |
|
|
|
9371 |
|
|
<p><i>[Copenhagen: straw poll was 7-4 in favor. It was generally
|
9372 |
|
|
agreed that requiring a diagnostic was inadvertent, but some LWG
|
9373 |
|
|
members thought that diagnostics should be required whenever
|
9374 |
|
|
possible.]</i></p>
|
9375 |
|
|
|
9376 |
|
|
<hr>
|
9377 |
|
|
<a name="307"><h3>307. Lack of reference typedefs in container adaptors</h3></a><p><b>Section:</b> 23.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 13 Mar 2001</p>
|
9378 |
|
|
|
9379 |
|
|
<p>From reflector message c++std-lib-8330. See also lib-8317.</p>
|
9380 |
|
|
|
9381 |
|
|
<p>
|
9382 |
|
|
The standard is currently inconsistent in 23.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>
|
9383 |
|
|
paragraph 1 and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1.
|
9384 |
|
|
23.2.3.3/1, for example, says:
|
9385 |
|
|
</p>
|
9386 |
|
|
|
9387 |
|
|
<blockquote>
|
9388 |
|
|
-1- Any sequence supporting operations back(), push_back() and pop_back()
|
9389 |
|
|
can be used to instantiate stack. In particular, vector (lib.vector), list
|
9390 |
|
|
(lib.list) and deque (lib.deque) can be used.
|
9391 |
|
|
</blockquote>
|
9392 |
|
|
|
9393 |
|
|
<p>But this is false: vector<bool> can not be used, because the
|
9394 |
|
|
container adaptors return a T& rather than using the underlying
|
9395 |
|
|
container's reference type.</p>
|
9396 |
|
|
|
9397 |
|
|
<p>This is a contradiction that can be fixed by:</p>
|
9398 |
|
|
|
9399 |
|
|
<ol>
|
9400 |
|
|
<li>Modifying these paragraphs to say that vector<bool>
|
9401 |
|
|
is an exception.</li>
|
9402 |
|
|
<li>Removing the vector<bool> specialization.</li>
|
9403 |
|
|
<li>Changing the return types of stack and priority_queue to use
|
9404 |
|
|
reference typedef's.</li>
|
9405 |
|
|
</ol>
|
9406 |
|
|
|
9407 |
|
|
<p>
|
9408 |
|
|
I propose 3. This does not preclude option 2 if we choose to do it
|
9409 |
|
|
later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>); the issues are independent. Option
|
9410 |
|
|
3 offers a small step towards support for proxied containers. This
|
9411 |
|
|
small step fixes a current contradiction, is easy for vendors to
|
9412 |
|
|
implement, is already implemented in at least one popular lib, and
|
9413 |
|
|
does not break any code.
|
9414 |
|
|
</p>
|
9415 |
|
|
|
9416 |
|
|
<p><b>Proposed resolution:</b></p>
|
9417 |
|
|
<p>Summary: Add reference and const_reference typedefs to queue,
|
9418 |
|
|
priority_queue and stack. Change return types of "value_type&" to
|
9419 |
|
|
"reference". Change return types of "const value_type&" to
|
9420 |
|
|
"const_reference". Details:</p>
|
9421 |
|
|
|
9422 |
|
|
<p>Change 23.2.3.1/1 from:</p>
|
9423 |
|
|
|
9424 |
|
|
<pre> namespace std {
|
9425 |
|
|
template <class T, class Container = deque<T> >
|
9426 |
|
|
class queue {
|
9427 |
|
|
public:
|
9428 |
|
|
typedef typename Container::value_type value_type;
|
9429 |
|
|
typedef typename Container::size_type size_type;
|
9430 |
|
|
typedef Container container_type;
|
9431 |
|
|
protected:
|
9432 |
|
|
Container c;
|
9433 |
|
|
|
9434 |
|
|
public:
|
9435 |
|
|
explicit queue(const Container& = Container());
|
9436 |
|
|
|
9437 |
|
|
bool empty() const { return c.empty(); }
|
9438 |
|
|
size_type size() const { return c.size(); }
|
9439 |
|
|
value_type& front() { return c.front(); }
|
9440 |
|
|
const value_type& front() const { return c.front(); }
|
9441 |
|
|
value_type& back() { return c.back(); }
|
9442 |
|
|
const value_type& back() const { return c.back(); }
|
9443 |
|
|
void push(const value_type& x) { c.push_back(x); }
|
9444 |
|
|
void pop() { c.pop_front(); }
|
9445 |
|
|
};
|
9446 |
|
|
</pre>
|
9447 |
|
|
|
9448 |
|
|
<p>to:</p>
|
9449 |
|
|
|
9450 |
|
|
<pre> namespace std {
|
9451 |
|
|
template <class T, class Container = deque<T> >
|
9452 |
|
|
class queue {
|
9453 |
|
|
public:
|
9454 |
|
|
typedef typename Container::value_type value_type;
|
9455 |
|
|
typedef typename Container::reference reference;
|
9456 |
|
|
typedef typename Container::const_reference const_reference;
|
9457 |
|
|
typedef typename Container::value_type value_type;
|
9458 |
|
|
typedef typename Container::size_type size_type;
|
9459 |
|
|
typedef Container container_type;
|
9460 |
|
|
protected:
|
9461 |
|
|
Container c;
|
9462 |
|
|
|
9463 |
|
|
public:
|
9464 |
|
|
explicit queue(const Container& = Container());
|
9465 |
|
|
|
9466 |
|
|
bool empty() const { return c.empty(); }
|
9467 |
|
|
size_type size() const { return c.size(); }
|
9468 |
|
|
reference front() { return c.front(); }
|
9469 |
|
|
const_reference front() const { return c.front(); }
|
9470 |
|
|
reference back() { return c.back(); }
|
9471 |
|
|
const_reference back() const { return c.back(); }
|
9472 |
|
|
void push(const value_type& x) { c.push_back(x); }
|
9473 |
|
|
void pop() { c.pop_front(); }
|
9474 |
|
|
};
|
9475 |
|
|
</pre>
|
9476 |
|
|
|
9477 |
|
|
<p>Change 23.2.3.2/1 from:</p>
|
9478 |
|
|
|
9479 |
|
|
<pre> namespace std {
|
9480 |
|
|
template <class T, class Container = vector<T>,
|
9481 |
|
|
class Compare = less<typename Container::value_type> >
|
9482 |
|
|
class priority_queue {
|
9483 |
|
|
public:
|
9484 |
|
|
typedef typename Container::value_type value_type;
|
9485 |
|
|
typedef typename Container::size_type size_type;
|
9486 |
|
|
typedef Container container_type;
|
9487 |
|
|
protected:
|
9488 |
|
|
Container c;
|
9489 |
|
|
Compare comp;
|
9490 |
|
|
|
9491 |
|
|
public:
|
9492 |
|
|
explicit priority_queue(const Compare& x = Compare(),
|
9493 |
|
|
const Container& = Container());
|
9494 |
|
|
template <class InputIterator>
|
9495 |
|
|
priority_queue(InputIterator first, InputIterator last,
|
9496 |
|
|
const Compare& x = Compare(),
|
9497 |
|
|
const Container& = Container());
|
9498 |
|
|
|
9499 |
|
|
bool empty() const { return c.empty(); }
|
9500 |
|
|
size_type size() const { return c.size(); }
|
9501 |
|
|
const value_type& top() const { return c.front(); }
|
9502 |
|
|
void push(const value_type& x);
|
9503 |
|
|
void pop();
|
9504 |
|
|
};
|
9505 |
|
|
// no equality is provided
|
9506 |
|
|
}
|
9507 |
|
|
</pre>
|
9508 |
|
|
|
9509 |
|
|
<p>to:</p>
|
9510 |
|
|
|
9511 |
|
|
<pre> namespace std {
|
9512 |
|
|
template <class T, class Container = vector<T>,
|
9513 |
|
|
class Compare = less<typename Container::value_type> >
|
9514 |
|
|
class priority_queue {
|
9515 |
|
|
public:
|
9516 |
|
|
typedef typename Container::value_type value_type;
|
9517 |
|
|
typedef typename Container::reference reference;
|
9518 |
|
|
typedef typename Container::const_reference const_reference;
|
9519 |
|
|
typedef typename Container::size_type size_type;
|
9520 |
|
|
typedef Container container_type;
|
9521 |
|
|
protected:
|
9522 |
|
|
Container c;
|
9523 |
|
|
Compare comp;
|
9524 |
|
|
|
9525 |
|
|
public:
|
9526 |
|
|
explicit priority_queue(const Compare& x = Compare(),
|
9527 |
|
|
const Container& = Container());
|
9528 |
|
|
template <class InputIterator>
|
9529 |
|
|
priority_queue(InputIterator first, InputIterator last,
|
9530 |
|
|
const Compare& x = Compare(),
|
9531 |
|
|
const Container& = Container());
|
9532 |
|
|
|
9533 |
|
|
bool empty() const { return c.empty(); }
|
9534 |
|
|
size_type size() const { return c.size(); }
|
9535 |
|
|
const_reference top() const { return c.front(); }
|
9536 |
|
|
void push(const value_type& x);
|
9537 |
|
|
void pop();
|
9538 |
|
|
};
|
9539 |
|
|
// no equality is provided
|
9540 |
|
|
}
|
9541 |
|
|
</pre>
|
9542 |
|
|
|
9543 |
|
|
<p>And change 23.2.3.3/1 from:</p>
|
9544 |
|
|
|
9545 |
|
|
<pre> namespace std {
|
9546 |
|
|
template <class T, class Container = deque<T> >
|
9547 |
|
|
class stack {
|
9548 |
|
|
public:
|
9549 |
|
|
typedef typename Container::value_type value_type;
|
9550 |
|
|
typedef typename Container::size_type size_type;
|
9551 |
|
|
typedef Container container_type;
|
9552 |
|
|
protected:
|
9553 |
|
|
Container c;
|
9554 |
|
|
|
9555 |
|
|
public:
|
9556 |
|
|
explicit stack(const Container& = Container());
|
9557 |
|
|
|
9558 |
|
|
bool empty() const { return c.empty(); }
|
9559 |
|
|
size_type size() const { return c.size(); }
|
9560 |
|
|
value_type& top() { return c.back(); }
|
9561 |
|
|
const value_type& top() const { return c.back(); }
|
9562 |
|
|
void push(const value_type& x) { c.push_back(x); }
|
9563 |
|
|
void pop() { c.pop_back(); }
|
9564 |
|
|
};
|
9565 |
|
|
|
9566 |
|
|
template <class T, class Container>
|
9567 |
|
|
bool operator==(const stack<T, Container>& x,
|
9568 |
|
|
const stack<T, Container>& y);
|
9569 |
|
|
template <class T, class Container>
|
9570 |
|
|
bool operator< (const stack<T, Container>& x,
|
9571 |
|
|
const stack<T, Container>& y);
|
9572 |
|
|
template <class T, class Container>
|
9573 |
|
|
bool operator!=(const stack<T, Container>& x,
|
9574 |
|
|
const stack<T, Container>& y);
|
9575 |
|
|
template <class T, class Container>
|
9576 |
|
|
bool operator> (const stack<T, Container>& x,
|
9577 |
|
|
const stack<T, Container>& y);
|
9578 |
|
|
template <class T, class Container>
|
9579 |
|
|
bool operator>=(const stack<T, Container>& x,
|
9580 |
|
|
const stack<T, Container>& y);
|
9581 |
|
|
template <class T, class Container>
|
9582 |
|
|
bool operator<=(const stack<T, Container>& x,
|
9583 |
|
|
const stack<T, Container>& y);
|
9584 |
|
|
}
|
9585 |
|
|
</pre>
|
9586 |
|
|
|
9587 |
|
|
<p>to:</p>
|
9588 |
|
|
|
9589 |
|
|
<pre> namespace std {
|
9590 |
|
|
template <class T, class Container = deque<T> >
|
9591 |
|
|
class stack {
|
9592 |
|
|
public:
|
9593 |
|
|
typedef typename Container::value_type value_type;
|
9594 |
|
|
typedef typename Container::reference reference;
|
9595 |
|
|
typedef typename Container::const_reference const_reference;
|
9596 |
|
|
typedef typename Container::size_type size_type;
|
9597 |
|
|
typedef Container container_type;
|
9598 |
|
|
protected:
|
9599 |
|
|
Container c;
|
9600 |
|
|
|
9601 |
|
|
public:
|
9602 |
|
|
explicit stack(const Container& = Container());
|
9603 |
|
|
|
9604 |
|
|
bool empty() const { return c.empty(); }
|
9605 |
|
|
size_type size() const { return c.size(); }
|
9606 |
|
|
reference top() { return c.back(); }
|
9607 |
|
|
const_reference top() const { return c.back(); }
|
9608 |
|
|
void push(const value_type& x) { c.push_back(x); }
|
9609 |
|
|
void pop() { c.pop_back(); }
|
9610 |
|
|
};
|
9611 |
|
|
|
9612 |
|
|
template <class T, class Container>
|
9613 |
|
|
bool operator==(const stack<T, Container>& x,
|
9614 |
|
|
const stack<T, Container>& y);
|
9615 |
|
|
template <class T, class Container>
|
9616 |
|
|
bool operator< (const stack<T, Container>& x,
|
9617 |
|
|
const stack<T, Container>& y);
|
9618 |
|
|
template <class T, class Container>
|
9619 |
|
|
bool operator!=(const stack<T, Container>& x,
|
9620 |
|
|
const stack<T, Container>& y);
|
9621 |
|
|
template <class T, class Container>
|
9622 |
|
|
bool operator> (const stack<T, Container>& x,
|
9623 |
|
|
const stack<T, Container>& y);
|
9624 |
|
|
template <class T, class Container>
|
9625 |
|
|
bool operator>=(const stack<T, Container>& x,
|
9626 |
|
|
const stack<T, Container>& y);
|
9627 |
|
|
template <class T, class Container>
|
9628 |
|
|
bool operator<=(const stack<T, Container>& x,
|
9629 |
|
|
const stack<T, Container>& y);
|
9630 |
|
|
}
|
9631 |
|
|
</pre>
|
9632 |
|
|
|
9633 |
|
|
<p><i>[Copenhagen: This change was discussed before the IS was released
|
9634 |
|
|
and it was deliberately not adopted. Nevertheless, the LWG believes
|
9635 |
|
|
(straw poll: 10-2) that it is a genuine defect.]</i></p>
|
9636 |
|
|
|
9637 |
|
|
<hr>
|
9638 |
|
|
<a name="308"><h3>308. Table 82 mentions unrelated headers</h3></a><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Mar 2001</p>
|
9639 |
|
|
<p>
|
9640 |
|
|
Table 82 in section 27 mentions the header <cstdlib> for String
|
9641 |
|
|
streams (27.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>) and the headers <cstdio> and
|
9642 |
|
|
<cwchar> for File streams (27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>). It's not clear
|
9643 |
|
|
why these headers are mentioned in this context since they do not
|
9644 |
|
|
define any of the library entities described by the
|
9645 |
|
|
subclauses. According to 17.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.contents"> [lib.contents]</a>, only such headers
|
9646 |
|
|
are to be listed in the summary.
|
9647 |
|
|
</p>
|
9648 |
|
|
<p><b>Proposed resolution:</b></p>
|
9649 |
|
|
<p>Remove <cstdlib> and <cwchar> from
|
9650 |
|
|
Table 82.</p>
|
9651 |
|
|
|
9652 |
|
|
<p><i>[Copenhagen: changed the proposed resolution slightly. The
|
9653 |
|
|
original proposed resolution also said to remove <cstdio> from
|
9654 |
|
|
Table 82. However, <cstdio> is mentioned several times within
|
9655 |
|
|
section 27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>, including 27.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.c.files"> [lib.c.files]</a>.]</i></p>
|
9656 |
|
|
|
9657 |
|
|
<hr>
|
9658 |
|
|
<a name="310"><h3>310. Is errno a macro?</h3></a><p><b>Section:</b> 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 21 Mar 2001</p>
|
9659 |
|
|
<p>
|
9660 |
|
|
Exactly how should errno be declared in a conforming C++ header?
|
9661 |
|
|
</p>
|
9662 |
|
|
|
9663 |
|
|
<p>
|
9664 |
|
|
The C standard says in 7.1.4 that it is unspecified whether errno is a
|
9665 |
|
|
macro or an identifier with external linkage. In some implementations
|
9666 |
|
|
it can be either, depending on compile-time options. (E.g., on
|
9667 |
|
|
Solaris in multi-threading mode, errno is a macro that expands to a
|
9668 |
|
|
function call, but is an extern int otherwise. "Unspecified" allows
|
9669 |
|
|
such variability.)
|
9670 |
|
|
</p>
|
9671 |
|
|
|
9672 |
|
|
<p>The C++ standard:</p>
|
9673 |
|
|
<ul>
|
9674 |
|
|
<li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
|
9675 |
|
|
<li>17.4.3.1.3 footnote 166 says errno is reserved as an external
|
9676 |
|
|
name (true), and implies that it is an identifier.</li>
|
9677 |
|
|
<li>19.3 simply lists errno as a macro (by what reasoning?) and goes
|
9678 |
|
|
on to say that the contents of of C++ <errno.h> are the
|
9679 |
|
|
same as in C, begging the question.</li>
|
9680 |
|
|
<li>C.2, table 95 lists errno as a macro, without comment.</li>
|
9681 |
|
|
</ul>
|
9682 |
|
|
|
9683 |
|
|
<p>I find no other references to errno.</p>
|
9684 |
|
|
|
9685 |
|
|
<p>We should either explicitly say that errno must be a macro, even
|
9686 |
|
|
though it need not be a macro in C, or else explicitly leave it
|
9687 |
|
|
unspecified. We also need to say something about namespace std.
|
9688 |
|
|
A user who includes <cerrno> needs to know whether to write
|
9689 |
|
|
<tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
|
9690 |
|
|
else <cerrno> is useless.</p>
|
9691 |
|
|
|
9692 |
|
|
<p>Two acceptable fixes:</p>
|
9693 |
|
|
<ul>
|
9694 |
|
|
<li><p>errno must be a macro. This is trivially satisfied by adding<br>
|
9695 |
|
|
#define errno (::std::errno)<br>
|
9696 |
|
|
to the headers if errno is not already a macro. You then always
|
9697 |
|
|
write errno without any scope qualification, and it always expands
|
9698 |
|
|
to a correct reference. Since it is always a macro, you know to
|
9699 |
|
|
avoid using errno as a local identifer.</p></li>
|
9700 |
|
|
<li><p>errno is in the global namespace. This fix is inferior, because
|
9701 |
|
|
::errno is not guaranteed to be well-formed.</p></li>
|
9702 |
|
|
</ul>
|
9703 |
|
|
|
9704 |
|
|
<p><i>[
|
9705 |
|
|
This issue was first raised in 1999, but it slipped through
|
9706 |
|
|
the cracks.
|
9707 |
|
|
]</i></p>
|
9708 |
|
|
<p><b>Proposed resolution:</b></p>
|
9709 |
|
|
<p>Change the Note in section 17.4.1.2p5 from</p>
|
9710 |
|
|
|
9711 |
|
|
<blockquote>
|
9712 |
|
|
Note: the names defined as macros in C include the following:
|
9713 |
|
|
assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
|
9714 |
|
|
</blockquote>
|
9715 |
|
|
|
9716 |
|
|
<p>to</p>
|
9717 |
|
|
|
9718 |
|
|
<blockquote>
|
9719 |
|
|
Note: the names defined as macros in C include the following:
|
9720 |
|
|
assert, offsetof, setjmp, va_arg, va_end, and va_start.
|
9721 |
|
|
</blockquote>
|
9722 |
|
|
|
9723 |
|
|
<p>In section 19.3, change paragraph 2 from</p>
|
9724 |
|
|
|
9725 |
|
|
<blockquote>
|
9726 |
|
|
The contents are the same as the Standard C library header
|
9727 |
|
|
<errno.h>.
|
9728 |
|
|
</blockquote>
|
9729 |
|
|
|
9730 |
|
|
<p>to</p>
|
9731 |
|
|
|
9732 |
|
|
<blockquote>
|
9733 |
|
|
The contents are the same as the Standard C library header
|
9734 |
|
|
<errno.h>, except that errno shall be defined as a macro.
|
9735 |
|
|
</blockquote>
|
9736 |
|
|
<p><b>Rationale:</b></p>
|
9737 |
|
|
<p>C++ must not leave it up to the implementation to decide whether or
|
9738 |
|
|
not a name is a macro; it must explicitly specify exactly which names
|
9739 |
|
|
are required to be macros. The only one that really works is for it
|
9740 |
|
|
to be a macro.</p>
|
9741 |
|
|
|
9742 |
|
|
<p><i>[Curaçao: additional rationale added.]</i></p>
|
9743 |
|
|
|
9744 |
|
|
<hr>
|
9745 |
|
|
<a name="311"><h3>311. Incorrect wording in basic_ostream class synopsis</h3></a><p><b>Section:</b> 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 21 Mar 2001</p>
|
9746 |
|
|
|
9747 |
|
|
<p>In 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, the synopsis of class basic_ostream says:</p>
|
9748 |
|
|
|
9749 |
|
|
<pre> // partial specializationss
|
9750 |
|
|
template<class traits>
|
9751 |
|
|
basic_ostream<char,traits>& operator<<( basic_ostream<char,traits>&,
|
9752 |
|
|
const char * );
|
9753 |
|
|
</pre>
|
9754 |
|
|
|
9755 |
|
|
<p>Problems:</p>
|
9756 |
|
|
<ul>
|
9757 |
|
|
<li>Too many 's's at the end of "specializationss" </li>
|
9758 |
|
|
<li>This is an overload, not a partial specialization</li>
|
9759 |
|
|
</ul>
|
9760 |
|
|
|
9761 |
|
|
<p><b>Proposed resolution:</b></p>
|
9762 |
|
|
<p>In the synopsis in 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, remove the
|
9763 |
|
|
<i>// partial specializationss</i> comment. Also remove the same
|
9764 |
|
|
comment (correctly spelled, but still incorrect) from the synopsis in
|
9765 |
|
|
27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>.
|
9766 |
|
|
</p>
|
9767 |
|
|
|
9768 |
|
|
<p><i>[
|
9769 |
|
|
Pre-Redmond: added 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> because of Martin's
|
9770 |
|
|
comment in c++std-lib-8939.
|
9771 |
|
|
]</i></p>
|
9772 |
|
|
|
9773 |
|
|
<hr>
|
9774 |
|
|
<a name="312"><h3>312. Table 27 is missing headers</h3></a><p><b>Section:</b> 20 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.utilities"> [lib.utilities]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 29 Mar 2001</p>
|
9775 |
|
|
<p>Table 27 in section 20 lists the header <memory> (only) for
|
9776 |
|
|
Memory (lib.memory) but neglects to mention the headers
|
9777 |
|
|
<cstdlib> and <cstring> that are discussed in 20.4.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.c.malloc"> [lib.c.malloc]</a>.</p>
|
9778 |
|
|
<p><b>Proposed resolution:</b></p>
|
9779 |
|
|
<p>Add <cstdlib> and <cstring> to Table 27, in the same row
|
9780 |
|
|
as <memory>.</p>
|
9781 |
|
|
<hr>
|
9782 |
|
|
<a name="315"><h3>315. Bad "range" in list::unique complexity</h3></a><p><b>Section:</b> 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1 May 2001</p>
|
9783 |
|
|
<p>
|
9784 |
|
|
23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, Para 21 describes the complexity of
|
9785 |
|
|
list::unique as: "If the range (last - first) is not empty, exactly
|
9786 |
|
|
(last - first) -1 applications of the corresponding predicate,
|
9787 |
|
|
otherwise no applications of the predicate)".
|
9788 |
|
|
</p>
|
9789 |
|
|
|
9790 |
|
|
<p>
|
9791 |
|
|
"(last - first)" is not a range.
|
9792 |
|
|
</p>
|
9793 |
|
|
<p><b>Proposed resolution:</b></p>
|
9794 |
|
|
<p>
|
9795 |
|
|
Change the "range" from (last - first) to [first, last).
|
9796 |
|
|
</p>
|
9797 |
|
|
<hr>
|
9798 |
|
|
<a name="316"><h3>316. Vague text in Table 69</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 4 May 2001</p>
|
9799 |
|
|
<p>Table 69 says this about a_uniq.insert(t):</p>
|
9800 |
|
|
|
9801 |
|
|
<blockquote>
|
9802 |
|
|
inserts t if and only if there is no element in the container with key
|
9803 |
|
|
equivalent to the key of t. The bool component of the returned pair
|
9804 |
|
|
indicates whether the insertion takes place and the iterator component of the
|
9805 |
|
|
pair points to the element with key equivalent to the key of t.
|
9806 |
|
|
</blockquote>
|
9807 |
|
|
|
9808 |
|
|
<p>The description should be more specific about exactly how the bool component
|
9809 |
|
|
indicates whether the insertion takes place.</p>
|
9810 |
|
|
<p><b>Proposed resolution:</b></p>
|
9811 |
|
|
<p>Change the text in question to</p>
|
9812 |
|
|
|
9813 |
|
|
<blockquote>
|
9814 |
|
|
...The bool component of the returned pair is true if and only if the insertion
|
9815 |
|
|
takes place...
|
9816 |
|
|
</blockquote>
|
9817 |
|
|
<hr>
|
9818 |
|
|
<a name="317"><h3>317. Instantiation vs. specialization of facets</h3></a><p><b>Section:</b> 22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 4 May 2001</p>
|
9819 |
|
|
<p>
|
9820 |
|
|
The localization section of the standard refers to specializations of
|
9821 |
|
|
the facet templates as instantiations even though the required facets
|
9822 |
|
|
are typically specialized rather than explicitly (or implicitly)
|
9823 |
|
|
instantiated. In the case of ctype<char> and
|
9824 |
|
|
ctype_byname<char> (and the wchar_t versions), these facets are
|
9825 |
|
|
actually required to be specialized. The terminology should be
|
9826 |
|
|
corrected to make it clear that the standard doesn't mandate explicit
|
9827 |
|
|
instantiation (the term specialization encompasses both explicit
|
9828 |
|
|
instantiations and specializations).
|
9829 |
|
|
</p>
|
9830 |
|
|
<p><b>Proposed resolution:</b></p>
|
9831 |
|
|
<p>
|
9832 |
|
|
In the following paragraphs, replace all occurrences of the word
|
9833 |
|
|
instantiation or instantiations with specialization or specializations,
|
9834 |
|
|
respectively:
|
9835 |
|
|
</p>
|
9836 |
|
|
|
9837 |
|
|
<blockquote>
|
9838 |
|
|
22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
|
9839 |
|
|
22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
|
9840 |
|
|
22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
|
9841 |
|
|
Footnote 242.
|
9842 |
|
|
</blockquote>
|
9843 |
|
|
|
9844 |
|
|
<p>And change the text in 22.1.1.1.1, p4 from</p>
|
9845 |
|
|
|
9846 |
|
|
<blockquote>
|
9847 |
|
|
An implementation is required to provide those instantiations
|
9848 |
|
|
for facet templates identified as members of a category, and
|
9849 |
|
|
for those shown in Table 52:
|
9850 |
|
|
</blockquote>
|
9851 |
|
|
|
9852 |
|
|
<p>to</p>
|
9853 |
|
|
|
9854 |
|
|
<blockquote>
|
9855 |
|
|
An implementation is required to provide those specializations...
|
9856 |
|
|
</blockquote>
|
9857 |
|
|
|
9858 |
|
|
<p><i>[Nathan will review these changes, and will look for places where
|
9859 |
|
|
explicit specialization is necessary.]</i></p>
|
9860 |
|
|
|
9861 |
|
|
<p><b>Rationale:</b></p>
|
9862 |
|
|
<p>This is a simple matter of outdated language. The language to
|
9863 |
|
|
describe templates was clarified during the standardization process,
|
9864 |
|
|
but the wording in clause 22 was never updated to reflect that
|
9865 |
|
|
change.</p>
|
9866 |
|
|
<hr>
|
9867 |
|
|
<a name="318"><h3>318. Misleading comment in definition of numpunct_byname</h3></a><p><b>Section:</b> 22.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 May 2001</p>
|
9868 |
|
|
<p>The definition of the numpunct_byname template contains the following
|
9869 |
|
|
comment:</p>
|
9870 |
|
|
|
9871 |
|
|
<pre> namespace std {
|
9872 |
|
|
template <class charT>
|
9873 |
|
|
class numpunct_byname : public numpunct<charT> {
|
9874 |
|
|
// this class is specialized for char and wchar_t.
|
9875 |
|
|
...
|
9876 |
|
|
</pre>
|
9877 |
|
|
|
9878 |
|
|
<p>There is no documentation of the specializations and it seems
|
9879 |
|
|
conceivable that an implementation will not explicitly specialize the
|
9880 |
|
|
template at all, but simply provide the primary template.</p>
|
9881 |
|
|
<p><b>Proposed resolution:</b></p>
|
9882 |
|
|
<p>Remove the comment from the text in 22.2.3.2 and from the proposed
|
9883 |
|
|
resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
|
9884 |
|
|
<hr>
|
9885 |
|
|
<a name="319"><h3>319. Storage allocation wording confuses "Required behavior", "Requires"</h3></a><p><b>Section:</b> 18.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>, 18.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 15 May 2001</p>
|
9886 |
|
|
<p>The standard specifies 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Required
|
9887 |
|
|
behavior" elements describe "the semantics of a function definition
|
9888 |
|
|
provided by either the implementation or a C++ program."</p>
|
9889 |
|
|
|
9890 |
|
|
<p>The standard specifies 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Requires"
|
9891 |
|
|
elements describe "the preconditions for calling the function."</p>
|
9892 |
|
|
|
9893 |
|
|
<p>In the sections noted below, the current wording specifies
|
9894 |
|
|
"Required Behavior" for what are actually preconditions, and thus
|
9895 |
|
|
should be specified as "Requires".</p>
|
9896 |
|
|
|
9897 |
|
|
<p><b>Proposed resolution:</b></p>
|
9898 |
|
|
|
9899 |
|
|
<p>In 18.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p>
|
9900 |
|
|
<blockquote>
|
9901 |
|
|
<p>Required behavior: accept a value of ptr that is null or that was
|
9902 |
|
|
returned by an earlier call ...</p>
|
9903 |
|
|
</blockquote>
|
9904 |
|
|
<p>to:</p>
|
9905 |
|
|
<blockquote>
|
9906 |
|
|
<p>Requires: the value of ptr is null or the value returned by an
|
9907 |
|
|
earlier call ...</p>
|
9908 |
|
|
</blockquote>
|
9909 |
|
|
|
9910 |
|
|
<p>In 18.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p>
|
9911 |
|
|
<blockquote>
|
9912 |
|
|
<p>Required behavior: accept a value of ptr that is null or that was
|
9913 |
|
|
returned by an earlier call ...</p>
|
9914 |
|
|
</blockquote>
|
9915 |
|
|
<p>to:</p>
|
9916 |
|
|
<blockquote>
|
9917 |
|
|
<p>Requires: the value of ptr is null or the value returned by an
|
9918 |
|
|
earlier call ...</p>
|
9919 |
|
|
</blockquote>
|
9920 |
|
|
|
9921 |
|
|
<hr>
|
9922 |
|
|
<a name="320"><h3>320. list::assign overspecified</h3></a><p><b>Section:</b> 23.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 17 May 2001</p>
|
9923 |
|
|
<p>
|
9924 |
|
|
Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
|
9925 |
|
|
the "effects" of a call to erase followed by a call to insert.
|
9926 |
|
|
</p>
|
9927 |
|
|
|
9928 |
|
|
<p>
|
9929 |
|
|
I would like to document that implementers have the freedom to implement
|
9930 |
|
|
assign by other methods, as long as the end result is the same and the
|
9931 |
|
|
exception guarantee is as good or better than the basic guarantee.
|
9932 |
|
|
</p>
|
9933 |
|
|
|
9934 |
|
|
<p>
|
9935 |
|
|
The motivation for this is to use T's assignment operator to recycle
|
9936 |
|
|
existing nodes in the list instead of erasing them and reallocating
|
9937 |
|
|
them with new values. It is also worth noting that, with careful
|
9938 |
|
|
coding, most common cases of assign (everything but assignment with
|
9939 |
|
|
true input iterators) can elevate the exception safety to strong if
|
9940 |
|
|
T's assignment has a nothrow guarantee (with no extra memory cost).
|
9941 |
|
|
Metrowerks does this. However I do not propose that this subtlety be
|
9942 |
|
|
standardized. It is a QoI issue. </p>
|
9943 |
|
|
|
9944 |
|
|
<p>Existing practise:
|
9945 |
|
|
Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
|
9946 |
|
|
</p>
|
9947 |
|
|
<p><b>Proposed resolution:</b></p>
|
9948 |
|
|
<p>Change 23.2.2.1/7 from:</p>
|
9949 |
|
|
|
9950 |
|
|
<blockquote>
|
9951 |
|
|
<p>Effects:</p>
|
9952 |
|
|
|
9953 |
|
|
<pre> erase(begin(), end());
|
9954 |
|
|
insert(begin(), first, last);
|
9955 |
|
|
</pre>
|
9956 |
|
|
</blockquote>
|
9957 |
|
|
|
9958 |
|
|
<p>to:</p>
|
9959 |
|
|
|
9960 |
|
|
<blockquote>
|
9961 |
|
|
<p>Effects: Replaces the contents of the list with the range [first, last).</p>
|
9962 |
|
|
</blockquote>
|
9963 |
|
|
|
9964 |
|
|
<p>In 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, in Table 67 (sequence requirements),
|
9965 |
|
|
add two new rows:</p>
|
9966 |
|
|
<pre> a.assign(i,j) void pre: i,j are not iterators into a.
|
9967 |
|
|
Replaces elements in a with a copy
|
9968 |
|
|
of [i, j).
|
9969 |
|
|
|
9970 |
|
|
a.assign(n,t) void pre: t is not a reference into a.
|
9971 |
|
|
Replaces elements in a with n copies
|
9972 |
|
|
of t.
|
9973 |
|
|
</pre>
|
9974 |
|
|
|
9975 |
|
|
<p>Change 23.2.2.1/8 from:</p>
|
9976 |
|
|
|
9977 |
|
|
<blockquote>
|
9978 |
|
|
<p>Effects:</p>
|
9979 |
|
|
<pre> erase(begin(), end());
|
9980 |
|
|
insert(begin(), n, t);
|
9981 |
|
|
</pre>
|
9982 |
|
|
</blockquote>
|
9983 |
|
|
<p>to:</p>
|
9984 |
|
|
|
9985 |
|
|
<blockquote>
|
9986 |
|
|
<p>Effects: Replaces the contents of the list with n copies of t.</p>
|
9987 |
|
|
</blockquote>
|
9988 |
|
|
|
9989 |
|
|
<p><i>[Redmond: Proposed resolution was changed slightly. Previous
|
9990 |
|
|
version made explicit statement about exception safety, which wasn't
|
9991 |
|
|
consistent with the way exception safety is expressed elsewhere.
|
9992 |
|
|
Also, the change in the sequence requirements is new. Without that
|
9993 |
|
|
change, the proposed resolution would have required that assignment of
|
9994 |
|
|
a subrange would have to work. That too would have been
|
9995 |
|
|
overspecification; it would effectively mandate that assignment use a
|
9996 |
|
|
temporary. Howard provided wording.
|
9997 |
|
|
]</i></p>
|
9998 |
|
|
|
9999 |
|
|
<p><i>[Curaçao: Made editorial improvement in wording; changed
|
10000 |
|
|
"Replaces elements in a with copies of elements in [i, j)."
|
10001 |
|
|
with "Replaces the elements of a with a copy of [i, j)."
|
10002 |
|
|
Changes not deemed serious enough to requre rereview.]</i></p>
|
10003 |
|
|
|
10004 |
|
|
<hr>
|
10005 |
|
|
<a name="321"><h3>321. Typo in num_get</h3></a><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Kevin Djang <b>Date:</b> 17 May 2001</p>
|
10006 |
|
|
<p>
|
10007 |
|
|
Section 22.2.2.1.2 at p7 states that "A length specifier is added to
|
10008 |
|
|
the conversion function, if needed, as indicated in Table 56."
|
10009 |
|
|
However, Table 56 uses the term "length modifier", not "length
|
10010 |
|
|
specifier".
|
10011 |
|
|
</p>
|
10012 |
|
|
<p><b>Proposed resolution:</b></p>
|
10013 |
|
|
<p>
|
10014 |
|
|
In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
|
10015 |
|
|
to be "A length modifier is added ..."
|
10016 |
|
|
</p>
|
10017 |
|
|
<p><b>Rationale:</b></p>
|
10018 |
|
|
<p>C uses the term "length modifier". We should be consistent.</p>
|
10019 |
|
|
<hr>
|
10020 |
|
|
<a name="322"><h3>322. iterator and const_iterator should have the same value type</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 17 May 2001</p>
|
10021 |
|
|
<p>
|
10022 |
|
|
It's widely assumed that, if X is a container,
|
10023 |
|
|
iterator_traits<X::iterator>::value_type and
|
10024 |
|
|
iterator_traits<X::const_iterator>::value_type should both be
|
10025 |
|
|
X::value_type. However, this is nowhere stated. The language in
|
10026 |
|
|
Table 65 is not precise about the iterators' value types (it predates
|
10027 |
|
|
iterator_traits), and could even be interpreted as saying that
|
10028 |
|
|
iterator_traits<X::const_iterator>::value_type should be "const
|
10029 |
|
|
X::value_type".
|
10030 |
|
|
</p>
|
10031 |
|
|
|
10032 |
|
|
<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
|
10033 |
|
|
<p><b>Proposed resolution:</b></p>
|
10034 |
|
|
<p>In Table 65 ("Container Requirements"), change the return type for
|
10035 |
|
|
X::iterator to "iterator type whose value type is T". Change the
|
10036 |
|
|
return type for X::const_iterator to "constant iterator type whose
|
10037 |
|
|
value type is T".</p>
|
10038 |
|
|
<p><b>Rationale:</b></p>
|
10039 |
|
|
<p>
|
10040 |
|
|
This belongs as a container requirement, rather than an iterator
|
10041 |
|
|
requirement, because the whole notion of iterator/const_iterator
|
10042 |
|
|
pairs is specific to containers' iterator.
|
10043 |
|
|
</p>
|
10044 |
|
|
<p>
|
10045 |
|
|
It is existing practice that (for example)
|
10046 |
|
|
iterator_traits<list<int>::const_iterator>::value_type
|
10047 |
|
|
is "int", rather than "const int". This is consistent with
|
10048 |
|
|
the way that const pointers are handled: the standard already
|
10049 |
|
|
requires that iterator_traits<const int*>::value_type is int.
|
10050 |
|
|
</p>
|
10051 |
|
|
<hr>
|
10052 |
|
|
<a name="324"><h3>324. Do output iterators have value types?</h3></a><p><b>Section:</b> 24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 7 June 2001</p>
|
10053 |
|
|
|
10054 |
|
|
<p>Table 73 suggests that output iterators have value types. It
|
10055 |
|
|
requires the expression "*a = t". Additionally, although Table 73
|
10056 |
|
|
never lists "a = t" or "X(a) = t" in the "expressions" column, it
|
10057 |
|
|
contains a note saying that "a = t" and "X(a) = t" have equivalent
|
10058 |
|
|
(but nowhere specified!) semantics.</p>
|
10059 |
|
|
|
10060 |
|
|
<p>According to 24.1/9, t is supposed to be "a value of value type
|
10061 |
|
|
T":</p>
|
10062 |
|
|
|
10063 |
|
|
<blockquote>
|
10064 |
|
|
In the following sections, a and b denote values of X, n denotes a
|
10065 |
|
|
value of the difference type Distance, u, tmp, and m denote
|
10066 |
|
|
identifiers, r denotes a value of X&, t denotes a value of
|
10067 |
|
|
value type T.
|
10068 |
|
|
</blockquote>
|
10069 |
|
|
|
10070 |
|
|
<p>Two other parts of the standard that are relevant to whether
|
10071 |
|
|
output iterators have value types:</p>
|
10072 |
|
|
|
10073 |
|
|
<ul>
|
10074 |
|
|
<li>24.1/1 says "All iterators i support the expression *i,
|
10075 |
|
|
resulting in a value of some class, enumeration, or built-in type
|
10076 |
|
|
T, called the value type of the iterator".</li>
|
10077 |
|
|
|
10078 |
|
|
<li>
|
10079 |
|
|
24.3.1/1, which says "In the case of an output iterator, the types
|
10080 |
|
|
iterator_traits<Iterator>::difference_type
|
10081 |
|
|
iterator_traits<Iterator>::value_type are both defined as void."
|
10082 |
|
|
</li>
|
10083 |
|
|
</ul>
|
10084 |
|
|
|
10085 |
|
|
<p>The first of these passages suggests that "*i" is supposed to
|
10086 |
|
|
return a useful value, which contradicts the note in 24.1.2/2 saying
|
10087 |
|
|
that the only valid use of "*i" for output iterators is in an
|
10088 |
|
|
expression of the form "*i = t". The second of these passages appears
|
10089 |
|
|
to contradict Table 73, because it suggests that "*i"'s return value
|
10090 |
|
|
should be void. The second passage is also broken in the case of a an
|
10091 |
|
|
iterator type, like non-const pointers, that satisfies both the output
|
10092 |
|
|
iterator requirements and the forward iterator requirements.</p>
|
10093 |
|
|
|
10094 |
|
|
<p>What should the standard say about <tt>*i</tt>'s return value when
|
10095 |
|
|
i is an output iterator, and what should it say about that t is in the
|
10096 |
|
|
expression "*i = t"? Finally, should the standard say anything about
|
10097 |
|
|
output iterators' pointer and reference types?</p>
|
10098 |
|
|
|
10099 |
|
|
<p><b>Proposed resolution:</b></p>
|
10100 |
|
|
<p>24.1 p1, change</p>
|
10101 |
|
|
|
10102 |
|
|
<blockquote>
|
10103 |
|
|
<p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
|
10104 |
|
|
in a value of some class, enumeration, or built-in type <tt>T</tt>,
|
10105 |
|
|
called the value type of the iterator.</p>
|
10106 |
|
|
</blockquote>
|
10107 |
|
|
|
10108 |
|
|
<p>to</p>
|
10109 |
|
|
|
10110 |
|
|
<blockquote>
|
10111 |
|
|
<p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
|
10112 |
|
|
resulting in a value of some class, enumeration, or built-in type
|
10113 |
|
|
<tt>T</tt>, called the value type of the iterator. All output
|
10114 |
|
|
iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
|
10115 |
|
|
value of some type that is in the set of types that are <i>writable</i> to
|
10116 |
|
|
the particular iterator type of <tt>i</tt>.
|
10117 |
|
|
</p>
|
10118 |
|
|
</blockquote>
|
10119 |
|
|
|
10120 |
|
|
<p>24.1 p9, add</p>
|
10121 |
|
|
|
10122 |
|
|
<blockquote>
|
10123 |
|
|
<p><tt>o</tt> denotes a value of some type that is writable to the
|
10124 |
|
|
output iterator.
|
10125 |
|
|
</p>
|
10126 |
|
|
</blockquote>
|
10127 |
|
|
|
10128 |
|
|
<p>Table 73, change</p>
|
10129 |
|
|
|
10130 |
|
|
<blockquote>
|
10131 |
|
|
<pre>*a = t
|
10132 |
|
|
</pre>
|
10133 |
|
|
</blockquote>
|
10134 |
|
|
|
10135 |
|
|
<p>to</p>
|
10136 |
|
|
|
10137 |
|
|
<blockquote>
|
10138 |
|
|
<pre>*r = o
|
10139 |
|
|
</pre>
|
10140 |
|
|
</blockquote>
|
10141 |
|
|
|
10142 |
|
|
<p>and change</p>
|
10143 |
|
|
|
10144 |
|
|
<blockquote>
|
10145 |
|
|
<pre>*r++ = t
|
10146 |
|
|
</pre>
|
10147 |
|
|
</blockquote>
|
10148 |
|
|
|
10149 |
|
|
<p>to</p>
|
10150 |
|
|
|
10151 |
|
|
<blockquote>
|
10152 |
|
|
<pre>*r++ = o
|
10153 |
|
|
</pre>
|
10154 |
|
|
</blockquote>
|
10155 |
|
|
|
10156 |
|
|
<p><i>[post-Redmond: Jeremy provided wording]</i></p>
|
10157 |
|
|
|
10158 |
|
|
<p><b>Rationale:</b></p>
|
10159 |
|
|
<p>The LWG considered two options: change all of the language that
|
10160 |
|
|
seems to imply that output iterators have value types, thus making it
|
10161 |
|
|
clear that output iterators have no value types, or else define value
|
10162 |
|
|
types for output iterator consistently. The LWG chose the former
|
10163 |
|
|
option, because it seems clear that output iterators were never
|
10164 |
|
|
intended to have value types. This was a deliberate design decision,
|
10165 |
|
|
and any language suggesting otherwise is simply a mistake.</p>
|
10166 |
|
|
|
10167 |
|
|
<p>A future revision of the standard may wish to revisit this design
|
10168 |
|
|
decision.</p>
|
10169 |
|
|
<hr>
|
10170 |
|
|
<a name="325"><h3>325. Misleading text in moneypunct<>::do_grouping</h3></a><p><b>Section:</b> 22.2.6.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Jul 2001</p>
|
10171 |
|
|
<p>The Returns clause in 22.2.6.3.2, p3 says about
|
10172 |
|
|
moneypunct<charT>::do_grouping()
|
10173 |
|
|
</p>
|
10174 |
|
|
|
10175 |
|
|
<blockquote>
|
10176 |
|
|
Returns: A pattern defined identically as the result of
|
10177 |
|
|
numpunct<charT>::do_grouping().241)
|
10178 |
|
|
</blockquote>
|
10179 |
|
|
|
10180 |
|
|
<p>Footnote 241 then reads</p>
|
10181 |
|
|
|
10182 |
|
|
<blockquote>
|
10183 |
|
|
This is most commonly the value "\003" (not "3").
|
10184 |
|
|
</blockquote>
|
10185 |
|
|
|
10186 |
|
|
<p>
|
10187 |
|
|
The returns clause seems to imply that the two member functions must
|
10188 |
|
|
return an identical value which in reality may or may not be true,
|
10189 |
|
|
since the facets are usually implemented in terms of struct std::lconv
|
10190 |
|
|
and return the value of the grouping and mon_grouping, respectively.
|
10191 |
|
|
The footnote also implies that the member function of the moneypunct
|
10192 |
|
|
facet (rather than the overridden virtual functions in moneypunct_byname)
|
10193 |
|
|
most commonly return "\003", which contradicts the C standard which
|
10194 |
|
|
specifies the value of "" for the (most common) C locale.
|
10195 |
|
|
</p>
|
10196 |
|
|
|
10197 |
|
|
<p><b>Proposed resolution:</b></p>
|
10198 |
|
|
<p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
|
10199 |
|
|
|
10200 |
|
|
<blockquote>
|
10201 |
|
|
Returns: A pattern defined identically as, but not necessarily
|
10202 |
|
|
equal to, the result of numpunct<charT>::do_grouping().241)
|
10203 |
|
|
</blockquote>
|
10204 |
|
|
|
10205 |
|
|
<p>and replace the text in Footnote 241 with the following:</p>
|
10206 |
|
|
|
10207 |
|
|
<blockquote>
|
10208 |
|
|
To specify grouping by 3s the value is "\003", not "3".
|
10209 |
|
|
</blockquote>
|
10210 |
|
|
<p><b>Rationale:</b></p>
|
10211 |
|
|
<p>
|
10212 |
|
|
The fundamental problem is that the description of the locale facet
|
10213 |
|
|
virtuals serves two purposes: describing the behavior of the base
|
10214 |
|
|
class, and describing the meaning of and constraints on the behavior
|
10215 |
|
|
in arbitrary derived classes. The new wording makes that separation a
|
10216 |
|
|
little bit clearer. The footnote (which is nonnormative) is not
|
10217 |
|
|
supposed to say what the grouping is in the "C" locale or in any other
|
10218 |
|
|
locale. It is just a reminder that the values are interpreted as small
|
10219 |
|
|
integers, not ASCII characters.
|
10220 |
|
|
</p>
|
10221 |
|
|
<hr>
|
10222 |
|
|
<a name="327"><h3>327. Typo in time_get facet in table 52</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Tiki Wan <b>Date:</b> 06 Jul 2001</p>
|
10223 |
|
|
<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
|
10224 |
|
|
<tt>time_get_byname</tt> are listed incorrectly in table 52,
|
10225 |
|
|
required instantiations. In both cases the second template
|
10226 |
|
|
parameter is given as OutputIterator. It should instead be
|
10227 |
|
|
InputIterator, since these are input facets.</p>
|
10228 |
|
|
<p><b>Proposed resolution:</b></p>
|
10229 |
|
|
<p>
|
10230 |
|
|
In table 52, required instantiations, in
|
10231 |
|
|
22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, change</p>
|
10232 |
|
|
<pre> time_get<wchar_t, OutputIterator>
|
10233 |
|
|
time_get_byname<wchar_t, OutputIterator>
|
10234 |
|
|
</pre>
|
10235 |
|
|
<p>to</p>
|
10236 |
|
|
<pre> time_get<wchar_t, InputIterator>
|
10237 |
|
|
time_get_byname<wchar_t, InputIterator>
|
10238 |
|
|
</pre>
|
10239 |
|
|
|
10240 |
|
|
<p><i>[Redmond: Very minor change in proposed resolution. Original had
|
10241 |
|
|
a typo, wchart instead of wchar_t.]</i></p>
|
10242 |
|
|
|
10243 |
|
|
<hr>
|
10244 |
|
|
<a name="328"><h3>328. Bad sprintf format modifier in money_put<>::do_put()</h3></a><p><b>Section:</b> 22.2.6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.money.put.virtuals"> [lib.locale.money.put.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 07 Jul 2001</p>
|
10245 |
|
|
<p>The sprintf format string , "%.01f" (that's the digit one), in the
|
10246 |
|
|
description of the do_put() member functions of the money_put facet in
|
10247 |
|
|
22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
|
10248 |
|
|
for values of type long double, and second, the precision of 01
|
10249 |
|
|
doesn't seem to make sense. What was most likely intended was
|
10250 |
|
|
"%.0Lf"., that is a precision of zero followed by the L length
|
10251 |
|
|
modifier.</p>
|
10252 |
|
|
<p><b>Proposed resolution:</b></p>
|
10253 |
|
|
<p>Change the format string to "%.0Lf".</p>
|
10254 |
|
|
<p><b>Rationale:</b></p>
|
10255 |
|
|
<p>Fixes an obvious typo</p>
|
10256 |
|
|
<hr>
|
10257 |
|
|
<a name="329"><h3>329. vector capacity, reserve and reallocation</h3></a><p><b>Section:</b> 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>, 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 13 Jul 2001</p>
|
10258 |
|
|
<p>
|
10259 |
|
|
There is an apparent contradiction about which circumstances can cause
|
10260 |
|
|
a reallocation of a vector in Section 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> and
|
10261 |
|
|
section 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>.
|
10262 |
|
|
</p>
|
10263 |
|
|
|
10264 |
|
|
<p>23.2.4.2p5 says:</p>
|
10265 |
|
|
<blockquote>
|
10266 |
|
|
Notes: Reallocation invalidates all the references, pointers, and iterators
|
10267 |
|
|
referring to the elements in the sequence. It is guaranteed that no
|
10268 |
|
|
reallocation takes place during insertions that happen after a call to
|
10269 |
|
|
reserve() until the time when an insertion would make the size of the vector
|
10270 |
|
|
greater than the size specified in the most recent call to reserve().
|
10271 |
|
|
</blockquote>
|
10272 |
|
|
|
10273 |
|
|
<p>Which implies if I do</p>
|
10274 |
|
|
|
10275 |
|
|
<pre> std::vector<int> vec;
|
10276 |
|
|
vec.reserve(23);
|
10277 |
|
|
vec.reserve(0);
|
10278 |
|
|
vec.insert(vec.end(),1);
|
10279 |
|
|
</pre>
|
10280 |
|
|
|
10281 |
|
|
<p>then the implementation may reallocate the vector for the insert,
|
10282 |
|
|
as the size specified in the previous call to reserve was zero.</p>
|
10283 |
|
|
|
10284 |
|
|
<p>However, the previous paragraphs (23.2.4.2, p1-2) state:</p>
|
10285 |
|
|
<blockquote>
|
10286 |
|
|
<p>
|
10287 |
|
|
(capacity) Returns: The total number of elements the vector
|
10288 |
|
|
can hold without requiring reallocation
|
10289 |
|
|
</p>
|
10290 |
|
|
<p>
|
10291 |
|
|
...After reserve(), capacity() is greater or equal to the
|
10292 |
|
|
argument of reserve if reallocation happens; and equal to the previous value
|
10293 |
|
|
of capacity() otherwise...
|
10294 |
|
|
</p>
|
10295 |
|
|
</blockquote>
|
10296 |
|
|
|
10297 |
|
|
<p>
|
10298 |
|
|
This implies that vec.capacity() is still 23, and so the insert()
|
10299 |
|
|
should not require a reallocation, as vec.size() is 0. This is backed
|
10300 |
|
|
up by 23.2.4.3p1:
|
10301 |
|
|
</p>
|
10302 |
|
|
<blockquote>
|
10303 |
|
|
(insert) Notes: Causes reallocation if the new size is greater than the old
|
10304 |
|
|
capacity.
|
10305 |
|
|
</blockquote>
|
10306 |
|
|
|
10307 |
|
|
<p>
|
10308 |
|
|
Though this doesn't rule out reallocation if the new size is less
|
10309 |
|
|
than the old capacity, I think the intent is clear.
|
10310 |
|
|
</p>
|
10311 |
|
|
|
10312 |
|
|
<p><b>Proposed resolution:</b></p>
|
10313 |
|
|
<p>Change the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5 to:</p>
|
10314 |
|
|
|
10315 |
|
|
<blockquote>
|
10316 |
|
|
Notes: Reallocation invalidates all the references, pointers, and
|
10317 |
|
|
iterators referring to the elements in the sequence. It is guaranteed
|
10318 |
|
|
that no reallocation takes place during insertions that happen after a
|
10319 |
|
|
call to reserve() until the time when an insertion would make the size
|
10320 |
|
|
of the vector greater than the value of capacity().
|
10321 |
|
|
</blockquote>
|
10322 |
|
|
|
10323 |
|
|
<p><i>[Redmond: original proposed resolution was modified slightly. In
|
10324 |
|
|
the original, the guarantee was that there would be no reallocation
|
10325 |
|
|
until the size would be greater than the value of capacity() after the
|
10326 |
|
|
most recent call to reserve(). The LWG did not believe that the
|
10327 |
|
|
"after the most recent call to reserve()" added any useful
|
10328 |
|
|
information.]</i></p>
|
10329 |
|
|
|
10330 |
|
|
<p><b>Rationale:</b></p>
|
10331 |
|
|
<p>There was general agreement that, when reserve() is called twice in
|
10332 |
|
|
succession and the argument to the second invocation is smaller than
|
10333 |
|
|
the argument to the first, the intent was for the second invocation to
|
10334 |
|
|
have no effect. Wording implying that such cases have an effect on
|
10335 |
|
|
reallocation guarantees was inadvertant.</p>
|
10336 |
|
|
<hr>
|
10337 |
|
|
<a name="331"><h3>331. bad declaration of destructor for ios_base::failure</h3></a><p><b>Section:</b> 27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 23 Aug 2001</p>
|
10338 |
|
|
<p>
|
10339 |
|
|
With the change in 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> to state
|
10340 |
|
|
"An implementation may strengthen the exception-specification for a
|
10341 |
|
|
non-virtual function by removing listed exceptions."
|
10342 |
|
|
(issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
|
10343 |
|
|
and the following declaration of ~failure() in ios_base::failure
|
10344 |
|
|
</p>
|
10345 |
|
|
<pre> namespace std {
|
10346 |
|
|
class ios_base::failure : public exception {
|
10347 |
|
|
public:
|
10348 |
|
|
...
|
10349 |
|
|
virtual ~failure();
|
10350 |
|
|
...
|
10351 |
|
|
};
|
10352 |
|
|
}
|
10353 |
|
|
</pre>
|
10354 |
|
|
<p>the class failure cannot be implemented since in 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> the destructor of class exception has an empty
|
10355 |
|
|
exception specification:</p>
|
10356 |
|
|
<pre> namespace std {
|
10357 |
|
|
class exception {
|
10358 |
|
|
public:
|
10359 |
|
|
...
|
10360 |
|
|
virtual ~exception() throw();
|
10361 |
|
|
...
|
10362 |
|
|
};
|
10363 |
|
|
}
|
10364 |
|
|
</pre>
|
10365 |
|
|
<p><b>Proposed resolution:</b></p>
|
10366 |
|
|
<p>Remove the declaration of ~failure().</p>
|
10367 |
|
|
<p><b>Rationale:</b></p>
|
10368 |
|
|
<p>The proposed resolution is consistent with the way that destructors
|
10369 |
|
|
of other classes derived from <tt>exception</tt> are handled.</p>
|
10370 |
|
|
<hr>
|
10371 |
|
|
<a name="333"><h3>333. does endl imply synchronization with the device?</h3></a><p><b>Section:</b> 27.6.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 27 Aug 2001</p>
|
10372 |
|
|
<p>A footnote in 27.6.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> states:</p>
|
10373 |
|
|
<blockquote>
|
10374 |
|
|
[Footnote: The effect of executing cout << endl is to insert a
|
10375 |
|
|
newline character in the output sequence controlled by cout, then
|
10376 |
|
|
synchronize it with any external file with which it might be
|
10377 |
|
|
associated. --- end foonote]
|
10378 |
|
|
</blockquote>
|
10379 |
|
|
|
10380 |
|
|
<p>
|
10381 |
|
|
Does the term "file" here refer to the external device?
|
10382 |
|
|
This leads to some implementation ambiguity on systems with fully
|
10383 |
|
|
buffered files where a newline does not cause a flush to the device.
|
10384 |
|
|
</p>
|
10385 |
|
|
|
10386 |
|
|
<p>
|
10387 |
|
|
Choosing to sync with the device leads to significant performance
|
10388 |
|
|
penalties for each call to endl, while not sync-ing leads to
|
10389 |
|
|
errors under special circumstances.
|
10390 |
|
|
</p>
|
10391 |
|
|
|
10392 |
|
|
<p>
|
10393 |
|
|
I could not find any other statement that explicitly defined
|
10394 |
|
|
the behavior one way or the other.
|
10395 |
|
|
</p>
|
10396 |
|
|
<p><b>Proposed resolution:</b></p>
|
10397 |
|
|
<p>Remove footnote 300 from section 27.6.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>.</p>
|
10398 |
|
|
<p><b>Rationale:</b></p>
|
10399 |
|
|
<p>We already have normative text saying what <tt>endl</tt> does: it
|
10400 |
|
|
inserts a newline character and calls <tt>flush</tt>. This footnote
|
10401 |
|
|
is at best redundant, at worst (as this issue says) misleading,
|
10402 |
|
|
because it appears to make promises about what <tt>flush</tt>
|
10403 |
|
|
does.</p>
|
10404 |
|
|
<hr>
|
10405 |
|
|
<a name="334"><h3>334. map::operator[] specification forces inefficient implementation</h3></a><p><b>Section:</b> 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andrea Griffini <b>Date:</b> 02 Sep 2001</p>
|
10406 |
|
|
<p>
|
10407 |
|
|
The current standard describes map::operator[] using a
|
10408 |
|
|
code example. That code example is however quite
|
10409 |
|
|
inefficient because it requires several useless copies
|
10410 |
|
|
of both the passed key_type value and of default
|
10411 |
|
|
constructed mapped_type instances.
|
10412 |
|
|
My opinion is that was not meant by the comitee to
|
10413 |
|
|
require all those temporary copies.
|
10414 |
|
|
</p>
|
10415 |
|
|
|
10416 |
|
|
<p>Currently map::operator[] behaviour is specified as: </p>
|
10417 |
|
|
<pre> Returns:
|
10418 |
|
|
(*((insert(make_pair(x, T()))).first)).second.
|
10419 |
|
|
</pre>
|
10420 |
|
|
|
10421 |
|
|
<p>
|
10422 |
|
|
This specification however uses make_pair that is a
|
10423 |
|
|
template function of which parameters in this case
|
10424 |
|
|
will be deduced being of type const key_type& and
|
10425 |
|
|
const T&. This will create a pair<key_type,T> that
|
10426 |
|
|
isn't the correct type expected by map::insert so
|
10427 |
|
|
another copy will be required using the template
|
10428 |
|
|
conversion constructor available in pair to build
|
10429 |
|
|
the required pair<const key_type,T> instance.
|
10430 |
|
|
</p>
|
10431 |
|
|
|
10432 |
|
|
<p>If we consider calling of key_type copy constructor
|
10433 |
|
|
and mapped_type default constructor and copy
|
10434 |
|
|
constructor as observable behaviour (as I think we
|
10435 |
|
|
should) then the standard is in this place requiring
|
10436 |
|
|
two copies of a key_type element plus a default
|
10437 |
|
|
construction and two copy construction of a mapped_type
|
10438 |
|
|
(supposing the addressed element is already present
|
10439 |
|
|
in the map; otherwise at least another copy
|
10440 |
|
|
construction for each type).
|
10441 |
|
|
</p>
|
10442 |
|
|
|
10443 |
|
|
<p>A simple (half) solution would be replacing the description with:</p>
|
10444 |
|
|
<pre> Returns:
|
10445 |
|
|
(*((insert(value_type(x, T()))).first)).second.
|
10446 |
|
|
</pre>
|
10447 |
|
|
|
10448 |
|
|
<p>This will remove the wrong typed pair construction that
|
10449 |
|
|
requires one extra copy of both key and value.</p>
|
10450 |
|
|
|
10451 |
|
|
<p>However still the using of map::insert requires temporary
|
10452 |
|
|
objects while the operation, from a logical point of view,
|
10453 |
|
|
doesn't require any. </p>
|
10454 |
|
|
|
10455 |
|
|
<p>I think that a better solution would be leaving free an
|
10456 |
|
|
implementer to use a different approach than map::insert
|
10457 |
|
|
that, because of its interface, forces default constructed
|
10458 |
|
|
temporaries and copies in this case.
|
10459 |
|
|
The best solution in my opinion would be just requiring
|
10460 |
|
|
map::operator[] to return a reference to the mapped_type
|
10461 |
|
|
part of the contained element creating a default element
|
10462 |
|
|
with the specified key if no such an element is already
|
10463 |
|
|
present in the container. Also a logarithmic complexity
|
10464 |
|
|
requirement should be specified for the operation.
|
10465 |
|
|
</p>
|
10466 |
|
|
|
10467 |
|
|
<p>
|
10468 |
|
|
This would allow library implementers to write alternative
|
10469 |
|
|
implementations not using map::insert and reaching optimal
|
10470 |
|
|
performance in both cases of the addressed element being
|
10471 |
|
|
present or absent from the map (no temporaries at all and
|
10472 |
|
|
just the creation of a new pair inside the container if
|
10473 |
|
|
the element isn't present).
|
10474 |
|
|
Some implementer has already taken this option but I think
|
10475 |
|
|
that the current wording of the standard rules that as
|
10476 |
|
|
non-conforming.
|
10477 |
|
|
</p>
|
10478 |
|
|
|
10479 |
|
|
<p><b>Proposed resolution:</b></p>
|
10480 |
|
|
|
10481 |
|
|
<p>
|
10482 |
|
|
Replace 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a> paragraph 1 with
|
10483 |
|
|
</p>
|
10484 |
|
|
<blockquote>
|
10485 |
|
|
<p>
|
10486 |
|
|
-1- Effects: If there is no key equivalent to x in the map, inserts
|
10487 |
|
|
value_type(x, T()) into the map.
|
10488 |
|
|
</p>
|
10489 |
|
|
<p>
|
10490 |
|
|
-2- Returns: A reference to the mapped_type corresponding to x in *this.
|
10491 |
|
|
</p>
|
10492 |
|
|
<p>
|
10493 |
|
|
-3- Complexity: logarithmic.
|
10494 |
|
|
</p>
|
10495 |
|
|
</blockquote>
|
10496 |
|
|
|
10497 |
|
|
<p><i>[This is the second option mentioned above. Howard provided
|
10498 |
|
|
wording. We may also wish to have a blanket statement somewhere in
|
10499 |
|
|
clause 17 saying that we do not intend the semantics of sample code
|
10500 |
|
|
fragments to be interpreted as specifing exactly how many copies are
|
10501 |
|
|
made. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a> for a similar problem.]</i></p>
|
10502 |
|
|
|
10503 |
|
|
<p><b>Rationale:</b></p>
|
10504 |
|
|
<p>
|
10505 |
|
|
This is the second solution described above; as noted, it is
|
10506 |
|
|
consistent with existing practice.
|
10507 |
|
|
</p>
|
10508 |
|
|
|
10509 |
|
|
<p>Note that we now need to specify the complexity explicitly, because
|
10510 |
|
|
we are no longer defining <tt>operator[]</tt> in terms of
|
10511 |
|
|
<tt>insert</tt>.</p>
|
10512 |
|
|
<hr>
|
10513 |
|
|
<a name="335"><h3>335. minor issue with char_traits, table 37</h3></a><p><b>Section:</b> 21.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 06 Sep 2001</p>
|
10514 |
|
|
<p>
|
10515 |
|
|
Table 37, in 21.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>, descibes char_traits::assign
|
10516 |
|
|
as:
|
10517 |
|
|
</p>
|
10518 |
|
|
<pre> X::assign(c,d) assigns c = d.
|
10519 |
|
|
</pre>
|
10520 |
|
|
|
10521 |
|
|
<p>And para 1 says:</p>
|
10522 |
|
|
|
10523 |
|
|
<blockquote>
|
10524 |
|
|
[...] c and d denote values of type CharT [...]
|
10525 |
|
|
</blockquote>
|
10526 |
|
|
|
10527 |
|
|
<p>
|
10528 |
|
|
Naturally, if c and d are <i>values</i>, then the assignment is
|
10529 |
|
|
(effectively) meaningless. It's clearly intended that (in the case of
|
10530 |
|
|
assign, at least), 'c' is intended to be a reference type.
|
10531 |
|
|
</p>
|
10532 |
|
|
|
10533 |
|
|
<p>I did a quick survey of the four implementations I happened to have
|
10534 |
|
|
lying around, and sure enough they all have signatures:</p>
|
10535 |
|
|
<pre> assign( charT&, const charT& );
|
10536 |
|
|
</pre>
|
10537 |
|
|
|
10538 |
|
|
<p>(or the equivalent). It's also described this way in Nico's book.
|
10539 |
|
|
(Not to mention the synopses of char_traits<char> in 21.1.3.1
|
10540 |
|
|
and char_traits<wchar_t> in 21.1.3.2...)
|
10541 |
|
|
</p>
|
10542 |
|
|
<p><b>Proposed resolution:</b></p>
|
10543 |
|
|
<p>Add the following to 21.1.1 para 1:</p>
|
10544 |
|
|
<blockquote>
|
10545 |
|
|
r denotes an lvalue of CharT
|
10546 |
|
|
</blockquote>
|
10547 |
|
|
|
10548 |
|
|
<p>and change the description of assign in the table to:</p>
|
10549 |
|
|
<pre> X::assign(r,d) assigns r = d
|
10550 |
|
|
</pre>
|
10551 |
|
|
<hr>
|
10552 |
|
|
<a name="336"><h3>336. Clause 17 lack of references to deprecated headers</h3></a><p><b>Section:</b> 17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 05 Sep 2001</p>
|
10553 |
|
|
<p>From c++std-edit-873:</p>
|
10554 |
|
|
|
10555 |
|
|
<p>17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>, Table 11. In this table, the header
|
10556 |
|
|
<strstream> is missing.</p>
|
10557 |
|
|
|
10558 |
|
|
<p>This shows a general problem: The whole clause 17 refers quite
|
10559 |
|
|
often to clauses 18 through 27, but D.7 is also a part of the standard
|
10560 |
|
|
library (though a deprecated one).</p>
|
10561 |
|
|
|
10562 |
|
|
<p><b>Proposed resolution:</b></p>
|
10563 |
|
|
|
10564 |
|
|
<p>To 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> Table 11, C++ Library Headers, add
|
10565 |
|
|
"<strstream>".</p>
|
10566 |
|
|
|
10567 |
|
|
<p>In the following places, change "clauses 17 through 27" to "clauses
|
10568 |
|
|
17 through 27 and Annex D":</p>
|
10569 |
|
|
|
10570 |
|
|
<ul>
|
10571 |
|
|
<li>1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.refs"> [intro.refs]</a> Normative references/1/footnote 1</li>
|
10572 |
|
|
<li>1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.defs"> [intro.defs]</a> Definitions/1</li>
|
10573 |
|
|
<li>7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.dcl"> [dcl.dcl]</a> Library introduction/9</li>
|
10574 |
|
|
<li>17.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.description"> [lib.description]</a> Method of description (Informative)/1</li>
|
10575 |
|
|
<li>17.3.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.character.seq"> [lib.character.seq]</a> Character sequences/1/bullet 2</li>
|
10576 |
|
|
<li>17.3.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.functions.within.classes"> [lib.functions.within.classes]</a> Functions within classes/1</li>
|
10577 |
|
|
<li>17.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.objects.within.classes"> [lib.objects.within.classes]</a> Private members/1/(2 places)</li>
|
10578 |
|
|
<li>17.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.requirements"> [lib.requirements]</a> Library-wide requirements/1</li>
|
10579 |
|
|
<li>17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> Headers/4</li>
|
10580 |
|
|
<li>17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> Replacement functions/1</li>
|
10581 |
|
|
<li>17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a> Global or non-member functions/2</li>
|
10582 |
|
|
<li>17.4.4.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.protection.within.classes"> [lib.protection.within.classes]</a> Protection within classes/1</li>
|
10583 |
|
|
</ul>
|
10584 |
|
|
|
10585 |
|
|
|
10586 |
|
|
<hr>
|
10587 |
|
|
<a name="337"><h3>337. replace_copy_if's template parameter should be InputIterator</h3></a><p><b>Section:</b> 25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 07 Sep 2001</p>
|
10588 |
|
|
<p>From c++std-edit-876:</p>
|
10589 |
|
|
|
10590 |
|
|
<p>
|
10591 |
|
|
In section 25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> before p4: The name of the first
|
10592 |
|
|
parameter of template replace_copy_if should be "InputIterator"
|
10593 |
|
|
instead of "Iterator". According to 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a> p1 the
|
10594 |
|
|
parameter name conveys real normative meaning.
|
10595 |
|
|
</p>
|
10596 |
|
|
<p><b>Proposed resolution:</b></p>
|
10597 |
|
|
<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
|
10598 |
|
|
<hr>
|
10599 |
|
|
<a name="338"><h3>338. is whitespace allowed between `-' and a digit?</h3></a><p><b>Section:</b> 22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 17 Sep 2001</p>
|
10600 |
|
|
<p>
|
10601 |
|
|
>From Stage 2 processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the
|
10602 |
|
|
original text or the text corrected by the proposed resolution of
|
10603 |
|
|
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
|
10604 |
|
|
within a number, but 22.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a>, p2, which gives the
|
10605 |
|
|
format for integer and floating point values, says that whitespace is
|
10606 |
|
|
optional between a plusminus and a sign.
|
10607 |
|
|
</p>
|
10608 |
|
|
|
10609 |
|
|
<p>
|
10610 |
|
|
The text needs to be clarified to either consistently allow or
|
10611 |
|
|
disallow whitespace between a plusminus and a sign. It might be
|
10612 |
|
|
worthwhile to consider the fact that the C library stdio facility does
|
10613 |
|
|
not permit whitespace embedded in numbers and neither does the C or
|
10614 |
|
|
C++ core language (the syntax of integer-literals is given in 2.13.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lex.html#lex.icon"> [lex.icon]</a>, that of floating-point-literals in 2.13.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lex.html#lex.fcon"> [lex.fcon]</a> of the C++ standard).
|
10615 |
|
|
</p>
|
10616 |
|
|
<p><b>Proposed resolution:</b></p>
|
10617 |
|
|
<p>Change the first part of 22.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 from:</p>
|
10618 |
|
|
<blockquote>
|
10619 |
|
|
<p>
|
10620 |
|
|
The syntax for number formats is as follows, where <tt>digit</tt>
|
10621 |
|
|
represents the radix set specified by the <tt>fmtflags</tt> argument
|
10622 |
|
|
value, <tt>whitespace</tt> is as determined by the facet
|
10623 |
|
|
<tt>ctype<charT></tt> (22.2.1.1), and <tt>thousands-sep</tt> and
|
10624 |
|
|
<tt>decimal-point</tt> are the results of corresponding
|
10625 |
|
|
<tt>numpunct<charT></tt> members. Integer values have the
|
10626 |
|
|
format:
|
10627 |
|
|
</p>
|
10628 |
|
|
<pre> integer ::= [sign] units
|
10629 |
|
|
sign ::= plusminus [whitespace]
|
10630 |
|
|
plusminus ::= '+' | '-'
|
10631 |
|
|
units ::= digits [thousands-sep units]
|
10632 |
|
|
digits ::= digit [digits]
|
10633 |
|
|
</pre>
|
10634 |
|
|
</blockquote>
|
10635 |
|
|
<p>to:</p>
|
10636 |
|
|
<blockquote>
|
10637 |
|
|
<p>
|
10638 |
|
|
The syntax for number formats is as follows, where <tt>digit</tt>
|
10639 |
|
|
represents the radix set specified by the <tt>fmtflags</tt> argument
|
10640 |
|
|
value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
|
10641 |
|
|
results of corresponding <tt>numpunct<charT></tt> members.
|
10642 |
|
|
Integer values have the format:
|
10643 |
|
|
</p>
|
10644 |
|
|
<pre> integer ::= [sign] units
|
10645 |
|
|
sign ::= plusminus
|
10646 |
|
|
plusminus ::= '+' | '-'
|
10647 |
|
|
units ::= digits [thousands-sep units]
|
10648 |
|
|
digits ::= digit [digits]
|
10649 |
|
|
</pre>
|
10650 |
|
|
</blockquote>
|
10651 |
|
|
<p><b>Rationale:</b></p>
|
10652 |
|
|
<p>It's not clear whether the format described in 22.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 has any normative weight: nothing in the
|
10653 |
|
|
standard says how, or whether, it's used. However, there's no reason
|
10654 |
|
|
for it to differ gratuitously from the very specific description of
|
10655 |
|
|
numeric processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>. The proposed
|
10656 |
|
|
resolution removes all mention of "whitespace" from that format.</p>
|
10657 |
|
|
<hr>
|
10658 |
|
|
<a name="339"><h3>339. definition of bitmask type restricted to clause 27</h3></a><p><b>Section:</b> 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 17 September 2001</p>
|
10659 |
|
|
<p>
|
10660 |
|
|
The ctype_category::mask type is declared to be an enum in 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> with p1 then stating that it is a bitmask type, most
|
10661 |
|
|
likely referring to the definition of bitmask type in 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>, p1. However, the said definition only applies to
|
10662 |
|
|
clause 27, making the reference in 22.2.1 somewhat dubious.
|
10663 |
|
|
</p>
|
10664 |
|
|
<p><b>Proposed resolution:</b></p>
|
10665 |
|
|
<p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
|
10666 |
|
|
<blockquote>
|
10667 |
|
|
Several types defined in clause 27 are bitmask types. Each bitmask type
|
10668 |
|
|
can be implemented as an enumerated type that overloads certain operators,
|
10669 |
|
|
as an integer type, or as a bitset (23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>).
|
10670 |
|
|
</blockquote>
|
10671 |
|
|
<p>to read</p>
|
10672 |
|
|
<blockquote>
|
10673 |
|
|
Several types defined in clauses lib.language.support through
|
10674 |
|
|
lib.input.output and Annex D are bitmask types. Each bitmask type can
|
10675 |
|
|
be implemented as an enumerated type that overloads certain operators,
|
10676 |
|
|
as an integer type, or as a bitset (lib.template.bitset).
|
10677 |
|
|
</blockquote>
|
10678 |
|
|
|
10679 |
|
|
<p>
|
10680 |
|
|
Additionally, change the definition in 22.2.1 to adopt the same
|
10681 |
|
|
convention as in clause 27 by replacing the existing text with the
|
10682 |
|
|
following (note, in particluar, the cross-reference to 17.3.2.1.2 in
|
10683 |
|
|
22.2.1, p1):
|
10684 |
|
|
</p>
|
10685 |
|
|
|
10686 |
|
|
<blockquote>
|
10687 |
|
|
<p>22.2.1 The ctype category [lib.category.ctype]</p>
|
10688 |
|
|
<pre>namespace std {
|
10689 |
|
|
class ctype_base {
|
10690 |
|
|
public:
|
10691 |
|
|
typedef <b><i>T</i></b> mask;
|
10692 |
|
|
|
10693 |
|
|
// numeric values are for exposition only.
|
10694 |
|
|
static const mask space = 1 << 0;
|
10695 |
|
|
static const mask print = 1 << 1;
|
10696 |
|
|
static const mask cntrl = 1 << 2;
|
10697 |
|
|
static const mask upper = 1 << 3;
|
10698 |
|
|
static const mask lower = 1 << 4;
|
10699 |
|
|
static const mask alpha = 1 << 5;
|
10700 |
|
|
static const mask digit = 1 << 6;
|
10701 |
|
|
static const mask punct = 1 << 7;
|
10702 |
|
|
static const mask xdigit = 1 << 8;
|
10703 |
|
|
static const mask alnum = alpha | digit;
|
10704 |
|
|
static const mask graph = alnum | punct;
|
10705 |
|
|
};
|
10706 |
|
|
}
|
10707 |
|
|
</pre>
|
10708 |
|
|
|
10709 |
|
|
<p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>).</p>
|
10710 |
|
|
</blockquote>
|
10711 |
|
|
|
10712 |
|
|
<p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
|
10713 |
|
|
consistent with the rest of the standard.]</i></p>
|
10714 |
|
|
|
10715 |
|
|
<hr>
|
10716 |
|
|
<a name="340"><h3>340. interpretation of <tt>has_facet<Facet>(loc)</tt>
|
10717 |
|
|
</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2001</p>
|
10718 |
|
|
<p>
|
10719 |
|
|
It's unclear whether 22.1.1.1.1, p3 says that
|
10720 |
|
|
<tt>has_facet<Facet>(loc)</tt> returns true for any <tt>Facet</tt>
|
10721 |
|
|
from Table 51 or whether it includes Table 52 as well:
|
10722 |
|
|
</p>
|
10723 |
|
|
|
10724 |
|
|
<blockquote>
|
10725 |
|
|
For any locale <tt>loc</tt> either constructed, or returned by
|
10726 |
|
|
locale::classic(), and any facet <tt>Facet</tt> that is a member of a
|
10727 |
|
|
standard category, <tt>has_facet<Facet>(loc)</tt> is true. Each
|
10728 |
|
|
locale member function which takes a <tt>locale::category</tt>
|
10729 |
|
|
argument operates on the corresponding set of facets.
|
10730 |
|
|
</blockquote>
|
10731 |
|
|
|
10732 |
|
|
<p>
|
10733 |
|
|
It seems that it comes down to which facets are considered to be members of a
|
10734 |
|
|
standard category. Intuitively, I would classify all the facets in Table 52 as
|
10735 |
|
|
members of their respective standard categories, but there are an unbounded set
|
10736 |
|
|
of them...
|
10737 |
|
|
</p>
|
10738 |
|
|
|
10739 |
|
|
<p>
|
10740 |
|
|
The paragraph implies that, for instance, <tt>has_facet<num_put<C,
|
10741 |
|
|
OutputIterator> >(loc)</tt> must always return true. I don't think that's
|
10742 |
|
|
possible. If it were, then <tt>use_facet<num_put<C, OutputIterator>
|
10743 |
|
|
>(loc)</tt> would have to return a reference to a distinct object for each
|
10744 |
|
|
valid specialization of <tt>num_put<C, OutputIteratory></tt>, which is
|
10745 |
|
|
clearly impossible.
|
10746 |
|
|
</p>
|
10747 |
|
|
|
10748 |
|
|
<p>
|
10749 |
|
|
On the other hand, if none of the facets in Table 52 is a member of a standard
|
10750 |
|
|
category then none of the locale member functions that operate on entire
|
10751 |
|
|
categories of facets will work properly.
|
10752 |
|
|
</p>
|
10753 |
|
|
|
10754 |
|
|
<p>
|
10755 |
|
|
It seems that what p3 should mention that it's required (permitted?)
|
10756 |
|
|
to hold only for specializations of <tt>Facet</tt> from Table 52 on
|
10757 |
|
|
<tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
|
10758 |
|
|
<tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
|
10759 |
|
|
{
|
10760 |
|
|
{i,o}<tt>streambuf_iterator</tt><{<tt>char</tt>,<tt>wchar_t</tt>}<tt>></tt>
|
10761 |
|
|
}.
|
10762 |
|
|
</p>
|
10763 |
|
|
<p><b>Proposed resolution:</b></p>
|
10764 |
|
|
<p>In 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 3, change
|
10765 |
|
|
"that is a member of a standard category" to "shown in Table 51".</p>
|
10766 |
|
|
<p><b>Rationale:</b></p>
|
10767 |
|
|
<p>The facets in Table 52 are an unbounded set. Locales should not be
|
10768 |
|
|
required to contain an infinite number of facets.</p>
|
10769 |
|
|
|
10770 |
|
|
<p>It's not necessary to talk about which values of InputIterator and
|
10771 |
|
|
OutputIterator must be supported. Table 51 already contains a
|
10772 |
|
|
complete list of the ones we need.</p>
|
10773 |
|
|
<hr>
|
10774 |
|
|
<a name="341"><h3>341. Vector reallocation and swap</h3></a><p><b>Section:</b> 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 27 Sep 2001</p>
|
10775 |
|
|
<p>It is a common idiom to reduce the capacity of a vector by swapping it with
|
10776 |
|
|
an empty one:</p>
|
10777 |
|
|
<pre> std::vector<SomeType> vec;
|
10778 |
|
|
// fill vec with data
|
10779 |
|
|
std::vector<SomeType>().swap(vec);
|
10780 |
|
|
// vec is now empty, with minimal capacity
|
10781 |
|
|
</pre>
|
10782 |
|
|
|
10783 |
|
|
<p>However, the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a>paragraph 5 prevents
|
10784 |
|
|
the capacity of a vector being reduced, following a call to
|
10785 |
|
|
reserve(). This invalidates the idiom, as swap() is thus prevented
|
10786 |
|
|
from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this. Consequently, the example above
|
10787 |
|
|
requires the temporary to be expanded to cater for the contents of
|
10788 |
|
|
vec, and the contents be copied across. This is a linear-time
|
10789 |
|
|
operation.</p>
|
10790 |
|
|
|
10791 |
|
|
<p>However, the container requirements state that swap must have constant
|
10792 |
|
|
complexity (23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> note to table 65).</p>
|
10793 |
|
|
|
10794 |
|
|
<p>This is an important issue, as reallocation affects the validity of
|
10795 |
|
|
references and iterators.</p>
|
10796 |
|
|
|
10797 |
|
|
<p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
|
10798 |
|
|
references and iterators remain valid after a call to swap, if they refer to
|
10799 |
|
|
an element before the new end() of the vector into which they originally
|
10800 |
|
|
pointed, in which case they refer to the element at the same index position.
|
10801 |
|
|
Iterators and references that referred to an element whose index position
|
10802 |
|
|
was beyond the new end of the vector are invalidated.</p>
|
10803 |
|
|
|
10804 |
|
|
<p>If the note to table 65 is taken as the desired intent, then there are two
|
10805 |
|
|
possibilities with regard to iterators and references:</p>
|
10806 |
|
|
|
10807 |
|
|
<ol>
|
10808 |
|
|
<li>All Iterators and references into both vectors are invalidated.</li>
|
10809 |
|
|
<li>Iterators and references into either vector remain valid, and remain
|
10810 |
|
|
pointing to the same element. Consequently iterators and references that
|
10811 |
|
|
referred to one vector now refer to the other, and vice-versa.</li>
|
10812 |
|
|
</ol>
|
10813 |
|
|
<p><b>Proposed resolution:</b></p>
|
10814 |
|
|
<p>Add a new paragraph after 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.capacity"> [lib.vector.capacity]</a> paragraph 5:</p>
|
10815 |
|
|
<blockquote>
|
10816 |
|
|
<pre> void swap(vector<T,Allocator>& x);
|
10817 |
|
|
</pre>
|
10818 |
|
|
<p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
|
10819 |
|
|
with that of <tt>x</tt>.</p>
|
10820 |
|
|
<p><b>Complexity:</b> Constant time.</p>
|
10821 |
|
|
</blockquote>
|
10822 |
|
|
|
10823 |
|
|
<p><i>[This solves the problem reported for this issue. We may also
|
10824 |
|
|
have a problem with a circular definition of swap() for other
|
10825 |
|
|
containers.]</i></p>
|
10826 |
|
|
|
10827 |
|
|
<p><b>Rationale:</b></p>
|
10828 |
|
|
<p>
|
10829 |
|
|
swap should be constant time. The clear intent is that it should just
|
10830 |
|
|
do pointer twiddling, and that it should exchange all properties of
|
10831 |
|
|
the two vectors, including their reallocation guarantees.
|
10832 |
|
|
</p>
|
10833 |
|
|
<hr>
|
10834 |
|
|
<a name="345"><h3>345. type tm in <cwchar></h3></a><p><b>Section:</b> 21.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Clark Nelson <b>Date:</b> 19 Oct 2001</p>
|
10835 |
|
|
<p>
|
10836 |
|
|
C99, and presumably amendment 1 to C90, specify that <wchar.h>
|
10837 |
|
|
declares struct tm as an incomplete type. However, table 48 in 21.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a> does not mention the type tm as being declared in
|
10838 |
|
|
<cwchar>. Is this omission intentional or accidental?
|
10839 |
|
|
</p>
|
10840 |
|
|
<p><b>Proposed resolution:</b></p>
|
10841 |
|
|
<p>In section 21.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a>, add "tm" to table 48.</p>
|
10842 |
|
|
<hr>
|
10843 |
|
|
<a name="346"><h3>346. Some iterator member functions should be const</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 20 Oct 2001</p>
|
10844 |
|
|
<p>Iterator member functions and operators that do not change the state
|
10845 |
|
|
of the iterator should be defined as const member functions or as
|
10846 |
|
|
functions that take iterators either by const reference or by
|
10847 |
|
|
value. The standard does not explicitly state which functions should
|
10848 |
|
|
be const. Since this a fairly common mistake, the following changes
|
10849 |
|
|
are suggested to make this explicit.</p>
|
10850 |
|
|
|
10851 |
|
|
<p>The tables almost indicate constness properly through naming: r
|
10852 |
|
|
for non-const and a,b for const iterators. The following changes
|
10853 |
|
|
make this more explicit and also fix a couple problems.</p>
|
10854 |
|
|
<p><b>Proposed resolution:</b></p>
|
10855 |
|
|
<p>In 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> Change the first section of p9 from
|
10856 |
|
|
"In the following sections, a and b denote values of X..." to
|
10857 |
|
|
"In the following sections, a and b denote values of type const X...".</p>
|
10858 |
|
|
|
10859 |
|
|
<p>In Table 73, change</p>
|
10860 |
|
|
<pre> a->m U& ...
|
10861 |
|
|
</pre>
|
10862 |
|
|
|
10863 |
|
|
<p>to</p>
|
10864 |
|
|
|
10865 |
|
|
<pre> a->m const U& ...
|
10866 |
|
|
r->m U& ...
|
10867 |
|
|
</pre>
|
10868 |
|
|
|
10869 |
|
|
<p>In Table 73 expression column, change</p>
|
10870 |
|
|
|
10871 |
|
|
<pre> *a = t
|
10872 |
|
|
</pre>
|
10873 |
|
|
|
10874 |
|
|
<p>to</p>
|
10875 |
|
|
|
10876 |
|
|
<pre> *r = t
|
10877 |
|
|
</pre>
|
10878 |
|
|
|
10879 |
|
|
<p><i>[Redmond: The container requirements should be reviewed to see if
|
10880 |
|
|
the same problem appears there.]</i></p>
|
10881 |
|
|
|
10882 |
|
|
<hr>
|
10883 |
|
|
<a name="347"><h3>347. locale::category and bitmask requirements</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Date:</b> 23 Oct 2001</p>
|
10884 |
|
|
<p>
|
10885 |
|
|
In 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> paragraph 1, the category members
|
10886 |
|
|
are described as bitmask elements. In fact, the bitmask requirements
|
10887 |
|
|
in 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> don't seem quite right: <tt>none</tt>
|
10888 |
|
|
and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
|
10889 |
|
|
|
10890 |
|
|
<p>In particular, the requirements for <tt>none</tt> interact poorly
|
10891 |
|
|
with the requirement that the LC_* constants from the C library must
|
10892 |
|
|
be recognizable as C++ locale category constants. LC_* values should
|
10893 |
|
|
not be mixed with these values to make category values.</p>
|
10894 |
|
|
|
10895 |
|
|
<p>We have two options for the proposed resolution. Informally:
|
10896 |
|
|
option 1 removes the requirement that LC_* values be recognized as
|
10897 |
|
|
category arguments. Option 2 changes the category type so that this
|
10898 |
|
|
requirement is implementable, by allowing <tt>none</tt> to be some
|
10899 |
|
|
value such as 0x1000 instead of 0.</p>
|
10900 |
|
|
|
10901 |
|
|
<p>Nathan writes: "I believe my proposed resolution [Option 2] merely
|
10902 |
|
|
re-expresses the status quo more clearly, without introducing any
|
10903 |
|
|
changes beyond resolving the DR.</p>
|
10904 |
|
|
|
10905 |
|
|
<p><b>Proposed resolution:</b></p>
|
10906 |
|
|
<p>Replace the first two paragraphs of 22.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
|
10907 |
|
|
<blockquote>
|
10908 |
|
|
<pre> typedef int category;
|
10909 |
|
|
</pre>
|
10910 |
|
|
|
10911 |
|
|
<p>Valid category values include the <tt>locale</tt> member bitmask
|
10912 |
|
|
elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
|
10913 |
|
|
<tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
|
10914 |
|
|
represents a single locale category. In addition, <tt>locale</tt> member
|
10915 |
|
|
bitmask constant <tt>none</tt> is defined as zero and represents no
|
10916 |
|
|
category. And locale member bitmask constant <tt>all</tt> is defined such that
|
10917 |
|
|
the expression</p>
|
10918 |
|
|
<pre> (collate | ctype | monetary | numeric | time | messages | all) == all
|
10919 |
|
|
</pre>
|
10920 |
|
|
<p>
|
10921 |
|
|
is <tt>true</tt>, and represents the union of all categories. Further
|
10922 |
|
|
the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
|
10923 |
|
|
represent a single category, represents the union of the two
|
10924 |
|
|
categories.
|
10925 |
|
|
</p>
|
10926 |
|
|
|
10927 |
|
|
<p>
|
10928 |
|
|
<tt>locale</tt> member functions expecting a <tt>category</tt>
|
10929 |
|
|
argument require one of the <tt>category</tt> values defined above, or
|
10930 |
|
|
the union of two or more such values. Such a <tt>category</tt>
|
10931 |
|
|
argument identifies a set of locale categories. Each locale category,
|
10932 |
|
|
in turn, identifies a set of locale facets, including at least those
|
10933 |
|
|
shown in Table 51:
|
10934 |
|
|
</p>
|
10935 |
|
|
</blockquote>
|
10936 |
|
|
<p><i>[Curaçao: need input from locale experts.]</i></p>
|
10937 |
|
|
|
10938 |
|
|
<p><b>Rationale:</b></p>
|
10939 |
|
|
|
10940 |
|
|
<p>The LWG considered, and rejected, an alternate proposal (described
|
10941 |
|
|
as "Option 2" in the discussion). The main reason for rejecting it
|
10942 |
|
|
was that library implementors were concerened about implementation
|
10943 |
|
|
difficult, given that getting a C++ library to work smoothly with a
|
10944 |
|
|
separately written C library is already a delicate business. Some
|
10945 |
|
|
library implementers were also concerned about the issue of adding
|
10946 |
|
|
extra locale categories.</p>
|
10947 |
|
|
|
10948 |
|
|
<blockquote>
|
10949 |
|
|
<p><b>Option 2:</b> <br>
|
10950 |
|
|
Replace the first paragraph of 22.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
|
10951 |
|
|
<blockquote>
|
10952 |
|
|
<p>
|
10953 |
|
|
Valid category values include the enumerated values. In addition, the
|
10954 |
|
|
result of applying commutative operators | and & to any two valid
|
10955 |
|
|
values is valid, and results in the setwise union and intersection,
|
10956 |
|
|
respectively, of the argument categories. The values <tt>all</tt> and
|
10957 |
|
|
<tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
|
10958 |
|
|
expressions <tt>(cat | all == all)</tt>, <tt>(cat & all == cat)</tt>,
|
10959 |
|
|
<tt>(cat | none == cat)</tt> and <tt>(cat & none == none)</tt> are
|
10960 |
|
|
true. For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
|
10961 |
|
|
remaining enumerated values, <tt>(cat1 & cat2 == none)</tt> is true.
|
10962 |
|
|
For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
|
10963 |
|
|
of <tt>(cat1 & ~cat2)</tt> is valid, and equals the setwise union of
|
10964 |
|
|
those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
|
10965 |
|
|
[Footnote: it is not required that <tt>all</tt> equal the setwise union
|
10966 |
|
|
of the other enumerated values; implementations may add extra categories.]
|
10967 |
|
|
</p>
|
10968 |
|
|
</blockquote>
|
10969 |
|
|
</blockquote>
|
10970 |
|
|
<hr>
|
10971 |
|
|
<a name="349"><h3>349. Minor typographical error in ostream_iterator</h3></a><p><b>Section:</b> 24.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 24 Oct 2001</p>
|
10972 |
|
|
<p>24.5.2 [lib.ostream.iterator] states:</p>
|
10973 |
|
|
<pre> [...]
|
10974 |
|
|
|
10975 |
|
|
private:
|
10976 |
|
|
// basic_ostream<charT,traits>* out_stream; exposition only
|
10977 |
|
|
// const char* delim; exposition only
|
10978 |
|
|
</pre>
|
10979 |
|
|
|
10980 |
|
|
<p>Whilst it's clearly marked "exposition only", I suspect 'delim'
|
10981 |
|
|
should be of type 'const charT*'.</p>
|
10982 |
|
|
<p><b>Proposed resolution:</b></p>
|
10983 |
|
|
<p>
|
10984 |
|
|
In 24.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>, replace <tt>const char* delim</tt> with
|
10985 |
|
|
<tt>const charT* delim</tt>.
|
10986 |
|
|
</p>
|
10987 |
|
|
<hr>
|
10988 |
|
|
<a name="352"><h3>352. missing fpos requirements</h3></a><p><b>Section:</b> 21.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.typedefs"> [lib.char.traits.typedefs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2 Dec 2001</p>
|
10989 |
|
|
<p>
|
10990 |
|
|
<i>(1)</i>
|
10991 |
|
|
There are no requirements on the <tt>stateT</tt> template parameter of
|
10992 |
|
|
<tt>fpos</tt> listed in 27.4.3. The interface appears to require that
|
10993 |
|
|
the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
|
10994 |
|
|
and I think also DefaultConstructible (to implement the operations in
|
10995 |
|
|
Table 88).
|
10996 |
|
|
</p>
|
10997 |
|
|
<p>
|
10998 |
|
|
21.1.2, p3, however, only requires that
|
10999 |
|
|
<tt>char_traits<charT>::state_type</tt> meet the requirements of
|
11000 |
|
|
CopyConstructible types.
|
11001 |
|
|
</p>
|
11002 |
|
|
<p>
|
11003 |
|
|
<i>(2)</i>
|
11004 |
|
|
Additionally, the <tt>stateT</tt> template argument has no
|
11005 |
|
|
corresponding typedef in fpos which might make it difficult to use in
|
11006 |
|
|
generic code.
|
11007 |
|
|
</p>
|
11008 |
|
|
<p><b>Proposed resolution:</b></p>
|
11009 |
|
|
<p>
|
11010 |
|
|
Modify 21.1.2, p4 from
|
11011 |
|
|
</p>
|
11012 |
|
|
<p>
|
11013 |
|
|
Requires: <tt>state_type</tt> shall meet the requirements of
|
11014 |
|
|
CopyConstructible types (20.1.3).
|
11015 |
|
|
</p>
|
11016 |
|
|
<p>
|
11017 |
|
|
Requires: state_type shall meet the requirements of Assignable
|
11018 |
|
|
(23.1, p4), CopyConstructible (20.1.3), and
|
11019 |
|
|
DefaultConstructible (20.1.4) types.
|
11020 |
|
|
</p>
|
11021 |
|
|
|
11022 |
|
|
<p><b>Rationale:</b></p>
|
11023 |
|
|
<p>The LWG feels this is two issues, as indicated above. The first is
|
11024 |
|
|
a defect---std::basic_fstream is unimplementable without these
|
11025 |
|
|
additional requirements---and the proposed resolution fixes it. The
|
11026 |
|
|
second is questionable; who would use that typedef? The class
|
11027 |
|
|
template fpos is used only in a very few places, all of which know the
|
11028 |
|
|
state type already. Unless motivation is provided, the second should
|
11029 |
|
|
be considered NAD.</p>
|
11030 |
|
|
<hr>
|
11031 |
|
|
<a name="354"><h3>354. Associative container lower/upper bound requirements</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Hans Aberg <b>Date:</b> 17 Dec 2001</p>
|
11032 |
|
|
<p>
|
11033 |
|
|
Discussions in the thread "Associative container lower/upper bound
|
11034 |
|
|
requirements" on comp.std.c++ suggests that there is a defect in the
|
11035 |
|
|
C++ standard, Table 69 of section 23.1.2, "Associative containers",
|
11036 |
|
|
[lib.associative.reqmts]. It currently says:</p>
|
11037 |
|
|
|
11038 |
|
|
<blockquote>
|
11039 |
|
|
<p>
|
11040 |
|
|
a.find(k): returns an iterator pointing to an element with the key equivalent to
|
11041 |
|
|
k, or a.end() if such an element is not found.
|
11042 |
|
|
</p>
|
11043 |
|
|
|
11044 |
|
|
<p>
|
11045 |
|
|
a.lower_bound(k): returns an iterator pointing to the first element with
|
11046 |
|
|
key not less than k.
|
11047 |
|
|
</p>
|
11048 |
|
|
|
11049 |
|
|
<p>
|
11050 |
|
|
a.upper_bound(k): returns an iterator pointing to the first element with
|
11051 |
|
|
key greater than k.
|
11052 |
|
|
</p>
|
11053 |
|
|
</blockquote>
|
11054 |
|
|
|
11055 |
|
|
<p>
|
11056 |
|
|
We have "or a.end() if such an element is not found" for
|
11057 |
|
|
<tt>find</tt>, but not for <tt>upper_bound</tt> or
|
11058 |
|
|
<tt>lower_bound</tt>. As the text stands, one would be forced to
|
11059 |
|
|
insert a new element into the container and return an iterator to that
|
11060 |
|
|
in case the sought iterator does not exist, which does not seem to be
|
11061 |
|
|
the intention (and not possible with the "const" versions).
|
11062 |
|
|
</p>
|
11063 |
|
|
<p><b>Proposed resolution:</b></p>
|
11064 |
|
|
|
11065 |
|
|
<p>Change Table 69 of section 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> indicated entries
|
11066 |
|
|
to:</p>
|
11067 |
|
|
|
11068 |
|
|
<blockquote>
|
11069 |
|
|
<p>
|
11070 |
|
|
a.lower_bound(k): returns an iterator pointing to the first element with
|
11071 |
|
|
key not less than k, or a.end() if such an element is not found.
|
11072 |
|
|
</p>
|
11073 |
|
|
|
11074 |
|
|
<p>
|
11075 |
|
|
a.upper_bound(k): returns an iterator pointing to the first element with
|
11076 |
|
|
key greater than k, or a.end() if such an element is not found.
|
11077 |
|
|
</p>
|
11078 |
|
|
</blockquote>
|
11079 |
|
|
|
11080 |
|
|
<p><i>[Curaçao: LWG reviewed PR.]</i></p>
|
11081 |
|
|
|
11082 |
|
|
<hr>
|
11083 |
|
|
<a name="355"></a><h3><a name="355">355. Operational semantics for a.back()</a></h3><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 23 Jan 2002</p>
|
11084 |
|
|
|
11085 |
|
|
<p>Table 68 "Optional Sequence Operations" in 23.1.1/12
|
11086 |
|
|
specifies operational semantics for "a.back()" as
|
11087 |
|
|
"*--a.end()", which may be ill-formed <i>[because calling
|
11088 |
|
|
operator-- on a temporary (the return) of a built-in type is
|
11089 |
|
|
ill-formed]</i>, provided a.end() returns a simple pointer rvalue
|
11090 |
|
|
(this is almost always the case for std::vector::end(), for
|
11091 |
|
|
example). Thus, the specification is not only incorrect, it
|
11092 |
|
|
demonstrates a dangerous construct: "--a.end()" may
|
11093 |
|
|
successfully compile and run as intended, but after changing the type
|
11094 |
|
|
of the container or the mode of compilation it may produce
|
11095 |
|
|
compile-time error. </p>
|
11096 |
|
|
|
11097 |
|
|
<p><b>Proposed resolution:</b></p>
|
11098 |
|
|
<p>Change the specification in table 68 "Optional Sequence
|
11099 |
|
|
Operations" in 23.1.1/12 for "a.back()" from</p>
|
11100 |
|
|
|
11101 |
|
|
|
11102 |
|
|
<blockquote>
|
11103 |
|
|
*--a.end()
|
11104 |
|
|
</blockquote>
|
11105 |
|
|
|
11106 |
|
|
<p>to</p>
|
11107 |
|
|
|
11108 |
|
|
<blockquote>
|
11109 |
|
|
{ iterator tmp = a.end(); --tmp; return *tmp; }
|
11110 |
|
|
</blockquote>
|
11111 |
|
|
|
11112 |
|
|
<p>and the specification for "a.pop_back()" from</p>
|
11113 |
|
|
|
11114 |
|
|
<blockquote>
|
11115 |
|
|
a.erase(--a.end())
|
11116 |
|
|
</blockquote>
|
11117 |
|
|
|
11118 |
|
|
<p>to</p>
|
11119 |
|
|
|
11120 |
|
|
<blockquote>
|
11121 |
|
|
{ iterator tmp = a.end(); --tmp; a.erase(tmp); }
|
11122 |
|
|
</blockquote>
|
11123 |
|
|
|
11124 |
|
|
<p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
|
11125 |
|
|
a.end(); return *--tmp; }" to "*a.rbegin()", and from
|
11126 |
|
|
"{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
|
11127 |
|
|
"a.erase(rbegin())".]</i></p>
|
11128 |
|
|
|
11129 |
|
|
<p><i>[There is a second possible defect; table 68 "Optional
|
11130 |
|
|
Sequence Operations" in the "Operational Semantics"
|
11131 |
|
|
column uses operations present only in the "Reversible
|
11132 |
|
|
Container" requirements, yet there is no stated dependency
|
11133 |
|
|
between these separate requirements tables. Ask in Santa Cruz if the
|
11134 |
|
|
LWG would like a new issue opened.]</i></p>
|
11135 |
|
|
|
11136 |
|
|
<p><i>[Santa Cruz: the proposed resolution is even worse than what's in
|
11137 |
|
|
the current standard: erase is undefined for reverse iterator. If
|
11138 |
|
|
we're going to make the change, we need to define a temporary and
|
11139 |
|
|
use operator--. Additionally, we don't know how prevalent this is:
|
11140 |
|
|
do we need to make this change in more than one place? Martin has
|
11141 |
|
|
volunteered to review the standard and see if this problem occurs
|
11142 |
|
|
elsewhere.]</i></p>
|
11143 |
|
|
|
11144 |
|
|
<p><i>[Oxford: Matt provided new wording to address the concerns raised
|
11145 |
|
|
in Santa Cruz. It does not appear that this problem appears
|
11146 |
|
|
anywhere else in clauses 23 or 24.]</i></p>
|
11147 |
|
|
|
11148 |
|
|
<p><i>[Kona: In definition of operational semantics of back(), change
|
11149 |
|
|
"*tmp" to "return *tmp;"]</i></p>
|
11150 |
|
|
|
11151 |
|
|
<hr>
|
11152 |
|
|
<a name="358"></a><h3><a name="358">358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
|
11153 |
|
|
</a></h3><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p>
|
11154 |
|
|
<p>
|
11155 |
|
|
I don't think <tt>thousands_sep</tt> is being treated correctly after
|
11156 |
|
|
decimal_point has been seen. Since grouping applies only to the
|
11157 |
|
|
integral part of the number, the first such occurrence should, IMO,
|
11158 |
|
|
terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
|
11159 |
|
|
and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
|
11160 |
|
|
interpreted in the fractional part of a number.)
|
11161 |
|
|
</p>
|
11162 |
|
|
|
11163 |
|
|
<p>
|
11164 |
|
|
The easiest change I can think of that resolves this issue would be
|
11165 |
|
|
something like below.
|
11166 |
|
|
</p>
|
11167 |
|
|
<p><b>Proposed resolution:</b></p>
|
11168 |
|
|
<p>
|
11169 |
|
|
Change the first sentence of 22.2.2.1.2, p9 from
|
11170 |
|
|
</p>
|
11171 |
|
|
|
11172 |
|
|
<blockquote>
|
11173 |
|
|
If discard is true then the position of the character is
|
11174 |
|
|
remembered, but the character is otherwise ignored. If it is not
|
11175 |
|
|
discarded, then a check is made to determine if c is allowed as
|
11176 |
|
|
the next character of an input field of the conversion specifier
|
11177 |
|
|
returned by stage 1. If so it is accumulated.
|
11178 |
|
|
</blockquote>
|
11179 |
|
|
|
11180 |
|
|
<p>to</p>
|
11181 |
|
|
|
11182 |
|
|
<blockquote>
|
11183 |
|
|
If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
|
11184 |
|
|
accumulated, then the position of the character is remembered, but
|
11185 |
|
|
the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
|
11186 |
|
|
already been accumulated, the character is discarded and Stage 2
|
11187 |
|
|
terminates. ...
|
11188 |
|
|
</blockquote>
|
11189 |
|
|
|
11190 |
|
|
<p><b>Rationale:</b></p>
|
11191 |
|
|
<p>We believe this reflects the intent of the Standard. Thousands sep
|
11192 |
|
|
characters after the decimal point are not useful in any locale.
|
11193 |
|
|
Some formatting conventions do group digits that follow the decimal
|
11194 |
|
|
point, but they usually introduce a different grouping character
|
11195 |
|
|
instead of reusing the thousand sep character. If we want to add
|
11196 |
|
|
support for such conventions, we need to do so explicitly.</p>
|
11197 |
|
|
|
11198 |
|
|
<hr>
|
11199 |
|
|
<a name="359"><h3>359. num_put<>::do_put (..., bool) undocumented</h3></a><p><b>Section:</b> 22.2.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.members"> [lib.facet.num.put.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p>
|
11200 |
|
|
<p>22.2.2.2.1, p1:</p>
|
11201 |
|
|
|
11202 |
|
|
<pre> iter_type put (iter_type out, ios_base& str, char_type fill,
|
11203 |
|
|
bool val) const;
|
11204 |
|
|
...
|
11205 |
|
|
|
11206 |
|
|
1 Returns: do_put (out, str, fill, val).
|
11207 |
|
|
</pre>
|
11208 |
|
|
|
11209 |
|
|
<p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
|
11210 |
|
|
however, 22.2.2.2.2, p23:</p>
|
11211 |
|
|
|
11212 |
|
|
<blockquote>
|
11213 |
|
|
<pre>iter_type put (iter_type out, ios_base& str, char_type fill,
|
11214 |
|
|
bool val) const;
|
11215 |
|
|
</pre>
|
11216 |
|
|
|
11217 |
|
|
|
11218 |
|
|
Effects: If (str.flags() & ios_base::boolalpha) == 0 then do
|
11219 |
|
|
out = do_put(out, str, fill, (int)val)
|
11220 |
|
|
Otherwise do
|
11221 |
|
|
<pre> string_type s =
|
11222 |
|
|
val ? use_facet<ctype<charT> >(loc).truename()
|
11223 |
|
|
: use_facet<ctype<charT> >(loc).falsename();
|
11224 |
|
|
</pre>
|
11225 |
|
|
and then insert the characters of s into out. <i>out</i>.
|
11226 |
|
|
</blockquote>
|
11227 |
|
|
|
11228 |
|
|
<p>
|
11229 |
|
|
This means that the bool overload of <tt>do_put()</tt> will never be called,
|
11230 |
|
|
which contradicts the first paragraph. Perhaps the declaration
|
11231 |
|
|
should read <tt>do_put()</tt>, and not <tt>put()</tt>?
|
11232 |
|
|
</p>
|
11233 |
|
|
|
11234 |
|
|
<p>
|
11235 |
|
|
Note also that there is no <b>Returns</b> clause for this function, which
|
11236 |
|
|
should probably be corrected, just as should the second occurrence
|
11237 |
|
|
of <i>"out."</i> in the text.
|
11238 |
|
|
</p>
|
11239 |
|
|
|
11240 |
|
|
<p>
|
11241 |
|
|
I think the least invasive change to fix it would be something like
|
11242 |
|
|
the following:
|
11243 |
|
|
</p>
|
11244 |
|
|
<p><b>Proposed resolution:</b></p>
|
11245 |
|
|
<p>In 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, just above paragraph 1, remove
|
11246 |
|
|
the <tt>bool</tt> overload.</p>
|
11247 |
|
|
|
11248 |
|
|
<p>
|
11249 |
|
|
In 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, p23, make the following changes
|
11250 |
|
|
</p>
|
11251 |
|
|
|
11252 |
|
|
<blockquote>
|
11253 |
|
|
Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
|
11254 |
|
|
of the member function.
|
11255 |
|
|
</blockquote>
|
11256 |
|
|
|
11257 |
|
|
<blockquote>
|
11258 |
|
|
Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
|
11259 |
|
|
avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
|
11260 |
|
|
do_put (..., bool))</tt>
|
11261 |
|
|
like so:
|
11262 |
|
|
</blockquote>
|
11263 |
|
|
|
11264 |
|
|
<blockquote>
|
11265 |
|
|
23 <b>Returns</b>: If <tt>(str.flags() &
|
11266 |
|
|
ios_base::boolalpha) == 0</tt> then
|
11267 |
|
|
<tt>do_put (out, str, fill, (long)val)</tt>
|
11268 |
|
|
Otherwise the function obtains a string <tt>s</tt> as if by
|
11269 |
|
|
<pre> string_type s =
|
11270 |
|
|
val ? use_facet<ctype<charT> >(loc).truename()
|
11271 |
|
|
: use_facet<ctype<charT> >(loc).falsename();
|
11272 |
|
|
</pre>
|
11273 |
|
|
and then inserts each character <tt>c</tt> of s into out via
|
11274 |
|
|
<tt>*out++ = c</tt>
|
11275 |
|
|
and returns <tt>out</tt>.
|
11276 |
|
|
</blockquote>
|
11277 |
|
|
|
11278 |
|
|
<p><b>Rationale:</b></p>
|
11279 |
|
|
<p>
|
11280 |
|
|
This fixes a couple of obvious typos, and also fixes what appears to
|
11281 |
|
|
be a requirement of gratuitous inefficiency.
|
11282 |
|
|
</p>
|
11283 |
|
|
<hr>
|
11284 |
|
|
<a name="360"><h3>360. locale mandates inefficient implementation</h3></a><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p>
|
11285 |
|
|
<p>
|
11286 |
|
|
22.1.1, p7 (copied below) allows iostream formatters and extractors
|
11287 |
|
|
to make assumptions about the values returned from facet members.
|
11288 |
|
|
However, such assumptions are apparently not guaranteed to hold
|
11289 |
|
|
in other cases (e.g., when the facet members are being called directly
|
11290 |
|
|
rather than as a result of iostream calls, or between successive
|
11291 |
|
|
calls to the same iostream functions with no interevening calls to
|
11292 |
|
|
<tt>imbue()</tt>, or even when the facet member functions are called
|
11293 |
|
|
from other member functions of other facets). This restriction
|
11294 |
|
|
prevents locale from being implemented efficiently.
|
11295 |
|
|
</p>
|
11296 |
|
|
<p><b>Proposed resolution:</b></p>
|
11297 |
|
|
<p>Change the first sentence in 22.1.1, p7 from</p>
|
11298 |
|
|
<blockquote>
|
11299 |
|
|
In successive calls to a locale facet member function during
|
11300 |
|
|
a call to an iostream inserter or extractor or a streambuf member
|
11301 |
|
|
function, the returned result shall be identical. [Note: This
|
11302 |
|
|
implies that such results may safely be reused without calling
|
11303 |
|
|
the locale facet member function again, and that member functions
|
11304 |
|
|
of iostream classes cannot safely call <tt>imbue()</tt>
|
11305 |
|
|
themselves, except as specified elsewhere. --end note]
|
11306 |
|
|
</blockquote>
|
11307 |
|
|
|
11308 |
|
|
<p>to</p>
|
11309 |
|
|
|
11310 |
|
|
<blockquote>
|
11311 |
|
|
In successive calls to a locale facet member function on a facet
|
11312 |
|
|
object installed in the same locale, the returned result shall be
|
11313 |
|
|
identical. ...
|
11314 |
|
|
</blockquote>
|
11315 |
|
|
|
11316 |
|
|
<p><b>Rationale:</b></p>
|
11317 |
|
|
<p>This change is reasonable becuase it clarifies the intent of this
|
11318 |
|
|
part of the standard.</p>
|
11319 |
|
|
<hr>
|
11320 |
|
|
<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Walter Brown and Marc Paterno <b>Date:</b> 20 May 2002</p>
|
11321 |
|
|
<p>
|
11322 |
|
|
The destructor of ios_base::failure should have an empty throw
|
11323 |
|
|
specification, because the destructor of its base class, exception, is
|
11324 |
|
|
declared in this way.
|
11325 |
|
|
</p>
|
11326 |
|
|
<p><b>Proposed resolution:</b></p>
|
11327 |
|
|
<p>Change the destructor to</p>
|
11328 |
|
|
<pre> virtual ~failure() throw();
|
11329 |
|
|
</pre>
|
11330 |
|
|
<p><b>Rationale:</b></p>
|
11331 |
|
|
<p>Fixes an obvious glitch. This is almost editorial.</p>
|
11332 |
|
|
<hr>
|
11333 |
|
|
<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 10 May 2002</p>
|
11334 |
|
|
<p>
|
11335 |
|
|
27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> paragraph 1 is inconsistent with the Effects
|
11336 |
|
|
clause for seekoff.
|
11337 |
|
|
</p>
|
11338 |
|
|
<p><b>Proposed resolution:</b></p>
|
11339 |
|
|
<p>
|
11340 |
|
|
Make this paragraph, the Effects clause for setbuf, consistent in wording
|
11341 |
|
|
with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
|
11342 |
|
|
to indicate the purpose of setbuf:
|
11343 |
|
|
</p>
|
11344 |
|
|
|
11345 |
|
|
<p>Original text:</p>
|
11346 |
|
|
|
11347 |
|
|
<blockquote>
|
11348 |
|
|
1 Effects: Performs an operation that is defined separately for each
|
11349 |
|
|
class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
|
11350 |
|
|
</blockquote>
|
11351 |
|
|
|
11352 |
|
|
<p>Proposed text:</p>
|
11353 |
|
|
|
11354 |
|
|
<blockquote>
|
11355 |
|
|
1 Effects: Influences stream buffering in a way that is defined separately
|
11356 |
|
|
for each class derived from basic_streambuf in this clause
|
11357 |
|
|
(27.7.1.3, 27.8.1.4).
|
11358 |
|
|
</blockquote>
|
11359 |
|
|
|
11360 |
|
|
<p><b>Rationale:</b></p>
|
11361 |
|
|
<p>The LWG doesn't believe there is any normative difference between
|
11362 |
|
|
the existing wording and what's in the proposed resolution, but the
|
11363 |
|
|
change may make the intent clearer.</p>
|
11364 |
|
|
<hr>
|
11365 |
|
|
<a name="365"><h3>365. Lack of const-qualification in clause 27</h3></a><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 10 May 2002</p>
|
11366 |
|
|
<p>
|
11367 |
|
|
Some stream and streambuf member functions are declared non-const,
|
11368 |
|
|
even thought they appear only to report information rather than to
|
11369 |
|
|
change an object's logical state. They should be declared const. See
|
11370 |
|
|
document N1360 for details and rationale.
|
11371 |
|
|
</p>
|
11372 |
|
|
|
11373 |
|
|
<p>The list of member functions under discussion: <tt>in_avail</tt>,
|
11374 |
|
|
<tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
|
11375 |
|
|
|
11376 |
|
|
<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
|
11377 |
|
|
|
11378 |
|
|
<p><b>Proposed resolution:</b></p>
|
11379 |
|
|
<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>
|
11380 |
|
|
<p>Replace</p>
|
11381 |
|
|
<pre> bool is_open();
|
11382 |
|
|
</pre>
|
11383 |
|
|
<p>with</p>
|
11384 |
|
|
<pre> bool is_open() const;
|
11385 |
|
|
</pre>
|
11386 |
|
|
<p><b>Rationale:</b></p>
|
11387 |
|
|
<p>Of the changes proposed in N1360, the only one that is safe is
|
11388 |
|
|
changing the filestreams' is_open to const. The LWG believed that
|
11389 |
|
|
this was NAD the first time it considered this issue (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a>), but now thinks otherwise. The corresponding streambuf
|
11390 |
|
|
member function, after all,is already const.</p>
|
11391 |
|
|
|
11392 |
|
|
<p>The other proposed changes are less safe, because some streambuf
|
11393 |
|
|
functions that appear merely to report a value do actually perform
|
11394 |
|
|
mutating operations. It's not even clear that they should be
|
11395 |
|
|
considered "logically const", because streambuf has two interfaces, a
|
11396 |
|
|
public one and a protected one. These functions may, and often do,
|
11397 |
|
|
change the state as exposed by the protected interface, even if the
|
11398 |
|
|
state exposed by the public interface is unchanged.</p>
|
11399 |
|
|
|
11400 |
|
|
<p>Note that implementers can make this change in a binary compatible
|
11401 |
|
|
way by providing both overloads; this would be a conforming extension.</p>
|
11402 |
|
|
|
11403 |
|
|
<hr>
|
11404 |
|
|
<a name="370"><h3>370. Minor error in basic_istream::get</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 15 Jul 2002</p>
|
11405 |
|
|
<p>Defect report for description of basic_istream::get (section 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), paragraph 15. The description for the get function
|
11406 |
|
|
with the following signature:</p>
|
11407 |
|
|
|
11408 |
|
|
<pre> basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>&
|
11409 |
|
|
sb);
|
11410 |
|
|
</pre>
|
11411 |
|
|
|
11412 |
|
|
<p>is incorrect. It reads</p>
|
11413 |
|
|
|
11414 |
|
|
<blockquote>
|
11415 |
|
|
Effects: Calls get(s,n,widen('\n'))
|
11416 |
|
|
</blockquote>
|
11417 |
|
|
|
11418 |
|
|
<p>which I believe should be:</p>
|
11419 |
|
|
|
11420 |
|
|
<blockquote>
|
11421 |
|
|
Effects: Calls get(sb,widen('\n'))
|
11422 |
|
|
</blockquote>
|
11423 |
|
|
<p><b>Proposed resolution:</b></p>
|
11424 |
|
|
<p>Change the <b>Effects</b> paragraph to:</p>
|
11425 |
|
|
<blockquote>
|
11426 |
|
|
Effects: Calls get(sb,this->widen('\n'))
|
11427 |
|
|
</blockquote>
|
11428 |
|
|
|
11429 |
|
|
<p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
|
11430 |
|
|
with 'this->widen'.]</i></p>
|
11431 |
|
|
|
11432 |
|
|
<p><b>Rationale:</b></p>
|
11433 |
|
|
<p>Fixes an obvious typo.</p>
|
11434 |
|
|
<hr>
|
11435 |
|
|
<a name="373"></a><h3><a name="373">373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?</a></h3><p><b>Section:</b> 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>, 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Keith Baker <b>Date:</b> 23 Jul 2002</p>
|
11436 |
|
|
|
11437 |
|
|
<p>
|
11438 |
|
|
In 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>
|
11439 |
|
|
(exception()&badbit) != 0 is used in testing for rethrow, yet
|
11440 |
|
|
exception() is the constructor to class std::exception in 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.exception"> [lib.exception]</a> that has no return type. Should member function
|
11441 |
|
|
exceptions() found in 27.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios"> [lib.ios]</a> be used instead?
|
11442 |
|
|
</p>
|
11443 |
|
|
|
11444 |
|
|
<p><b>Proposed resolution:</b></p>
|
11445 |
|
|
<p>
|
11446 |
|
|
In 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>, change
|
11447 |
|
|
"(exception()&badbit) != 0" to "(exceptions()&badbit) != 0".
|
11448 |
|
|
</p>
|
11449 |
|
|
<p><b>Rationale:</b></p>
|
11450 |
|
|
<p>Fixes an obvious typo.</p>
|
11451 |
|
|
<hr>
|
11452 |
|
|
<a name="375"></a><h3><a name="375">375. basic_ios should be ios_base in 27.7.1.3</a></h3><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 14 Aug 2002</p>
|
11453 |
|
|
<p>
|
11454 |
|
|
In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>: Table 90, Table 91, and paragraph
|
11455 |
|
|
14 all contain references to "basic_ios::" which should be
|
11456 |
|
|
"ios_base::".
|
11457 |
|
|
</p>
|
11458 |
|
|
<p><b>Proposed resolution:</b></p>
|
11459 |
|
|
<p>
|
11460 |
|
|
Change all references to "basic_ios" in Table 90, Table 91, and
|
11461 |
|
|
paragraph 14 to "ios_base".
|
11462 |
|
|
</p>
|
11463 |
|
|
<p><b>Rationale:</b></p>
|
11464 |
|
|
<p>Fixes an obvious typo.</p>
|
11465 |
|
|
<hr>
|
11466 |
|
|
<a name="379"><h3>379. nonsensical ctype::do_widen() requirement</h3></a><p><b>Section:</b> 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
|
11467 |
|
|
<p>
|
11468 |
|
|
The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
|
11469 |
|
|
</p>
|
11470 |
|
|
<pre> charT do_widen (char c) const;
|
11471 |
|
|
|
11472 |
|
|
-11- Effects: Applies the simplest reasonable transformation from
|
11473 |
|
|
a char value or sequence of char values to the corresponding
|
11474 |
|
|
charT value or values. The only characters for which unique
|
11475 |
|
|
transformations are required are those in the basic source
|
11476 |
|
|
character set (2.2). For any named ctype category with a
|
11477 |
|
|
ctype<charT> facet ctw and valid ctype_base::mask value
|
11478 |
|
|
M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
|
11479 |
|
|
</pre>
|
11480 |
|
|
<p>
|
11481 |
|
|
Shouldn't the last sentence instead read
|
11482 |
|
|
</p>
|
11483 |
|
|
<pre> For any named ctype category with a ctype<char> facet ctc
|
11484 |
|
|
and valid ctype_base::mask value M
|
11485 |
|
|
(ctc.is(M, c) || !is(M, do_widen(c))) is true.
|
11486 |
|
|
</pre>
|
11487 |
|
|
<p>
|
11488 |
|
|
I.e., if the narrow character c is not a member of a class of
|
11489 |
|
|
characters then neither is the widened form of c. (To paraphrase
|
11490 |
|
|
footnote 224.)
|
11491 |
|
|
</p>
|
11492 |
|
|
<p><b>Proposed resolution:</b></p>
|
11493 |
|
|
<p>
|
11494 |
|
|
Replace the last sentence of 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>, p11 with the
|
11495 |
|
|
following text:
|
11496 |
|
|
</p>
|
11497 |
|
|
<pre> For any named ctype category with a ctype<char> facet ctc
|
11498 |
|
|
and valid ctype_base::mask value M,
|
11499 |
|
|
(ctc.is(M, c) || !is(M, do_widen(c))) is true.
|
11500 |
|
|
</pre>
|
11501 |
|
|
|
11502 |
|
|
<p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
|
11503 |
|
|
|
11504 |
|
|
<p><b>Rationale:</b></p>
|
11505 |
|
|
<p>The LWG believes this is just a typo, and that this is the correct fix.</p>
|
11506 |
|
|
<hr>
|
11507 |
|
|
<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="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
|
11508 |
|
|
<p>
|
11509 |
|
|
Tables 53 and 54 in 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> are both titled "convert
|
11510 |
|
|
result values," when surely "do_in/do_out result values" must have
|
11511 |
|
|
been intended for Table 53 and "do_unshift result values" for Table
|
11512 |
|
|
54.
|
11513 |
|
|
</p>
|
11514 |
|
|
<p>
|
11515 |
|
|
Table 54, row 3 says that the meaning of partial is "more characters
|
11516 |
|
|
needed to be supplied to complete termination." The function is not
|
11517 |
|
|
supplied any characters, it is given a buffer which it fills with
|
11518 |
|
|
characters or, more precisely, destination elements (i.e., an escape
|
11519 |
|
|
sequence). So partial means that space for more than (to_limit - to)
|
11520 |
|
|
destination elements was needed to terminate a sequence given the
|
11521 |
|
|
value of state.
|
11522 |
|
|
</p>
|
11523 |
|
|
<p><b>Proposed resolution:</b></p>
|
11524 |
|
|
<p>
|
11525 |
|
|
Change the title of Table 53 to "do_in/do_out result values" and
|
11526 |
|
|
the title of Table 54 to "do_unshift result values."
|
11527 |
|
|
</p>
|
11528 |
|
|
<p>
|
11529 |
|
|
Change the text in Table 54, row 3 (the <b>partial</b> row), under the
|
11530 |
|
|
heading Meaning, to "space for more than (to_limit - to) destination
|
11531 |
|
|
elements was needed to terminate a sequence given the value of state."
|
11532 |
|
|
</p>
|
11533 |
|
|
<hr>
|
11534 |
|
|
<a name="381"></a><h3><a name="381">381. detection of invalid mbstate_t in codecvt</a></h3><p><b>Section:</b> 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
|
11535 |
|
|
<p>
|
11536 |
|
|
All but one codecvt member functions that take a state_type argument
|
11537 |
|
|
list as one of their preconditions that the state_type argument have
|
11538 |
|
|
a valid value. However, according to 22.2.1.5.2, p6,
|
11539 |
|
|
codecvt::do_unshift() is the only codecvt member that is supposed to
|
11540 |
|
|
return error if the state_type object is invalid.
|
11541 |
|
|
</p>
|
11542 |
|
|
|
11543 |
|
|
<p>
|
11544 |
|
|
It seems to me that the treatment of state_type by all codecvt member
|
11545 |
|
|
functions should be the same and the current requirements should be
|
11546 |
|
|
changed. Since the detection of invalid state_type values may be
|
11547 |
|
|
difficult in general or computationally expensive in some specific
|
11548 |
|
|
cases, I propose the following:
|
11549 |
|
|
</p>
|
11550 |
|
|
<p><b>Proposed resolution:</b></p>
|
11551 |
|
|
<p>
|
11552 |
|
|
Add a new paragraph before 22.2.1.5.2, p5, and after the function
|
11553 |
|
|
declaration below
|
11554 |
|
|
</p>
|
11555 |
|
|
<pre> result do_unshift(stateT& state,
|
11556 |
|
|
externT* to, externT* to_limit, externT*& to_next) const;
|
11557 |
|
|
</pre>
|
11558 |
|
|
<p>
|
11559 |
|
|
as follows:
|
11560 |
|
|
</p>
|
11561 |
|
|
<pre> Requires: (to <= to_end) well defined and true; state initialized,
|
11562 |
|
|
if at the beginning of a sequence, or else equal to the result of
|
11563 |
|
|
converting the preceding characters in the sequence.
|
11564 |
|
|
</pre>
|
11565 |
|
|
<p>
|
11566 |
|
|
and change the text in Table 54, row 4, the <b>error</b> row, under
|
11567 |
|
|
the heading Meaning, from
|
11568 |
|
|
</p>
|
11569 |
|
|
<pre> state has invalid value
|
11570 |
|
|
</pre>
|
11571 |
|
|
<p>
|
11572 |
|
|
to
|
11573 |
|
|
</p>
|
11574 |
|
|
<pre> an unspecified error has occurred
|
11575 |
|
|
</pre>
|
11576 |
|
|
<p><b>Rationale:</b></p>
|
11577 |
|
|
<p>The intent is that implementations should not be required to detect
|
11578 |
|
|
invalid state values; such a requirement appears nowhere else. An
|
11579 |
|
|
invalid state value is a precondition violation, <i>i.e.</i> undefined
|
11580 |
|
|
behavior. Implementations that do choose to detect invalid state
|
11581 |
|
|
values, or that choose to detect any other kind of error, may return
|
11582 |
|
|
<b>error</b> as an indication.</p>
|
11583 |
|
|
<hr>
|
11584 |
|
|
<a name="383"><h3>383. Bidirectional iterator assertion typo</h3></a><p><b>Section:</b> 24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Date:</b> 17 Oct 2002</p>
|
11585 |
|
|
<p>
|
11586 |
|
|
Following a discussion on the boost list regarding end iterators and
|
11587 |
|
|
the possibility of performing operator--() on them, it seems to me
|
11588 |
|
|
that there is a typo in the standard. This typo has nothing to do
|
11589 |
|
|
with that discussion.
|
11590 |
|
|
</p>
|
11591 |
|
|
|
11592 |
|
|
<p>
|
11593 |
|
|
I have checked this newsgroup, as well as attempted a search of the
|
11594 |
|
|
Active/Defect/Closed Issues List on the site for the words "s is
|
11595 |
|
|
derefer" so I believe this has not been proposed before. Furthermore,
|
11596 |
|
|
the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> on section
|
11597 |
|
|
24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> is not related to this issue.
|
11598 |
|
|
</p>
|
11599 |
|
|
|
11600 |
|
|
<p>
|
11601 |
|
|
The standard makes the following assertion on bidirectional iterators,
|
11602 |
|
|
in section 24.1.4 [lib.bidirectional.iterators], Table 75:
|
11603 |
|
|
</p>
|
11604 |
|
|
|
11605 |
|
|
<pre> operational assertion/note
|
11606 |
|
|
expression return type semantics pre/post-condition
|
11607 |
|
|
|
11608 |
|
|
--r X& pre: there exists s such
|
11609 |
|
|
that r == ++s.
|
11610 |
|
|
post: s is dereferenceable.
|
11611 |
|
|
--(++r) == r.
|
11612 |
|
|
--r == --s implies r == s.
|
11613 |
|
|
&r == &--r.
|
11614 |
|
|
</pre>
|
11615 |
|
|
|
11616 |
|
|
<p>
|
11617 |
|
|
(See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
|
11618 |
|
|
</p>
|
11619 |
|
|
|
11620 |
|
|
<p>
|
11621 |
|
|
In particular, "s is dereferenceable" seems to be in error. It seems
|
11622 |
|
|
that the intention was to say "r is dereferenceable".
|
11623 |
|
|
</p>
|
11624 |
|
|
|
11625 |
|
|
<p>
|
11626 |
|
|
If it were to say "r is dereferenceable" it would
|
11627 |
|
|
make perfect sense. Since s must be dereferenceable prior to
|
11628 |
|
|
operator++, then the natural result of operator-- (to undo operator++)
|
11629 |
|
|
would be to make r dereferenceable. Furthermore, without other
|
11630 |
|
|
assertions, and basing only on precondition and postconditions, we
|
11631 |
|
|
could not otherwise know this. So it is also interesting information.
|
11632 |
|
|
</p>
|
11633 |
|
|
|
11634 |
|
|
<p><b>Proposed resolution:</b></p>
|
11635 |
|
|
<p>
|
11636 |
|
|
Change the guarantee to "postcondition: r is dereferenceable."
|
11637 |
|
|
</p>
|
11638 |
|
|
<p><b>Rationale:</b></p>
|
11639 |
|
|
<p>Fixes an obvious typo</p>
|
11640 |
|
|
<hr>
|
11641 |
|
|
<a name="386"><h3>386. Reverse iterator's operator[] has impossible return type</h3></a><p><b>Section:</b> 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Oct 2002</p>
|
11642 |
|
|
<p>In 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>, <tt>reverse_iterator<>::operator[]</tt>
|
11643 |
|
|
is specified as having a return type of <tt>reverse_iterator::reference</tt>,
|
11644 |
|
|
which is the same as <tt>iterator_traits<Iterator>::reference</tt>.
|
11645 |
|
|
(Where <tt>Iterator</tt> is the underlying iterator type.)</p>
|
11646 |
|
|
|
11647 |
|
|
<p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
|
11648 |
|
|
necessarily have a return type
|
11649 |
|
|
of <tt>iterator_traits<Iterator>::reference</tt>. Its
|
11650 |
|
|
return type is merely required to be convertible
|
11651 |
|
|
to <tt>Iterator</tt>'s value type. The return type specified for
|
11652 |
|
|
reverse_iterator's operator[] would thus appear to be impossible.</p>
|
11653 |
|
|
|
11654 |
|
|
<p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, the type of
|
11655 |
|
|
<tt>a[n]</tt> will continue to be required (for random access
|
11656 |
|
|
iterators) to be convertible to the value type, and also <tt>a[n] =
|
11657 |
|
|
t</tt> will be a valid expression. Implementations of
|
11658 |
|
|
<tt>reverse_iterator</tt> will likely need to return a proxy from
|
11659 |
|
|
<tt>operator[]</tt> to meet these requirements. As mentioned in the
|
11660 |
|
|
comment from Dave Abrahams, the simplest way to specify that
|
11661 |
|
|
<tt>reverse_iterator</tt> meet this requirement to just mandate
|
11662 |
|
|
it and leave the return type of <tt>operator[]</tt> unspecified.</p>
|
11663 |
|
|
|
11664 |
|
|
<p><b>Proposed resolution:</b></p>
|
11665 |
|
|
|
11666 |
|
|
<p>In 24.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.requirements"> [lib.reverse.iter.requirements]</a> change:</p>
|
11667 |
|
|
|
11668 |
|
|
<blockquote>
|
11669 |
|
|
<pre>reference operator[](difference_type n) const;
|
11670 |
|
|
</pre>
|
11671 |
|
|
</blockquote>
|
11672 |
|
|
|
11673 |
|
|
<p>to:</p>
|
11674 |
|
|
|
11675 |
|
|
<blockquote>
|
11676 |
|
|
<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see <font color="red">lib.random.access.iterators</font>
|
11677 |
|
|
</pre>
|
11678 |
|
|
</blockquote>
|
11679 |
|
|
|
11680 |
|
|
|
11681 |
|
|
|
11682 |
|
|
|
11683 |
|
|
<p><i>[
|
11684 |
|
|
Comments from Dave Abrahams: IMO we should resolve 386 by just saying
|
11685 |
|
|
that the return type of reverse_iterator's operator[] is
|
11686 |
|
|
unspecified, allowing the random access iterator requirements to
|
11687 |
|
|
impose an appropriate return type. If we accept 299's proposed
|
11688 |
|
|
resolution (and I think we should), the return type will be
|
11689 |
|
|
readable and writable, which is about as good as we can do.
|
11690 |
|
|
]</i></p>
|
11691 |
|
|
<hr>
|
11692 |
|
|
<a name="389"><h3>389. Const overload of valarray::operator[] returns by value</h3></a><p><b>Section:</b> 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 8 Nov 2002</p>
|
11693 |
|
|
<p>Consider the following program:</p>
|
11694 |
|
|
<pre> #include <iostream>
|
11695 |
|
|
#include <ostream>
|
11696 |
|
|
#include <vector>
|
11697 |
|
|
#include <valarray>
|
11698 |
|
|
#include <algorithm>
|
11699 |
|
|
#include <iterator>
|
11700 |
|
|
template<typename Array>
|
11701 |
|
|
void print(const Array& a)
|
11702 |
|
|
{
|
11703 |
|
|
using namespace std;
|
11704 |
|
|
typedef typename Array::value_type T;
|
11705 |
|
|
copy(&a[0], &a[0] + a.size(),
|
11706 |
|
|
ostream_iterator<T>(std::cout, " "));
|
11707 |
|
|
}
|
11708 |
|
|
template<typename T, unsigned N>
|
11709 |
|
|
unsigned size(T(&)[N]) { return N; }
|
11710 |
|
|
int main()
|
11711 |
|
|
{
|
11712 |
|
|
double array[] = { 0.89, 9.3, 7, 6.23 };
|
11713 |
|
|
std::vector<double> v(array, array + size(array));
|
11714 |
|
|
std::valarray<double> w(array, size(array));
|
11715 |
|
|
print(v); // #1
|
11716 |
|
|
std::cout << std::endl;
|
11717 |
|
|
print(w); // #2
|
11718 |
|
|
std::cout << std::endl;
|
11719 |
|
|
}
|
11720 |
|
|
</pre>
|
11721 |
|
|
|
11722 |
|
|
<p>While the call numbered #1 succeeds, the call numbered #2 fails
|
11723 |
|
|
because the const version of the member function
|
11724 |
|
|
valarray<T>::operator[](size_t) returns a value instead of a
|
11725 |
|
|
const-reference. That seems to be so for no apparent reason, no
|
11726 |
|
|
benefit. Not only does that defeats users' expectation but it also
|
11727 |
|
|
does hinder existing software (written either in C or Fortran)
|
11728 |
|
|
integration within programs written in C++. There is no reason why
|
11729 |
|
|
subscripting an expression of type valarray<T> that is const-qualified
|
11730 |
|
|
should not return a const T&.</p>
|
11731 |
|
|
<p><b>Proposed resolution:</b></p>
|
11732 |
|
|
<p>In the class synopsis in 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>, and in
|
11733 |
|
|
26.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a> just above paragraph 1, change</p>
|
11734 |
|
|
<pre> T operator[](size_t const);
|
11735 |
|
|
</pre>
|
11736 |
|
|
<p>to</p>
|
11737 |
|
|
<pre> const T& operator[](size_t const);
|
11738 |
|
|
</pre>
|
11739 |
|
|
|
11740 |
|
|
<p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
|
11741 |
|
|
wehre it belongs.]</i></p>
|
11742 |
|
|
|
11743 |
|
|
<p><b>Rationale:</b></p>
|
11744 |
|
|
<p>Return by value seems to serve no purpose. Valaray was explicitly
|
11745 |
|
|
designed to have a specified layout so that it could easily be
|
11746 |
|
|
integrated with libraries in other languages, and return by value
|
11747 |
|
|
defeats that purpose. It is believed that this change will have no
|
11748 |
|
|
impact on allowable optimizations.</p>
|
11749 |
|
|
<hr>
|
11750 |
|
|
<a name="391"><h3>391. non-member functions specified as const</h3></a><p><b>Section:</b> 22.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.conversions"> [lib.conversions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> James Kanze <b>Date:</b> 10 Dec 2002</p>
|
11751 |
|
|
<p>
|
11752 |
|
|
The specifications of toupper and tolower both specify the functions as
|
11753 |
|
|
const, althought they are not member functions, and are not specified as
|
11754 |
|
|
const in the header file synopsis in section 22.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locales"> [lib.locales]</a>.
|
11755 |
|
|
</p>
|
11756 |
|
|
<p><b>Proposed resolution:</b></p>
|
11757 |
|
|
<p>In 22.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.conversions"> [lib.conversions]</a>, remove <tt>const</tt> from the function
|
11758 |
|
|
declarations of std::toupper and std::tolower</p>
|
11759 |
|
|
<p><b>Rationale:</b></p>
|
11760 |
|
|
<p>Fixes an obvious typo</p>
|
11761 |
|
|
<hr>
|
11762 |
|
|
<a name="395"><h3>395. inconsistencies in the definitions of rand() and random_shuffle()</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> James Kanze <b>Date:</b> 3 Jan 2003</p>
|
11763 |
|
|
<p>
|
11764 |
|
|
In 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a>, the C++ standard refers to the C standard for the
|
11765 |
|
|
definition of rand(); in the C standard, it is written that "The
|
11766 |
|
|
implementation shall behave as if no library function calls the rand
|
11767 |
|
|
function."
|
11768 |
|
|
</p>
|
11769 |
|
|
|
11770 |
|
|
<p>
|
11771 |
|
|
In 25.2.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.random.shuffle"> [lib.alg.random.shuffle]</a>, there is no specification as to
|
11772 |
|
|
how the two parameter version of the function generates its random
|
11773 |
|
|
value. I believe that all current implementations in fact call rand()
|
11774 |
|
|
(in contradiction with the requirement avove); if an implementation does
|
11775 |
|
|
not call rand(), there is the question of how whatever random generator
|
11776 |
|
|
it does use is seeded. Something is missing.
|
11777 |
|
|
</p>
|
11778 |
|
|
|
11779 |
|
|
<p><b>Proposed resolution:</b></p>
|
11780 |
|
|
<p>
|
11781 |
|
|
In [lib.c.math], add a paragraph specifying that the C definition of
|
11782 |
|
|
rand shal be modified to say that "Unless otherwise specified, the
|
11783 |
|
|
implementation shall behave as if no library function calls the rand
|
11784 |
|
|
function."
|
11785 |
|
|
</p>
|
11786 |
|
|
|
11787 |
|
|
<p>
|
11788 |
|
|
In [lib.alg.random.shuffle], add a sentence to the effect that "In
|
11789 |
|
|
the two argument form of the function, the underlying source of
|
11790 |
|
|
random numbers is implementation defined. [Note: in particular, an
|
11791 |
|
|
implementation is permitted to use <tt>rand</tt>.]
|
11792 |
|
|
</p>
|
11793 |
|
|
<p><b>Rationale:</b></p>
|
11794 |
|
|
<p>The original proposed resolution proposed requiring the
|
11795 |
|
|
two-argument from of <tt>random_shuffle</tt> to
|
11796 |
|
|
use <tt>rand</tt>. We don't want to do that, because some existing
|
11797 |
|
|
implementations already use something else: gcc
|
11798 |
|
|
uses <tt>lrand48</tt>, for example. Using <tt>rand</tt> presents a
|
11799 |
|
|
problem if the number of elements in the sequence is greater than
|
11800 |
|
|
RAND_MAX.</p>
|
11801 |
|
|
<hr>
|
11802 |
|
|
<a name="400"><h3>400. redundant type cast in lib.allocator.members</h3></a><p><b>Section:</b> 20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 27 Feb 2003</p>
|
11803 |
|
|
<p>
|
11804 |
|
|
20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> allocator members, contains
|
11805 |
|
|
the following 3 lines:
|
11806 |
|
|
</p>
|
11807 |
|
|
|
11808 |
|
|
<pre> 12 Returns: new((void *) p) T( val)
|
11809 |
|
|
void destroy(pointer p);
|
11810 |
|
|
13 Returns: ((T*) p)->~T()
|
11811 |
|
|
</pre>
|
11812 |
|
|
|
11813 |
|
|
<p>
|
11814 |
|
|
The type cast "(T*) p" in the last line is redundant cause
|
11815 |
|
|
we know that std::allocator<T>::pointer is a typedef for T*.
|
11816 |
|
|
</p>
|
11817 |
|
|
<p><b>Proposed resolution:</b></p>
|
11818 |
|
|
<p>
|
11819 |
|
|
Replace "((T*) p)" with "p".
|
11820 |
|
|
</p>
|
11821 |
|
|
<p><b>Rationale:</b></p>
|
11822 |
|
|
<p>Just a typo, this is really editorial.</p>
|
11823 |
|
|
<hr>
|
11824 |
|
|
<a name="402"><h3>402. wrong new expression in [some_]allocator::construct</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>, <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 27 Feb 2003</p>
|
11825 |
|
|
<p>
|
11826 |
|
|
This applies to the new expression that is contained in both par12 of
|
11827 |
|
|
20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> and in par2 (table 32) of 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>.
|
11828 |
|
|
I think this new expression is wrong, involving unintended side
|
11829 |
|
|
effects.
|
11830 |
|
|
</p>
|
11831 |
|
|
|
11832 |
|
|
|
11833 |
|
|
<p>20.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a> contains the following 3 lines:</p>
|
11834 |
|
|
|
11835 |
|
|
<pre> 11 Returns: the largest value N for which the call allocate(N,0) might succeed.
|
11836 |
|
|
void construct(pointer p, const_reference val);
|
11837 |
|
|
12 Returns: new((void *) p) T( val)
|
11838 |
|
|
</pre>
|
11839 |
|
|
|
11840 |
|
|
|
11841 |
|
|
<p>20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> in table 32 has the following line:</p>
|
11842 |
|
|
<pre> a.construct(p,t) Effect: new((void*)p) T(t)
|
11843 |
|
|
</pre>
|
11844 |
|
|
|
11845 |
|
|
<p>
|
11846 |
|
|
.... with the prerequisits coming from the preceding two paragraphs,
|
11847 |
|
|
especially from table 31:
|
11848 |
|
|
</p>
|
11849 |
|
|
|
11850 |
|
|
<pre> alloc<T> a ;// an allocator for T
|
11851 |
|
|
alloc<T>::pointer p ;// random access iterator
|
11852 |
|
|
// (may be different from T*)
|
11853 |
|
|
alloc<T>::reference r = *p;// T&
|
11854 |
|
|
T const& t ;
|
11855 |
|
|
</pre>
|
11856 |
|
|
|
11857 |
|
|
<p>
|
11858 |
|
|
Cause of using "new" but not "::new", any existing "T::operator new"
|
11859 |
|
|
function will hide the global placement new function. When there is no
|
11860 |
|
|
"T::operator new" with adequate signature,
|
11861 |
|
|
every_alloc<T>::construct(..) is ill-formed, and most
|
11862 |
|
|
std::container<T,every_alloc<T>> use it; a workaround
|
11863 |
|
|
would be adding placement new and delete functions with adequate
|
11864 |
|
|
signature and semantic to class T, but class T might come from another
|
11865 |
|
|
party. Maybe even worse is the case when T has placement new and
|
11866 |
|
|
delete functions with adequate signature but with "unknown" semantic:
|
11867 |
|
|
I dont like to speculate about it, but whoever implements
|
11868 |
|
|
any_container<T,any_alloc> and wants to use construct(..)
|
11869 |
|
|
probably must think about it.
|
11870 |
|
|
</p>
|
11871 |
|
|
<p><b>Proposed resolution:</b></p>
|
11872 |
|
|
<p>
|
11873 |
|
|
Replace "new" with "::new" in both cases.
|
11874 |
|
|
</p>
|
11875 |
|
|
<hr>
|
11876 |
|
|
<a name="403"><h3>403. basic_string::swap should not throw exceptions</h3></a><p><b>Section:</b> 21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::swap"> [lib.string::swap]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 25 Mar 2003</p>
|
11877 |
|
|
|
11878 |
|
|
<p>
|
11879 |
|
|
std::basic_string, 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 2 says that
|
11880 |
|
|
basic_string "conforms to the requirements of a Sequence, as specified
|
11881 |
|
|
in (23.1.1)." The sequence requirements specified in (23.1.1) to not
|
11882 |
|
|
include any prohibition on swap members throwing exceptions.
|
11883 |
|
|
</p>
|
11884 |
|
|
|
11885 |
|
|
<p>
|
11886 |
|
|
Section 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 does limit conditions under
|
11887 |
|
|
which exceptions may be thrown, but applies only to "all container
|
11888 |
|
|
types defined in this clause" and so excludes basic_string::swap
|
11889 |
|
|
because it is defined elsewhere.
|
11890 |
|
|
</p>
|
11891 |
|
|
|
11892 |
|
|
<p>
|
11893 |
|
|
Eric Niebler points out that 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 5 explicitly
|
11894 |
|
|
permits basic_string::swap to invalidates iterators, which is
|
11895 |
|
|
disallowed by 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10. Thus the standard would
|
11896 |
|
|
be contradictory if it were read or extended to read as having
|
11897 |
|
|
basic_string meet 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 requirements.
|
11898 |
|
|
</p>
|
11899 |
|
|
|
11900 |
|
|
<p>
|
11901 |
|
|
Yet several LWG members have expressed the belief that the original
|
11902 |
|
|
intent was that basic_string::swap should not throw exceptions as
|
11903 |
|
|
specified by 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10, and that the standard is
|
11904 |
|
|
unclear on this issue. The complexity of basic_string::swap is
|
11905 |
|
|
specified as "constant time", indicating the intent was to avoid
|
11906 |
|
|
copying (which could cause a bad_alloc or other exception). An
|
11907 |
|
|
important use of swap is to ensure that exceptions are not thrown in
|
11908 |
|
|
exception-safe code.
|
11909 |
|
|
</p>
|
11910 |
|
|
|
11911 |
|
|
<p>
|
11912 |
|
|
Note: There remains long standing concern over whether or not it is
|
11913 |
|
|
possible to reasonably meet the 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 swap
|
11914 |
|
|
requirements when allocators are unequal. The specification of
|
11915 |
|
|
basic_string::swap exception requirements is in no way intended to
|
11916 |
|
|
address, prejudice, or otherwise impact that concern.
|
11917 |
|
|
</p>
|
11918 |
|
|
|
11919 |
|
|
|
11920 |
|
|
|
11921 |
|
|
|
11922 |
|
|
|
11923 |
|
|
<p><b>Proposed resolution:</b></p>
|
11924 |
|
|
<p>
|
11925 |
|
|
In 21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::swap"> [lib.string::swap]</a>, add a throws clause:
|
11926 |
|
|
</p>
|
11927 |
|
|
|
11928 |
|
|
<p>
|
11929 |
|
|
Throws: Shall not throw exceptions.
|
11930 |
|
|
</p>
|
11931 |
|
|
<hr>
|
11932 |
|
|
<a name="404"><h3>404. May a replacement allocation function be declared inline?</h3></a><p><b>Section:</b> 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 24 Apr 2003</p>
|
11933 |
|
|
<p>
|
11934 |
|
|
The eight basic dynamic memory allocation functions (single-object
|
11935 |
|
|
and array versions of ::operator new and ::operator delete, in the
|
11936 |
|
|
ordinary and nothrow forms) are replaceable. A C++ program may
|
11937 |
|
|
provide an alternative definition for any of them, which will be used
|
11938 |
|
|
in preference to the implementation's definition.
|
11939 |
|
|
</p>
|
11940 |
|
|
|
11941 |
|
|
<p>
|
11942 |
|
|
Three different parts of the standard mention requirements on
|
11943 |
|
|
replacement functions: 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>
|
11944 |
|
|
and 18.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>, and 3.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.stc.dynamic"> [basic.stc.dynamic]</a>.
|
11945 |
|
|
</p>
|
11946 |
|
|
|
11947 |
|
|
<p>None of these three places say whether a replacement function may
|
11948 |
|
|
be declared inline. 18.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> paragraph 2 specifies a
|
11949 |
|
|
signature for the replacement function, but that's not enough:
|
11950 |
|
|
the <tt>inline</tt> specifier is not part of a function's signature.
|
11951 |
|
|
One might also reason from 7.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.fct.spec"> [dcl.fct.spec]</a> paragraph 2, which
|
11952 |
|
|
requires that "an inline function shall be defined in every
|
11953 |
|
|
translation unit in which it is used," but this may not be quite
|
11954 |
|
|
specific enough either. We should either explicitly allow or
|
11955 |
|
|
explicitly forbid inline replacement memory allocation
|
11956 |
|
|
functions.</p>
|
11957 |
|
|
<p><b>Proposed resolution:</b></p>
|
11958 |
|
|
<p>
|
11959 |
|
|
Add a new sentence to the end of 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 3:
|
11960 |
|
|
"The program's definitions shall not be specified as <tt>inline</tt>.
|
11961 |
|
|
No diagnostic is required."
|
11962 |
|
|
</p>
|
11963 |
|
|
|
11964 |
|
|
<p><i>[Kona: added "no diagnostic is required"]</i></p>
|
11965 |
|
|
|
11966 |
|
|
<p><b>Rationale:</b></p>
|
11967 |
|
|
<p>
|
11968 |
|
|
The fact that <tt>inline</tt> isn't mentioned appears to have been
|
11969 |
|
|
nothing more than an oversight. Existing implementations do not
|
11970 |
|
|
permit inline functions as replacement memory allocation functions.
|
11971 |
|
|
Providing this functionality would be difficult in some cases, and is
|
11972 |
|
|
believed to be of limited value.
|
11973 |
|
|
</p>
|
11974 |
|
|
<hr>
|
11975 |
|
|
<a name="405"><h3>405. qsort and POD</h3></a><p><b>Section:</b> 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 08 Apr 2003</p>
|
11976 |
|
|
<p>
|
11977 |
|
|
Section 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> describes bsearch and qsort, from the C
|
11978 |
|
|
standard library. Paragraph 4 does not list any restrictions on qsort,
|
11979 |
|
|
but it should limit the base parameter to point to POD. Presumably,
|
11980 |
|
|
qsort sorts the array by copying bytes, which requires POD.
|
11981 |
|
|
</p>
|
11982 |
|
|
<p><b>Proposed resolution:</b></p>
|
11983 |
|
|
<p>
|
11984 |
|
|
In 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> paragraph 4, just after the declarations and
|
11985 |
|
|
before the nonnormative note, add these words: "both of which have the
|
11986 |
|
|
same behavior as the original declaration. The behavior is undefined
|
11987 |
|
|
unless the objects in the array pointed to by <i>base</i> are of POD
|
11988 |
|
|
type."
|
11989 |
|
|
</p>
|
11990 |
|
|
|
11991 |
|
|
<p><i>[Something along these lines is clearly necessary. Matt
|
11992 |
|
|
provided wording.]</i></p>
|
11993 |
|
|
<hr>
|
11994 |
|
|
<a name="406"><h3>406. vector::insert(s) exception safety</h3></a><p><b>Section:</b> 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 27 Apr 2003</p>
|
11995 |
|
|
<p>
|
11996 |
|
|
There is a possible defect in the standard: the standard text was
|
11997 |
|
|
never intended to prevent arbitrary ForwardIterators, whose operations
|
11998 |
|
|
may throw exceptions, from being passed, and it also wasn't intended
|
11999 |
|
|
to require a temporary buffer in the case where ForwardIterators were
|
12000 |
|
|
passed (and I think most implementations don't use one). As is, the
|
12001 |
|
|
standard appears to impose requirements that aren't met by any
|
12002 |
|
|
existing implementation.
|
12003 |
|
|
</p>
|
12004 |
|
|
<p><b>Proposed resolution:</b></p>
|
12005 |
|
|
<p>Replace 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> paragraph 1 with:</p>
|
12006 |
|
|
<blockquote>
|
12007 |
|
|
1- Notes: Causes reallocation if the new size is greater than the
|
12008 |
|
|
old capacity. If no reallocation happens, all the iterators and
|
12009 |
|
|
references before the insertion point remain valid. If an exception
|
12010 |
|
|
is thrown other than by the copy constructor or assignment operator
|
12011 |
|
|
of T or by any InputIterator operation there are no effects.
|
12012 |
|
|
</blockquote>
|
12013 |
|
|
|
12014 |
|
|
<p><i>[We probably need to say something similar for deque.]</i></p>
|
12015 |
|
|
|
12016 |
|
|
<hr>
|
12017 |
|
|
<a name="407"><h3>407. Can singular iterators be destroyed?</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 3 June 2003</p>
|
12018 |
|
|
<p>
|
12019 |
|
|
Clause 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>, paragraph 5, says that the only expression
|
12020 |
|
|
that is defined for a singular iterator is "an assignment of a
|
12021 |
|
|
non-singular value to an iterator that holds a singular value". This
|
12022 |
|
|
means that destroying a singular iterator (e.g. letting an automatic
|
12023 |
|
|
variable go out of scope) is technically undefined behavior. This
|
12024 |
|
|
seems overly strict, and probably unintentional.
|
12025 |
|
|
</p>
|
12026 |
|
|
<p><b>Proposed resolution:</b></p>
|
12027 |
|
|
<p>
|
12028 |
|
|
Change the sentence in question to "... the only exceptions are
|
12029 |
|
|
destroying an iterator that holds a singular value, or the assignment
|
12030 |
|
|
of a non-singular value to an iterator that holds a singular value."
|
12031 |
|
|
</p>
|
12032 |
|
|
<hr>
|
12033 |
|
|
<a name="409"><h3>409. Closing an fstream should clear error state</h3></a><p><b>Section:</b> 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 3 June 2003</p>
|
12034 |
|
|
<p>
|
12035 |
|
|
A strict reading of 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> shows that opening or
|
12036 |
|
|
closing a basic_[io]fstream does not affect the error bits. This
|
12037 |
|
|
means, for example, that if you read through a file up to EOF, and
|
12038 |
|
|
then close the stream and reopen it at the beginning of the file,
|
12039 |
|
|
the EOF bit in the stream's error state is still set. This is
|
12040 |
|
|
counterintuitive.
|
12041 |
|
|
</p>
|
12042 |
|
|
<p>
|
12043 |
|
|
The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>,
|
12044 |
|
|
and put in a footnote to clarify that the strict reading was indeed
|
12045 |
|
|
correct. We did that because we believed the standard was
|
12046 |
|
|
unambiguous and consistent, and that we should not make architectural
|
12047 |
|
|
changes in a TC. Now that we're working on a new revision of the
|
12048 |
|
|
language, those considerations no longer apply.
|
12049 |
|
|
</p>
|
12050 |
|
|
<p><b>Proposed resolution:</b></p>
|
12051 |
|
|
|
12052 |
|
|
<p>Change 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, para. 3 from:</p>
|
12053 |
|
|
|
12054 |
|
|
<blockquote>
|
12055 |
|
|
Calls rdbuf()->open(s,mode|in). If that function returns a null
|
12056 |
|
|
pointer, calls setstate(failbit) (which may throw ios_base::failure
|
12057 |
|
|
[Footnote: (lib.iostate.flags)].
|
12058 |
|
|
</blockquote>
|
12059 |
|
|
|
12060 |
|
|
<p>to:</p>
|
12061 |
|
|
|
12062 |
|
|
<blockquote>Calls rdbuf()->open(s,mode|in). If that function returns
|
12063 |
|
|
a null pointer, calls setstate(failbit) (which may throw
|
12064 |
|
|
ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
|
12065 |
|
|
</blockquote>
|
12066 |
|
|
|
12067 |
|
|
<p>Change 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a>, para. 3 from:</p>
|
12068 |
|
|
|
12069 |
|
|
<blockquote>Calls rdbuf()->open(s,mode|out). If that function
|
12070 |
|
|
returns a null pointer, calls setstate(failbit) (which may throw
|
12071 |
|
|
ios_base::failure [Footnote: (lib.iostate.flags)).
|
12072 |
|
|
</blockquote>
|
12073 |
|
|
|
12074 |
|
|
<p>to:</p>
|
12075 |
|
|
|
12076 |
|
|
<blockquote>Calls rdbuf()->open(s,mode|out). If that function
|
12077 |
|
|
returns a null pointer, calls setstate(failbit) (which may throw
|
12078 |
|
|
ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
|
12079 |
|
|
</blockquote>
|
12080 |
|
|
|
12081 |
|
|
<p>Change 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, para. 3 from:</p>
|
12082 |
|
|
|
12083 |
|
|
<blockquote>Calls rdbuf()->open(s,mode), If that function returns a
|
12084 |
|
|
null pointer, calls setstate(failbit), (which may throw
|
12085 |
|
|
ios_base::failure). (lib.iostate.flags) )
|
12086 |
|
|
</blockquote>
|
12087 |
|
|
|
12088 |
|
|
<p>to:</p>
|
12089 |
|
|
|
12090 |
|
|
<blockquote>Calls rdbuf()->open(s,mode), If that function returns a
|
12091 |
|
|
null pointer, calls setstate(failbit), (which may throw
|
12092 |
|
|
ios_base::failure). (lib.iostate.flags) ), else calls clear().
|
12093 |
|
|
</blockquote>
|
12094 |
|
|
|
12095 |
|
|
|
12096 |
|
|
|
12097 |
|
|
<p><i>[Kona: the LWG agrees this is a good idea. Post-Kona: Bill
|
12098 |
|
|
provided wording. He suggests having open, not close, clear the error
|
12099 |
|
|
flags.]</i></p>
|
12100 |
|
|
|
12101 |
|
|
<p><i>[Post-Sydney: Howard provided a new proposed resolution. The
|
12102 |
|
|
old one didn't make sense because it proposed to fix this at the
|
12103 |
|
|
level of basic_filebuf, which doesn't have access to the stream's
|
12104 |
|
|
error state. Howard's proposed resolution fixes this at the level
|
12105 |
|
|
of the three fstream class template instead.]</i></p>
|
12106 |
|
|
|
12107 |
|
|
<hr>
|
12108 |
|
|
<a name="410"><h3>410. Missing semantics for stack and queue comparison operators</h3></a><p><b>Section:</b> 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 7 Jun 2003</p>
|
12109 |
|
|
<p>
|
12110 |
|
|
Sections 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a> and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> list
|
12111 |
|
|
comparison operators (==, !=, <, <=, >, =>) for queue and
|
12112 |
|
|
stack. Only the semantics for queue::operator== (23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a> par2) and queue::operator< (23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>
|
12113 |
|
|
par3) are defined.
|
12114 |
|
|
</p>
|
12115 |
|
|
<p><b>Proposed resolution:</b></p>
|
12116 |
|
|
|
12117 |
|
|
<p>Add the following new paragraphs after 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>
|
12118 |
|
|
paragraph 3:</p>
|
12119 |
|
|
|
12120 |
|
|
<blockquote>
|
12121 |
|
|
|
12122 |
|
|
<pre> operator!=
|
12123 |
|
|
</pre>
|
12124 |
|
|
<p>Returns: <tt>x.c != y.c</tt></p>
|
12125 |
|
|
|
12126 |
|
|
<pre> operator>
|
12127 |
|
|
</pre>
|
12128 |
|
|
<p>Returns: <tt>x.c > y.c</tt></p>
|
12129 |
|
|
|
12130 |
|
|
<pre> operator<=
|
12131 |
|
|
</pre>
|
12132 |
|
|
<p>Returns: <tt>x.c <= y.c</tt></p>
|
12133 |
|
|
|
12134 |
|
|
<pre> operator>=
|
12135 |
|
|
</pre>
|
12136 |
|
|
<p>Returns: <tt>x.c >= y.c</tt></p>
|
12137 |
|
|
|
12138 |
|
|
</blockquote>
|
12139 |
|
|
|
12140 |
|
|
<p>Add the following paragraphs at the end of 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>:</p>
|
12141 |
|
|
|
12142 |
|
|
<blockquote>
|
12143 |
|
|
|
12144 |
|
|
<pre> operator==
|
12145 |
|
|
</pre>
|
12146 |
|
|
<p>Returns: <tt>x.c == y.c</tt></p>
|
12147 |
|
|
|
12148 |
|
|
<pre> operator<
|
12149 |
|
|
</pre>
|
12150 |
|
|
<p>Returns: <tt>x.c < y.c</tt></p>
|
12151 |
|
|
|
12152 |
|
|
<pre> operator!=
|
12153 |
|
|
</pre>
|
12154 |
|
|
<p>Returns: <tt>x.c != y.c</tt></p>
|
12155 |
|
|
|
12156 |
|
|
<pre> operator>
|
12157 |
|
|
</pre>
|
12158 |
|
|
<p>Returns: <tt>x.c > y.c</tt></p>
|
12159 |
|
|
|
12160 |
|
|
<pre> operator<=
|
12161 |
|
|
</pre>
|
12162 |
|
|
<p>Returns: <tt>x.c <= y.c</tt></p>
|
12163 |
|
|
|
12164 |
|
|
<pre> operator>=
|
12165 |
|
|
</pre>
|
12166 |
|
|
<p>Returns: <tt>x.c >= y.c</tt></p>
|
12167 |
|
|
|
12168 |
|
|
</blockquote>
|
12169 |
|
|
|
12170 |
|
|
|
12171 |
|
|
<p><i>[Kona: Matt provided wording.]</i></p>
|
12172 |
|
|
|
12173 |
|
|
<p><b>Rationale:</b></p>
|
12174 |
|
|
There isn't any real doubt about what these operators are
|
12175 |
|
|
supposed to do, but we ought to spell it out.
|
12176 |
|
|
<hr>
|
12177 |
|
|
<a name="411"><h3>411. Wrong names of set member functions</h3></a><p><b>Section:</b> 25.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Daniel Frey <b>Date:</b> 9 Jul 2003</p>
|
12178 |
|
|
<p>
|
12179 |
|
|
25.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a> paragraph 1 reads:
|
12180 |
|
|
"The semantics of the set operations are generalized to multisets in a
|
12181 |
|
|
standard way by defining union() to contain the maximum number of
|
12182 |
|
|
occurrences of every element, intersection() to contain the minimum, and
|
12183 |
|
|
so on."
|
12184 |
|
|
</p>
|
12185 |
|
|
|
12186 |
|
|
<p>
|
12187 |
|
|
This is wrong. The name of the functions are set_union() and
|
12188 |
|
|
set_intersection(), not union() and intersection().
|
12189 |
|
|
</p>
|
12190 |
|
|
<p><b>Proposed resolution:</b></p>
|
12191 |
|
|
<p>Change that sentence to use the correct names.</p>
|
12192 |
|
|
<hr>
|
12193 |
|
|
<a name="412"><h3>412. Typo in 27.4.4.3</h3></a><p><b>Section:</b> 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 10 Jul 2003</p>
|
12194 |
|
|
<p>
|
12195 |
|
|
The Effects clause in 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> paragraph 5 says that the
|
12196 |
|
|
function only throws if the respective bits are already set prior to
|
12197 |
|
|
the function call. That's obviously not the intent. The typo ought to
|
12198 |
|
|
be corrected and the text reworded as: "If (<i>state</i> &
|
12199 |
|
|
exceptions()) == 0, returns. ..."
|
12200 |
|
|
</p>
|
12201 |
|
|
<p><b>Proposed resolution:</b></p>
|
12202 |
|
|
<p>
|
12203 |
|
|
In 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> paragraph 5, replace "If (rdstate() &
|
12204 |
|
|
exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
|
12205 |
|
|
& exceptions()) == 0".
|
12206 |
|
|
</p>
|
12207 |
|
|
|
12208 |
|
|
<p><i>[Kona: the original proposed resolution wasn't quite right. We
|
12209 |
|
|
really do mean rdstate(); the ambiguity is that the wording in the
|
12210 |
|
|
standard doesn't make it clear whether we mean rdstate() before
|
12211 |
|
|
setting the new state, or rdsate() after setting it. We intend the
|
12212 |
|
|
latter, of course. Post-Kona: Martin provided wording.]</i></p>
|
12213 |
|
|
|
12214 |
|
|
<hr>
|
12215 |
|
|
<a name="413"><h3>413. Proposed resolution to LDR#64 still wrong</h3></a><p><b>Section:</b> 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Bo Persson <b>Date:</b> 13 Jul 2003</p>
|
12216 |
|
|
<p>
|
12217 |
|
|
The second sentence of the proposed resolution says:
|
12218 |
|
|
</p>
|
12219 |
|
|
|
12220 |
|
|
<p>
|
12221 |
|
|
"If it inserted no characters because it caught an exception thrown
|
12222 |
|
|
while extracting characters from sb and ..."
|
12223 |
|
|
</p>
|
12224 |
|
|
|
12225 |
|
|
<p>
|
12226 |
|
|
However, we are not extracting from sb, but extracting from the
|
12227 |
|
|
basic_istream (*this) and inserting into sb. I can't really tell if
|
12228 |
|
|
"extracting" or "sb" is a typo.
|
12229 |
|
|
</p>
|
12230 |
|
|
|
12231 |
|
|
<p><i>[
|
12232 |
|
|
Sydney: Definitely a real issue. We are, indeed, extracting characters
|
12233 |
|
|
from an istream and not from sb. The problem was there in the FDIS and
|
12234 |
|
|
wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was
|
12235 |
|
|
to have *this instead of sb. We're talking about the exception flag
|
12236 |
|
|
state of a basic_istream object, and there's only one basic_istream
|
12237 |
|
|
object in this discussion, so that would be a consistent
|
12238 |
|
|
interpretation. (But we need to be careful: the exception policy of
|
12239 |
|
|
this member function must be consistent with that of other
|
12240 |
|
|
extractors.) PJP will provide wording.
|
12241 |
|
|
]</i></p>
|
12242 |
|
|
|
12243 |
|
|
<p><b>Proposed resolution:</b></p>
|
12244 |
|
|
<p>Change the sentence from:</p>
|
12245 |
|
|
|
12246 |
|
|
<blockquote>
|
12247 |
|
|
If it inserted no characters because it caught an exception thrown
|
12248 |
|
|
while extracting characters from sb and failbit is on in exceptions(),
|
12249 |
|
|
then the caught exception is rethrown.
|
12250 |
|
|
</blockquote>
|
12251 |
|
|
|
12252 |
|
|
<p>to:</p>
|
12253 |
|
|
|
12254 |
|
|
<blockquote>
|
12255 |
|
|
If it inserted no characters because it caught an exception thrown
|
12256 |
|
|
while extracting characters from *this and failbit is on in exceptions(),
|
12257 |
|
|
then the caught exception is rethrown.
|
12258 |
|
|
</blockquote>
|
12259 |
|
|
<hr>
|
12260 |
|
|
<a name="414"><h3>414. Which iterators are invalidated by v.erase()?</h3></a><p><b>Section:</b> 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Aug 2003</p>
|
12261 |
|
|
<p>
|
12262 |
|
|
Consider the following code fragment:
|
12263 |
|
|
</p>
|
12264 |
|
|
<blockquote>
|
12265 |
|
|
<pre>int A[8] = { 1,3,5,7,9,8,4,2 };
|
12266 |
|
|
std::vector<int> v(A, A+8);
|
12267 |
|
|
|
12268 |
|
|
std::vector<int>::iterator i1 = v.begin() + 3;
|
12269 |
|
|
std::vector<int>::iterator i2 = v.begin() + 4;
|
12270 |
|
|
v.erase(i1);
|
12271 |
|
|
</pre>
|
12272 |
|
|
</blockquote>
|
12273 |
|
|
|
12274 |
|
|
<p>
|
12275 |
|
|
Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
|
12276 |
|
|
both, or neither?
|
12277 |
|
|
</p>
|
12278 |
|
|
|
12279 |
|
|
<p>
|
12280 |
|
|
On all existing implementations that I know of, the status of i1 and
|
12281 |
|
|
i2 is the same: both of them will be iterators that point to some
|
12282 |
|
|
elements of the vector (albeit not the same elements they did
|
12283 |
|
|
before). You won't get a crash if you use them. Depending on
|
12284 |
|
|
exactly what you mean by "invalidate", you might say that neither one
|
12285 |
|
|
has been invalidated because they still point to <i>something</i>,
|
12286 |
|
|
or you might say that both have been invalidated because in both
|
12287 |
|
|
cases the elements they point to have been changed out from under the
|
12288 |
|
|
iterator.
|
12289 |
|
|
</p>
|
12290 |
|
|
|
12291 |
|
|
<p>
|
12292 |
|
|
The standard doesn't say either of those things. It says that erase
|
12293 |
|
|
invalidates all iterators and references "after the point of the
|
12294 |
|
|
erase". This doesn't include i1, since it's at the point of the
|
12295 |
|
|
erase instead of after it. I can't think of any sensible definition
|
12296 |
|
|
of invalidation by which one can say that i2 is invalidated but i1
|
12297 |
|
|
isn't.
|
12298 |
|
|
</p>
|
12299 |
|
|
|
12300 |
|
|
<p>
|
12301 |
|
|
(This issue is important if you try to reason about iterator validity
|
12302 |
|
|
based only on the guarantees in the standard, rather than reasoning
|
12303 |
|
|
from typical implementation techniques. Strict debugging modes,
|
12304 |
|
|
which some programmers find useful, do not use typical implementation
|
12305 |
|
|
techniques.)
|
12306 |
|
|
</p>
|
12307 |
|
|
<p><b>Proposed resolution:</b></p>
|
12308 |
|
|
<p>
|
12309 |
|
|
In 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> paragraph 3, change "Invalidates all the
|
12310 |
|
|
iterators and references after the point of the erase" to
|
12311 |
|
|
"Invalidates iterators and references at or after the point of the
|
12312 |
|
|
erase".
|
12313 |
|
|
</p>
|
12314 |
|
|
<p><b>Rationale:</b></p>
|
12315 |
|
|
<p>I believe this was essentially a typographical error, and that it
|
12316 |
|
|
was taken for granted that erasing an element invalidates iterators
|
12317 |
|
|
that point to it. The effects clause in question treats iterators
|
12318 |
|
|
and references in parallel, and it would seem counterintuitive to
|
12319 |
|
|
say that a reference to an erased value remains valid.</p>
|
12320 |
|
|
<hr>
|
12321 |
|
|
<a name="415"><h3>415. behavior of std::ws</h3></a><p><b>Section:</b> 27.6.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.manip"> [lib.istream.manip]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
|
12322 |
|
|
<p>
|
12323 |
|
|
According to 27.6.1.4, the ws() manipulator is not required to construct
|
12324 |
|
|
the sentry object. The manipulator is also not a member function so the
|
12325 |
|
|
text in 27.6.1, p1 through 4 that describes the exception policy for
|
12326 |
|
|
istream member functions does not apply. That seems inconsistent with
|
12327 |
|
|
the rest of extractors and all the other input functions (i.e., ws will
|
12328 |
|
|
not cause a tied stream to be flushed before extraction, it doesn't check
|
12329 |
|
|
the stream's exceptions or catch exceptions thrown during input, and it
|
12330 |
|
|
doesn't affect the stream's gcount).
|
12331 |
|
|
</p>
|
12332 |
|
|
<p><b>Proposed resolution:</b></p>
|
12333 |
|
|
<p>
|
12334 |
|
|
Add to 27.6.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.manip"> [lib.istream.manip]</a>, immediately before the first sentence
|
12335 |
|
|
of paragraph 1, the following text:
|
12336 |
|
|
</p>
|
12337 |
|
|
|
12338 |
|
|
<blockquote>
|
12339 |
|
|
Behaves as an unformatted input function (as described in
|
12340 |
|
|
27.6.1.3, paragraph 1), except that it does not count the number
|
12341 |
|
|
of characters extracted and does not affect the value returned by
|
12342 |
|
|
subsequent calls to is.gcount(). After constructing a sentry
|
12343 |
|
|
object...
|
12344 |
|
|
</blockquote>
|
12345 |
|
|
|
12346 |
|
|
<p><i>[Post-Kona: Martin provided wording]</i></p>
|
12347 |
|
|
|
12348 |
|
|
<hr>
|
12349 |
|
|
<a name="420"><h3>420. is std::FILE a complete type?</h3></a><p><b>Section:</b> 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
|
12350 |
|
|
<p>
|
12351 |
|
|
7.19.1, p2, of C99 requires that the FILE type only be declared in
|
12352 |
|
|
<stdio.h>. None of the (implementation-defined) members of the
|
12353 |
|
|
struct is mentioned anywhere for obvious reasons.
|
12354 |
|
|
</p>
|
12355 |
|
|
|
12356 |
|
|
<p>
|
12357 |
|
|
C++ says in 27.8.1, p2 that FILE is a type that's defined in <cstdio>. Is
|
12358 |
|
|
it really the intent that FILE be a complete type or is an implementation
|
12359 |
|
|
allowed to just declare it without providing a full definition?
|
12360 |
|
|
</p>
|
12361 |
|
|
<p><b>Proposed resolution:</b></p>
|
12362 |
|
|
<p>In the first sentence of 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> paragraph 2, change
|
12363 |
|
|
"defined" to "declared".</p>
|
12364 |
|
|
<p><b>Rationale:</b></p>
|
12365 |
|
|
<p>We don't want to impose any restrictions beyond what the C standard
|
12366 |
|
|
already says. We don't want to make anything implementation defined,
|
12367 |
|
|
because that imposes new requirements in implementations.</p>
|
12368 |
|
|
<hr>
|
12369 |
|
|
<a name="425"><h3>425. return value of std::get_temporary_buffer</h3></a><p><b>Section:</b> 20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.temporary.buffer"> [lib.temporary.buffer]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
|
12370 |
|
|
<p>
|
12371 |
|
|
The standard is not clear about the requirements on the value returned from
|
12372 |
|
|
a call to get_temporary_buffer(0). In particular, it fails to specify whether
|
12373 |
|
|
the call should return a distinct pointer each time it is called (like
|
12374 |
|
|
operator new), or whether the value is unspecified (as if returned by
|
12375 |
|
|
malloc). The standard also fails to mention what the required behavior
|
12376 |
|
|
is when the argument is less than 0.
|
12377 |
|
|
</p>
|
12378 |
|
|
<p><b>Proposed resolution:</b></p>
|
12379 |
|
|
<p>Change 20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.temporary.buffer"> [lib.temporary.buffer]</a> paragraph 2 from "...or a pair of 0
|
12380 |
|
|
values if no storage can be obtained" to "...or a pair of 0 values if
|
12381 |
|
|
no storage can be obtained or if <i>n</i> <= 0."</p>
|
12382 |
|
|
<p><i>[Kona: Matt provided wording]</i></p>
|
12383 |
|
|
<hr>
|
12384 |
|
|
<a name="426"><h3>426. search_n(), fill_n(), and generate_n() with negative n</h3></a><p><b>Section:</b> 25.1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a>, 25.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a>, 25.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.generate"> [lib.alg.generate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
|
12385 |
|
|
<p>
|
12386 |
|
|
The complexity requirements for these function templates are incorrect
|
12387 |
|
|
(or don't even make sense) for negative n:</p>
|
12388 |
|
|
|
12389 |
|
|
<p>25.1.9, p7 (search_n):
|
12390 |
|
|
<br>
|
12391 |
|
|
Complexity: At most (last1 - first1) * count applications
|
12392 |
|
|
of the corresponding predicate.</p>
|
12393 |
|
|
|
12394 |
|
|
<p>25.2.5, p3 (fill_n):
|
12395 |
|
|
<br>
|
12396 |
|
|
Complexity: Exactly last - first (or n) assignments.</p>
|
12397 |
|
|
<br>
|
12398 |
|
|
|
12399 |
|
|
<p>25.2.6, p3 (generate_n):
|
12400 |
|
|
<br>
|
12401 |
|
|
Complexity: Exactly last - first (or n) assignments.</p>
|
12402 |
|
|
|
12403 |
|
|
<p>
|
12404 |
|
|
In addition, the Requirements or the Effects clauses for the latter two
|
12405 |
|
|
templates don't say anything about the behavior when n is negative.
|
12406 |
|
|
</p>
|
12407 |
|
|
<p><b>Proposed resolution:</b></p>
|
12408 |
|
|
<p>Change 25.1.9, p7 to</p>
|
12409 |
|
|
|
12410 |
|
|
<blockquote>
|
12411 |
|
|
Complexity: At most (last1 - first1) * count applications
|
12412 |
|
|
of the corresponding predicate if count is positive,
|
12413 |
|
|
or 0 otherwise.
|
12414 |
|
|
</blockquote>
|
12415 |
|
|
|
12416 |
|
|
<p>Change 25.2.5, p2 to</p>
|
12417 |
|
|
<blockquote>
|
12418 |
|
|
Effects: Assigns value through all the iterators in the range [first,
|
12419 |
|
|
last), or [first, first + n) if n is positive, none otherwise.
|
12420 |
|
|
</blockquote>
|
12421 |
|
|
|
12422 |
|
|
<p>Change 25.2.5, p3 to:</p>
|
12423 |
|
|
<blockquote>
|
12424 |
|
|
Complexity: Exactly last - first (or n if n is positive,
|
12425 |
|
|
or 0 otherwise) assignments.
|
12426 |
|
|
</blockquote>
|
12427 |
|
|
|
12428 |
|
|
<p>
|
12429 |
|
|
Change 25.2.6, p1
|
12430 |
|
|
to (notice the correction for the misspelled "through"):
|
12431 |
|
|
</p>
|
12432 |
|
|
<blockquote>
|
12433 |
|
|
Effects: Invokes the function object genand assigns the return
|
12434 |
|
|
value of gen through all the iterators in the range [first, last),
|
12435 |
|
|
or [first, first + n) if n is positive, or [first, first)
|
12436 |
|
|
otherwise.
|
12437 |
|
|
</blockquote>
|
12438 |
|
|
|
12439 |
|
|
<p>Change 25.2.6, p3 to:</p>
|
12440 |
|
|
<blockquote>
|
12441 |
|
|
Complexity: Exactly last - first (or n if n is positive,
|
12442 |
|
|
or 0 otherwise) assignments.
|
12443 |
|
|
</blockquote>
|
12444 |
|
|
<p><b>Rationale:</b></p>
|
12445 |
|
|
<p>Informally, we want to say that whenever we see a negative number
|
12446 |
|
|
we treat it the same as if it were zero. We believe the above
|
12447 |
|
|
changes do that (although they may not be the minimal way of saying
|
12448 |
|
|
so). The LWG considered and rejected the alternative of saying that
|
12449 |
|
|
negative numbers are undefined behavior.</p>
|
12450 |
|
|
<hr>
|
12451 |
|
|
<a name="428"><h3>428. string::erase(iterator) validity</h3></a><p><b>Section:</b> 21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::erase"> [lib.string::erase]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
|
12452 |
|
|
<p>
|
12453 |
|
|
23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
|
12454 |
|
|
that q must be a valid dereferenceable iterator into the sequence a.
|
12455 |
|
|
</p>
|
12456 |
|
|
|
12457 |
|
|
<p>
|
12458 |
|
|
However, 21.3.5.5, p5 describing string::erase(p) only requires that
|
12459 |
|
|
p be a valid iterator.
|
12460 |
|
|
</p>
|
12461 |
|
|
|
12462 |
|
|
<p>
|
12463 |
|
|
This may be interepreted as a relaxation of the general requirement,
|
12464 |
|
|
which is most likely not the intent.
|
12465 |
|
|
</p>
|
12466 |
|
|
<p><b>Proposed resolution:</b></p>
|
12467 |
|
|
<p>Remove 21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::erase"> [lib.string::erase]</a> paragraph 5.</p>
|
12468 |
|
|
<p><b>Rationale:</b></p>
|
12469 |
|
|
<p>The LWG considered two options: changing the string requirements to
|
12470 |
|
|
match the general container requirements, or just removing the
|
12471 |
|
|
erroneous string requirements altogether. The LWG chose the latter
|
12472 |
|
|
option, on the grounds that duplicating text always risks the
|
12473 |
|
|
possibility that it might be duplicated incorrectly.</p>
|
12474 |
|
|
<hr>
|
12475 |
|
|
<a name="432"><h3>432. stringbuf::overflow() makes only one write position available</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Christian W Brock <b>Date:</b> 24 Sep 2003</p>
|
12476 |
|
|
<p>27.7.1.3 par 8 says:</p>
|
12477 |
|
|
<blockquote>
|
12478 |
|
|
Notes: The function can make a write position available only if
|
12479 |
|
|
( mode & ios_base::out) != 0. To make a write position
|
12480 |
|
|
available, the function reallocates (or initially allocates) an
|
12481 |
|
|
array object with a sufficient number of elements to hold the
|
12482 |
|
|
current array object (if any), plus one additional write position.
|
12483 |
|
|
If ( mode & ios_base::in) != 0, the function alters the read end
|
12484 |
|
|
pointer egptr() to point just past the new write position (as
|
12485 |
|
|
does the write end pointer epptr()).
|
12486 |
|
|
</blockquote>
|
12487 |
|
|
|
12488 |
|
|
<p>
|
12489 |
|
|
The sentences "plus one additional write position." and especially
|
12490 |
|
|
"(as does the write end pointer epptr())" COULD by interpreted
|
12491 |
|
|
(and is interpreted by at least my library vendor) as:
|
12492 |
|
|
</p>
|
12493 |
|
|
|
12494 |
|
|
<blockquote>
|
12495 |
|
|
post-condition: epptr() == pptr()+1
|
12496 |
|
|
</blockquote>
|
12497 |
|
|
|
12498 |
|
|
<p>
|
12499 |
|
|
This WOULD force sputc() to call the virtual overflow() each time.
|
12500 |
|
|
</p>
|
12501 |
|
|
|
12502 |
|
|
<p>The proposed change also affects Defect Report 169.</p>
|
12503 |
|
|
|
12504 |
|
|
<p><b>Proposed resolution:</b></p>
|
12505 |
|
|
<p>27.7.1.1/2 Change:</p>
|
12506 |
|
|
|
12507 |
|
|
<blockquote>
|
12508 |
|
|
2- Notes: The function allocates no array object.
|
12509 |
|
|
</blockquote>
|
12510 |
|
|
|
12511 |
|
|
<p>
|
12512 |
|
|
to:
|
12513 |
|
|
</p>
|
12514 |
|
|
|
12515 |
|
|
<blockquote>
|
12516 |
|
|
2- Postcondition: str() == "".
|
12517 |
|
|
</blockquote>
|
12518 |
|
|
|
12519 |
|
|
<p>
|
12520 |
|
|
27.7.1.1/3 Change:
|
12521 |
|
|
</p>
|
12522 |
|
|
|
12523 |
|
|
<blockquote>
|
12524 |
|
|
<p>
|
12525 |
|
|
-3- Effects: Constructs an object of class basic_stringbuf,
|
12526 |
|
|
initializing the base class with basic_streambuf()
|
12527 |
|
|
(lib.streambuf.cons), and initializing mode with which . Then copies
|
12528 |
|
|
the content of str into the basic_stringbuf underlying character
|
12529 |
|
|
sequence and initializes the input and output sequences according to
|
12530 |
|
|
which. If which & ios_base::out is true, initializes the output
|
12531 |
|
|
sequence with the underlying sequence. If which & ios_base::in is
|
12532 |
|
|
true, initializes the input sequence with the underlying sequence.
|
12533 |
|
|
</p>
|
12534 |
|
|
</blockquote>
|
12535 |
|
|
|
12536 |
|
|
<p>to:</p>
|
12537 |
|
|
|
12538 |
|
|
<blockquote>
|
12539 |
|
|
<p>
|
12540 |
|
|
-3- Effects: Constructs an object of class basic_stringbuf,
|
12541 |
|
|
initializing the base class with basic_streambuf()
|
12542 |
|
|
(lib.streambuf.cons), and initializing mode with which. Then copies
|
12543 |
|
|
the content of str into the basic_stringbuf underlying character
|
12544 |
|
|
sequence. If which & ios_base::out is true, initializes the output
|
12545 |
|
|
sequence such that pbase() points to the first underlying character,
|
12546 |
|
|
epptr() points one past the last underlying character, and if (which &
|
12547 |
|
|
ios_base::ate) is true, pptr() is set equal to
|
12548 |
|
|
epptr() else pptr() is set equal to pbase(). If which & ios_base::in
|
12549 |
|
|
is true, initializes the input sequence such that eback() and gptr()
|
12550 |
|
|
point to the first underlying character and egptr() points one past
|
12551 |
|
|
the last underlying character.
|
12552 |
|
|
</p>
|
12553 |
|
|
</blockquote>
|
12554 |
|
|
|
12555 |
|
|
<p>27.7.1.2/1 Change:</p>
|
12556 |
|
|
|
12557 |
|
|
<blockquote>
|
12558 |
|
|
<p>
|
12559 |
|
|
-1- Returns: A basic_string object whose content is equal to the
|
12560 |
|
|
basic_stringbuf underlying character sequence. If the buffer is only
|
12561 |
|
|
created in input mode, the underlying character sequence is equal to
|
12562 |
|
|
the input sequence; otherwise, it is equal to the output sequence. In
|
12563 |
|
|
case of an empty underlying character sequence, the function returns
|
12564 |
|
|
basic_string<charT,traits,Allocator>().
|
12565 |
|
|
</p>
|
12566 |
|
|
</blockquote>
|
12567 |
|
|
|
12568 |
|
|
<p>to:</p>
|
12569 |
|
|
|
12570 |
|
|
<blockquote>
|
12571 |
|
|
<p>
|
12572 |
|
|
-1- Returns: A basic_string object whose content is equal to the
|
12573 |
|
|
basic_stringbuf underlying character sequence. If the basic_stringbuf
|
12574 |
|
|
was created only in input mode, the resultant basic_string contains
|
12575 |
|
|
the character sequence in the range [eback(), egptr()). If the
|
12576 |
|
|
basic_stringbuf was created with (which & ios_base::out) being true
|
12577 |
|
|
then the resultant basic_string contains the character sequence in the
|
12578 |
|
|
range [pbase(), high_mark) where high_mark represents the position one
|
12579 |
|
|
past the highest initialized character in the buffer. Characters can
|
12580 |
|
|
be initialized either through writing to the stream, or by
|
12581 |
|
|
constructing the basic_stringbuf with a basic_string, or by calling
|
12582 |
|
|
the str(basic_string) member function. In the case of calling the
|
12583 |
|
|
str(basic_string) member function, all characters initialized prior to
|
12584 |
|
|
the call are now considered uninitialized (except for those
|
12585 |
|
|
characters re-initialized by the new basic_string). Otherwise the
|
12586 |
|
|
basic_stringbuf has been created in neither input nor output mode and
|
12587 |
|
|
a zero length basic_string is returned.
|
12588 |
|
|
</p>
|
12589 |
|
|
</blockquote>
|
12590 |
|
|
|
12591 |
|
|
<p>
|
12592 |
|
|
27.7.1.2/2 Change:
|
12593 |
|
|
</p>
|
12594 |
|
|
|
12595 |
|
|
<blockquote>
|
12596 |
|
|
<p>
|
12597 |
|
|
-2- Effects: If the basic_stringbuf's underlying character sequence is
|
12598 |
|
|
not empty, deallocates it. Then copies the content of s into the
|
12599 |
|
|
basic_stringbuf underlying character sequence and initializes the
|
12600 |
|
|
input and output sequences according to the mode stored when creating
|
12601 |
|
|
the basic_stringbuf object. If (mode&ios_base::out) is true, then
|
12602 |
|
|
initializes the output sequence with the underlying sequence. If
|
12603 |
|
|
(mode&ios_base::in) is true, then initializes the input sequence with
|
12604 |
|
|
the underlying sequence.
|
12605 |
|
|
</p>
|
12606 |
|
|
</blockquote>
|
12607 |
|
|
|
12608 |
|
|
<p>to:</p>
|
12609 |
|
|
|
12610 |
|
|
<blockquote>
|
12611 |
|
|
<p>
|
12612 |
|
|
-2- Effects: Copies the content of s into the basic_stringbuf
|
12613 |
|
|
underlying character sequence. If mode & ios_base::out is true,
|
12614 |
|
|
initializes the output sequence such that pbase() points to the first
|
12615 |
|
|
underlying character, epptr() points one past the last underlying
|
12616 |
|
|
character, and if (mode & ios_base::ate) is true,
|
12617 |
|
|
pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
|
12618 |
|
|
mode & ios_base::in is true, initializes the input sequence such that
|
12619 |
|
|
eback() and gptr() point to the first underlying character and egptr()
|
12620 |
|
|
points one past the last underlying character.
|
12621 |
|
|
</p>
|
12622 |
|
|
</blockquote>
|
12623 |
|
|
|
12624 |
|
|
<p>Remove 27.2.1.2/3. (Same rationale as issue 238: incorrect and unnecessary.)</p>
|
12625 |
|
|
|
12626 |
|
|
<p>27.7.1.3/1 Change:</p>
|
12627 |
|
|
|
12628 |
|
|
<blockquote>
|
12629 |
|
|
<p>
|
12630 |
|
|
1- Returns: If the input sequence has a read position available,
|
12631 |
|
|
returns traits::to_int_type(*gptr()). Otherwise, returns
|
12632 |
|
|
traits::eof().
|
12633 |
|
|
</p>
|
12634 |
|
|
</blockquote>
|
12635 |
|
|
|
12636 |
|
|
<p>to:</p>
|
12637 |
|
|
|
12638 |
|
|
<blockquote>
|
12639 |
|
|
<p>
|
12640 |
|
|
1- Returns: If the input sequence has a read position available,
|
12641 |
|
|
returns traits::to_int_type(*gptr()). Otherwise, returns
|
12642 |
|
|
traits::eof(). Any character in the underlying buffer which has been
|
12643 |
|
|
initialized is considered to be part of the input sequence.
|
12644 |
|
|
</p>
|
12645 |
|
|
</blockquote>
|
12646 |
|
|
|
12647 |
|
|
<p>27.7.1.3/9 Change:</p>
|
12648 |
|
|
|
12649 |
|
|
<blockquote>
|
12650 |
|
|
<p>
|
12651 |
|
|
-9- Notes: The function can make a write position available only if (
|
12652 |
|
|
mode & ios_base::out) != 0. To make a write position available, the
|
12653 |
|
|
function reallocates (or initially allocates) an array object with a
|
12654 |
|
|
sufficient number of elements to hold the current array object (if
|
12655 |
|
|
any), plus one additional write position. If ( mode & ios_base::in) !=
|
12656 |
|
|
0, the function alters the read end pointer egptr() to point just past
|
12657 |
|
|
the new write position (as does the write end pointer epptr()).
|
12658 |
|
|
</p>
|
12659 |
|
|
</blockquote>
|
12660 |
|
|
|
12661 |
|
|
<p>to:</p>
|
12662 |
|
|
|
12663 |
|
|
<blockquote>
|
12664 |
|
|
<p>
|
12665 |
|
|
-9- The function can make a write position available only if ( mode &
|
12666 |
|
|
ios_base::out) != 0. To make a write position available, the function
|
12667 |
|
|
reallocates (or initially allocates) an array object with a sufficient
|
12668 |
|
|
number of elements to hold the current array object (if any), plus one
|
12669 |
|
|
additional write position. If ( mode & ios_base::in) != 0, the
|
12670 |
|
|
function alters the read end pointer egptr() to point just past the
|
12671 |
|
|
new write position.
|
12672 |
|
|
</p>
|
12673 |
|
|
</blockquote>
|
12674 |
|
|
|
12675 |
|
|
<p>27.7.1.3/12 Change:</p>
|
12676 |
|
|
|
12677 |
|
|
<blockquote>
|
12678 |
|
|
<p>
|
12679 |
|
|
-12- _ If (newoff + off) < 0, or (xend - xbeg) < (newoff + off), the
|
12680 |
|
|
positioning operation fails. Otherwise, the function assigns xbeg +
|
12681 |
|
|
newoff + off to the next pointer xnext .
|
12682 |
|
|
</p>
|
12683 |
|
|
</blockquote>
|
12684 |
|
|
|
12685 |
|
|
<p>to:</p>
|
12686 |
|
|
|
12687 |
|
|
<blockquote>
|
12688 |
|
|
<p>
|
12689 |
|
|
-12- _ If (newoff + off) < 0, or if (newoff + off) refers to an
|
12690 |
|
|
uninitialized character (as defined in 27.7.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.members"> [lib.stringbuf.members]</a>
|
12691 |
|
|
paragraph 1), the positioning operation fails. Otherwise, the function
|
12692 |
|
|
assigns xbeg + newoff + off to the next pointer xnext .
|
12693 |
|
|
</p>
|
12694 |
|
|
</blockquote>
|
12695 |
|
|
|
12696 |
|
|
<p><i>[post-Kona: Howard provided wording. At Kona the LWG agreed that
|
12697 |
|
|
something along these lines was a good idea, but the original
|
12698 |
|
|
proposed resolution didn't say enough about the effect of various
|
12699 |
|
|
member functions on the underlying character sequences.]</i></p>
|
12700 |
|
|
|
12701 |
|
|
<p><b>Rationale:</b></p>
|
12702 |
|
|
<p>The current basic_stringbuf description is over-constrained in such
|
12703 |
|
|
a way as to prohibit vendors from making this the high-performance
|
12704 |
|
|
in-memory stream it was meant to be. The fundamental problem is that
|
12705 |
|
|
the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
|
12706 |
|
|
observable from a derived client, and the current description
|
12707 |
|
|
restricts the range [pbase(), epptr()) from being grown geometrically.
|
12708 |
|
|
This change allows, but does not require, geometric growth of this
|
12709 |
|
|
range.</p>
|
12710 |
|
|
|
12711 |
|
|
<p>Backwards compatibility issues: These changes will break code that
|
12712 |
|
|
derives from basic_stringbuf, observes epptr(), and depends upon
|
12713 |
|
|
[pbase(), epptr()) growing by one character on each call to overflow()
|
12714 |
|
|
(i.e. test suites). Otherwise there are no backwards compatibility
|
12715 |
|
|
issues.</p>
|
12716 |
|
|
|
12717 |
|
|
<p>27.7.1.1/2: The non-normative note is non-binding, and if it were
|
12718 |
|
|
binding, would be over specification. The recommended change focuses
|
12719 |
|
|
on the important observable fact.</p>
|
12720 |
|
|
|
12721 |
|
|
<p>27.7.1.1/3: This change does two things: 1. It describes exactly
|
12722 |
|
|
what must happen in terms of the sequences. The terms "input
|
12723 |
|
|
sequence" and "output sequence" are not well defined. 2. It
|
12724 |
|
|
introduces a common extension: open with app or ate mode. I concur
|
12725 |
|
|
with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
|
12726 |
|
|
|
12727 |
|
|
<p>27.7.1.2/1: This change is the crux of the efficiency issue. The
|
12728 |
|
|
resultant basic_string is not dependent upon epptr(), and thus
|
12729 |
|
|
implementors are free to grow the underlying buffer geometrically
|
12730 |
|
|
during overflow() *and* place epptr() at the end of that buffer.</p>
|
12731 |
|
|
|
12732 |
|
|
<p>27.7.1.2/2: Made consistent with the proposed 27.7.1.1/3.</p>
|
12733 |
|
|
|
12734 |
|
|
<p>27.7.1.3/1: Clarifies that characters written to the stream beyond
|
12735 |
|
|
the initially specified string are available for reading in an i/o
|
12736 |
|
|
basic_streambuf.</p>
|
12737 |
|
|
|
12738 |
|
|
<p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
|
12739 |
|
|
trailing parenthetical comment concerning epptr().</p>
|
12740 |
|
|
|
12741 |
|
|
<p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
|
12742 |
|
|
longer allowable since [pbase(), epptr()) may now contain
|
12743 |
|
|
uninitialized characters. Positioning is only allowable over the
|
12744 |
|
|
initialized range.</p>
|
12745 |
|
|
<hr>
|
12746 |
|
|
<a name="434"><h3>434. bitset::to_string() hard to use</h3></a><p><b>Section:</b> 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2003</p>
|
12747 |
|
|
<p>
|
12748 |
|
|
It has been pointed out a number of times that the bitset to_string() member
|
12749 |
|
|
function template is tedious to use since callers must explicitly specify the
|
12750 |
|
|
entire template argument list (3 arguments). At least two implementations
|
12751 |
|
|
provide a number of overloads of this template to make it easier to use.
|
12752 |
|
|
</p>
|
12753 |
|
|
<p><b>Proposed resolution:</b></p>
|
12754 |
|
|
<p>In order to allow callers to specify no template arguments at all, just the
|
12755 |
|
|
first one (charT), or the first 2 (charT and traits), in addition to all
|
12756 |
|
|
three template arguments, add the following three overloads to both the
|
12757 |
|
|
interface (declarations only) of the class template bitset as well as to
|
12758 |
|
|
section 23.3.5.2, immediately after p34, the Returns clause of the existing
|
12759 |
|
|
to_string() member function template:</p>
|
12760 |
|
|
|
12761 |
|
|
<pre> template <class charT, class traits>
|
12762 |
|
|
basic_string<charT, traits, allocator<charT> >
|
12763 |
|
|
to_string () const;
|
12764 |
|
|
|
12765 |
|
|
-34.1- Returns: to_string<charT, traits, allocator<charT> >().
|
12766 |
|
|
|
12767 |
|
|
template <class charT>
|
12768 |
|
|
basic_string<charT, char_traits<charT>, allocator<charT> >
|
12769 |
|
|
to_string () const;
|
12770 |
|
|
|
12771 |
|
|
-34.2- Returns: to_string<charT, char_traits<charT>, allocator<charT> >().
|
12772 |
|
|
|
12773 |
|
|
basic_string<char, char_traits<char>, allocator<char> >
|
12774 |
|
|
to_string () const;
|
12775 |
|
|
|
12776 |
|
|
-34.3- Returns: to_string<char, char_traits<char>, allocator<char> >().
|
12777 |
|
|
</pre>
|
12778 |
|
|
|
12779 |
|
|
<p><i>[Kona: the LWG agrees that this is an improvement over the
|
12780 |
|
|
status quo. Dietmar thought about an alternative using a proxy
|
12781 |
|
|
object but now believes that the proposed resolution above is the
|
12782 |
|
|
right choice.
|
12783 |
|
|
]</i></p>
|
12784 |
|
|
|
12785 |
|
|
<hr>
|
12786 |
|
|
<a name="435"><h3>435. bug in DR 25</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2003</p>
|
12787 |
|
|
|
12788 |
|
|
<p>
|
12789 |
|
|
It has been pointed out that the proposed resolution in DR 25 may not be
|
12790 |
|
|
quite up to snuff: <br>
|
12791 |
|
|
http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
|
12792 |
|
|
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
|
12793 |
|
|
</p>
|
12794 |
|
|
|
12795 |
|
|
<p>
|
12796 |
|
|
It looks like Petur is right. The complete corrected text is copied below.
|
12797 |
|
|
I think we may have have been confused by the reference to 22.2.2.2.2 and
|
12798 |
|
|
the subsequent description of `n' which actually talks about the second
|
12799 |
|
|
argument to sputn(), not about the number of fill characters to pad with.
|
12800 |
|
|
</p>
|
12801 |
|
|
|
12802 |
|
|
<p>
|
12803 |
|
|
So the question is: was the original text correct? If the intent was to
|
12804 |
|
|
follow classic iostreams then it most likely wasn't, since setting width()
|
12805 |
|
|
to less than the length of the string doesn't truncate it on output. This
|
12806 |
|
|
is also the behavior of most implementations (except for SGI's standard
|
12807 |
|
|
iostreams where the operator does truncate).
|
12808 |
|
|
</p>
|
12809 |
|
|
<p><b>Proposed resolution:</b></p>
|
12810 |
|
|
<p>Change the text in 21.3.7.9, p4 from</p>
|
12811 |
|
|
<blockquote>
|
12812 |
|
|
If bool(k) is true, inserts characters as if by calling
|
12813 |
|
|
os.rdbuf()->sputn(str.data(), n), padding as described in stage 3
|
12814 |
|
|
of lib.facet.num.put.virtuals, where n is the larger of os.width()
|
12815 |
|
|
and str.size();
|
12816 |
|
|
</blockquote>
|
12817 |
|
|
<p>to</p>
|
12818 |
|
|
<blockquote>
|
12819 |
|
|
If bool(k) is true, determines padding as described in
|
12820 |
|
|
lib.facet.num.put.virtuals, and then inserts the resulting
|
12821 |
|
|
sequence of characters <tt>seq</tt> as if by calling
|
12822 |
|
|
<tt>os.rdbuf()->sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
|
12823 |
|
|
<tt>os.width()</tt> and <tt>str.size()</tt>;
|
12824 |
|
|
</blockquote>
|
12825 |
|
|
|
12826 |
|
|
<p><i>[Kona: it appears that neither the original wording, DR25, nor the
|
12827 |
|
|
proposed resolution, is quite what we want. We want to say that
|
12828 |
|
|
the string will be output, padded to os.width() if necessary. We
|
12829 |
|
|
don't want to duplicate the padding rules in clause 22, because
|
12830 |
|
|
they're complicated, but we need to be careful because they weren't
|
12831 |
|
|
quite written with quite this case in mind. We need to say what
|
12832 |
|
|
the character sequence is, and then defer to clause 22. Post-Kona:
|
12833 |
|
|
Benjamin provided wording.]</i></p>
|
12834 |
|
|
|
12835 |
|
|
<hr>
|
12836 |
|
|
<a name="436"><h3>436. are cv-qualified facet types valid facets?</h3></a><p><b>Section:</b> 22.1.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.facet"> [lib.locale.facet]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2003</p>
|
12837 |
|
|
<p>
|
12838 |
|
|
Is "const std::ctype<char>" a valid template argument to has_facet, use_facet,
|
12839 |
|
|
and the locale template ctor? And if so, does it designate the same Facet as
|
12840 |
|
|
the non-const "std::ctype<char>?" What about "volatile std::ctype<char>?"
|
12841 |
|
|
Different implementations behave differently: some fail to compile, others
|
12842 |
|
|
accept such types but behave inconsistently.
|
12843 |
|
|
</p>
|
12844 |
|
|
<p><b>Proposed resolution:</b></p>
|
12845 |
|
|
<p>Change 22.1.1.1.2, p1 to read:</p>
|
12846 |
|
|
|
12847 |
|
|
<p>Template parameters in this clause which are required to be facets
|
12848 |
|
|
are those named Facet in declarations. A program that passes a type
|
12849 |
|
|
that is not a facet, or a type that refers to volatile-qualified
|
12850 |
|
|
facet, as an (explicit or deduced) template parameter to a locale
|
12851 |
|
|
function expecting a facet, is ill-formed. A const-qualified facet is
|
12852 |
|
|
a valid template argument to any locale function that expects a Facet
|
12853 |
|
|
template parameter.</p>
|
12854 |
|
|
|
12855 |
|
|
<p><i>[Kona: changed the last sentence from a footnote to normative
|
12856 |
|
|
text.]</i></p>
|
12857 |
|
|
|
12858 |
|
|
<hr>
|
12859 |
|
|
<a name="438"><h3>438. Ambiguity in the "do the right thing" clause</h3></a><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Oct 2003</p>
|
12860 |
|
|
|
12861 |
|
|
<p>Section 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, paragraphs 9-11, fixed up the problem
|
12862 |
|
|
noticed with statements like:</p>
|
12863 |
|
|
<pre>vector<int> v(10, 1);
|
12864 |
|
|
</pre>
|
12865 |
|
|
|
12866 |
|
|
<p>The intent of the above statement was to construct with:</p>
|
12867 |
|
|
<pre>vector(size_type, const value_type&);
|
12868 |
|
|
</pre>
|
12869 |
|
|
|
12870 |
|
|
<p>but early implementations failed to compile as they bound to:</p>
|
12871 |
|
|
<pre>template <class InputIterator>
|
12872 |
|
|
vector(InputIterator f, InputIterator l);
|
12873 |
|
|
</pre>
|
12874 |
|
|
<p>instead.</p>
|
12875 |
|
|
|
12876 |
|
|
<p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
|
12877 |
|
|
member template constructor will have the same effect as:</p>
|
12878 |
|
|
<pre>vector<static_cast<size_type>(f), static_cast<value_type>(l));
|
12879 |
|
|
</pre>
|
12880 |
|
|
<p>(and similarly for the other member template functions of sequences).</p>
|
12881 |
|
|
|
12882 |
|
|
<p>There is also a note that describes one implementation technique:</p>
|
12883 |
|
|
<blockquote>
|
12884 |
|
|
One way that sequence implementors can satisfy this requirement is to
|
12885 |
|
|
specialize the member template for every integral type.
|
12886 |
|
|
</blockquote>
|
12887 |
|
|
|
12888 |
|
|
<p>This might look something like:</p>
|
12889 |
|
|
<blockquote>
|
12890 |
|
|
<pre>template <class T>
|
12891 |
|
|
struct vector
|
12892 |
|
|
{
|
12893 |
|
|
typedef unsigned size_type;
|
12894 |
|
|
|
12895 |
|
|
explicit vector(size_type) {}
|
12896 |
|
|
vector(size_type, const T&) {}
|
12897 |
|
|
|
12898 |
|
|
template <class I>
|
12899 |
|
|
vector(I, I);
|
12900 |
|
|
|
12901 |
|
|
// ...
|
12902 |
|
|
};
|
12903 |
|
|
|
12904 |
|
|
template <class T>
|
12905 |
|
|
template <class I>
|
12906 |
|
|
vector<T>::vector(I, I) { ... }
|
12907 |
|
|
|
12908 |
|
|
template <>
|
12909 |
|
|
template <>
|
12910 |
|
|
vector<int>::vector(int, int) { ... }
|
12911 |
|
|
|
12912 |
|
|
template <>
|
12913 |
|
|
template <>
|
12914 |
|
|
vector<int>::vector(unsigned, unsigned) { ... }
|
12915 |
|
|
|
12916 |
|
|
// ...
|
12917 |
|
|
</pre>
|
12918 |
|
|
</blockquote>
|
12919 |
|
|
|
12920 |
|
|
<p>Label this solution 'A'.</p>
|
12921 |
|
|
|
12922 |
|
|
<p>The standard also says:</p>
|
12923 |
|
|
<blockquote>
|
12924 |
|
|
Less cumbersome implementation techniques also exist.
|
12925 |
|
|
</blockquote>
|
12926 |
|
|
<p>
|
12927 |
|
|
A popular technique is to not specialize as above, but instead catch
|
12928 |
|
|
every call with the member template, detect the type of InputIterator,
|
12929 |
|
|
and then redirect to the correct logic. Something like:
|
12930 |
|
|
</p>
|
12931 |
|
|
<blockquote>
|
12932 |
|
|
<pre>template <class T>
|
12933 |
|
|
template <class I>
|
12934 |
|
|
vector<T>::vector(I f, I l)
|
12935 |
|
|
{
|
12936 |
|
|
choose_init(f, l, int2type<is_integral<I>::value>());
|
12937 |
|
|
}
|
12938 |
|
|
|
12939 |
|
|
template <class T>
|
12940 |
|
|
template <class I>
|
12941 |
|
|
vector<T>::choose_init(I f, I l, int2type<false>)
|
12942 |
|
|
{
|
12943 |
|
|
// construct with iterators
|
12944 |
|
|
}
|
12945 |
|
|
|
12946 |
|
|
template <class T>
|
12947 |
|
|
template <class I>
|
12948 |
|
|
vector<T>::choose_init(I f, I l, int2type<true>)
|
12949 |
|
|
{
|
12950 |
|
|
size_type sz = static_cast<size_type>(f);
|
12951 |
|
|
value_type v = static_cast<value_type>(l);
|
12952 |
|
|
// construct with sz,v
|
12953 |
|
|
}
|
12954 |
|
|
</pre>
|
12955 |
|
|
</blockquote>
|
12956 |
|
|
|
12957 |
|
|
<p>Label this solution 'B'.</p>
|
12958 |
|
|
|
12959 |
|
|
<p>Both of these solutions solve the case the standard specifically
|
12960 |
|
|
mentions:</p>
|
12961 |
|
|
<pre>vector<int> v(10, 1); // ok, vector size 10, initialized to 1
|
12962 |
|
|
</pre>
|
12963 |
|
|
|
12964 |
|
|
<p>
|
12965 |
|
|
However, (and here is the problem), the two solutions have different
|
12966 |
|
|
behavior in some cases where the value_type of the sequence is not an
|
12967 |
|
|
integral type. For example consider:
|
12968 |
|
|
</p>
|
12969 |
|
|
<blockquote><pre> pair<char, char> p('a', 'b');
|
12970 |
|
|
vector<vector<pair<char, char> > > d('a', 'b');
|
12971 |
|
|
</pre></blockquote>
|
12972 |
|
|
<p>
|
12973 |
|
|
The second line of this snippet is likely an error. Solution A catches
|
12974 |
|
|
the error and refuses to compile. The reason is that there is no
|
12975 |
|
|
specialization of the member template constructor that looks like:
|
12976 |
|
|
</p>
|
12977 |
|
|
<pre>template <>
|
12978 |
|
|
template <>
|
12979 |
|
|
vector<vector<pair<char, char> > >::vector(char, char) { ... }
|
12980 |
|
|
</pre>
|
12981 |
|
|
|
12982 |
|
|
<p>
|
12983 |
|
|
So the expression binds to the unspecialized member template
|
12984 |
|
|
constructor, and then fails (compile time) because char is not an
|
12985 |
|
|
InputIterator.
|
12986 |
|
|
</p>
|
12987 |
|
|
|
12988 |
|
|
<p>
|
12989 |
|
|
Solution B compiles the above example though. 'a' is casted to an
|
12990 |
|
|
unsigned integral type and used to size the outer vector. 'b' is
|
12991 |
|
|
static casted to the inner vector using it's explicit constructor:
|
12992 |
|
|
</p>
|
12993 |
|
|
|
12994 |
|
|
<pre>explicit vector(size_type n);
|
12995 |
|
|
</pre>
|
12996 |
|
|
|
12997 |
|
|
<p>
|
12998 |
|
|
and so you end up with a static_cast<size_type>('a') by
|
12999 |
|
|
static_cast<size_type>('b') matrix.
|
13000 |
|
|
</p>
|
13001 |
|
|
|
13002 |
|
|
<p>
|
13003 |
|
|
It is certainly possible that this is what the coder intended. But the
|
13004 |
|
|
explicit qualifier on the inner vector has been thwarted at any rate.
|
13005 |
|
|
</p>
|
13006 |
|
|
|
13007 |
|
|
<p>
|
13008 |
|
|
The standard is not clear whether the expression:
|
13009 |
|
|
</p>
|
13010 |
|
|
|
13011 |
|
|
<pre> vector<vector<pair<char, char> > > d('a', 'b');
|
13012 |
|
|
</pre>
|
13013 |
|
|
|
13014 |
|
|
<p>
|
13015 |
|
|
(and similar expressions) are:
|
13016 |
|
|
</p>
|
13017 |
|
|
|
13018 |
|
|
<ol>
|
13019 |
|
|
<li> undefined behavior.</li>
|
13020 |
|
|
<li> illegal and must be rejected.</li>
|
13021 |
|
|
<li> legal and must be accepted.</li>
|
13022 |
|
|
</ol>
|
13023 |
|
|
|
13024 |
|
|
<p>My preference is listed in the order presented.</p>
|
13025 |
|
|
|
13026 |
|
|
<p>There are still other techniques for implementing the requirements of
|
13027 |
|
|
paragraphs 9-11, namely the "restricted template technique" (e.g.
|
13028 |
|
|
enable_if). This technique is the most compact and easy way of coding
|
13029 |
|
|
the requirements, and has the behavior of #2 (rejects the above
|
13030 |
|
|
expression).
|
13031 |
|
|
</p>
|
13032 |
|
|
|
13033 |
|
|
<p>
|
13034 |
|
|
Choosing 1 would allow all implementation techniques I'm aware of.
|
13035 |
|
|
Choosing 2 would allow only solution 'A' and the enable_if technique.
|
13036 |
|
|
Choosing 3 would allow only solution 'B'.
|
13037 |
|
|
</p>
|
13038 |
|
|
|
13039 |
|
|
<p>
|
13040 |
|
|
Possible wording for a future standard if we wanted to actively reject
|
13041 |
|
|
the expression above would be to change "static_cast" in paragraphs
|
13042 |
|
|
9-11 to "implicit_cast" where that is defined by:
|
13043 |
|
|
</p>
|
13044 |
|
|
|
13045 |
|
|
<blockquote>
|
13046 |
|
|
<pre>template <class T, class U>
|
13047 |
|
|
inline
|
13048 |
|
|
T implicit_cast(const U& u)
|
13049 |
|
|
{
|
13050 |
|
|
return u;
|
13051 |
|
|
}
|
13052 |
|
|
</pre>
|
13053 |
|
|
</blockquote>
|
13054 |
|
|
|
13055 |
|
|
<p><b>Proposed resolution:</b></p>
|
13056 |
|
|
|
13057 |
|
|
Replace 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> paragraphs 9 - 11 with:
|
13058 |
|
|
|
13059 |
|
|
<p>For every sequence defined in this clause and in clause lib.strings:</p>
|
13060 |
|
|
|
13061 |
|
|
<ul>
|
13062 |
|
|
<li>
|
13063 |
|
|
<p>If the constructor</p>
|
13064 |
|
|
<pre> template <class InputIterator>
|
13065 |
|
|
X(InputIterator f, InputIterator l,
|
13066 |
|
|
const allocator_type& a = allocator_type())
|
13067 |
|
|
</pre>
|
13068 |
|
|
<p>is called with a type InputIterator that does not qualify as
|
13069 |
|
|
an input iterator, then the constructor will behave as if the
|
13070 |
|
|
overloaded constructor:</p>
|
13071 |
|
|
<pre> X(size_type, const value_type& = value_type(),
|
13072 |
|
|
const allocator_type& = allocator_type())
|
13073 |
|
|
</pre>
|
13074 |
|
|
<p>were called instead, with the arguments static_cast<size_type>(f), l and a, respectively.</p>
|
13075 |
|
|
</li>
|
13076 |
|
|
|
13077 |
|
|
<li>
|
13078 |
|
|
<p>If the member functions of the forms:</p>
|
13079 |
|
|
<pre> template <class InputIterator> // such as insert()
|
13080 |
|
|
rt fx1(iterator p, InputIterator f, InputIterator l);
|
13081 |
|
|
|
13082 |
|
|
template <class InputIterator> // such as append(), assign()
|
13083 |
|
|
rt fx2(InputIterator f, InputIterator l);
|
13084 |
|
|
|
13085 |
|
|
template <class InputIterator> // such as replace()
|
13086 |
|
|
rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
|
13087 |
|
|
</pre>
|
13088 |
|
|
<p>are called with a type InputIterator that does not qualify as
|
13089 |
|
|
an input iterator, then these functions will behave as if the
|
13090 |
|
|
overloaded member functions:</p>
|
13091 |
|
|
<pre> rt fx1(iterator, size_type, const value_type&);
|
13092 |
|
|
|
13093 |
|
|
rt fx2(size_type, const value_type&);
|
13094 |
|
|
|
13095 |
|
|
rt fx3(iterator, iterator, size_type, const value_type&);
|
13096 |
|
|
</pre>
|
13097 |
|
|
<p>were called instead, with the same arguments.</p>
|
13098 |
|
|
</li>
|
13099 |
|
|
</ul>
|
13100 |
|
|
|
13101 |
|
|
<p>In the previous paragraph the alternative binding will fail if f
|
13102 |
|
|
is not implicitly convertible to X::size_type or if l is not implicitly
|
13103 |
|
|
convertible to X::value_type.</p>
|
13104 |
|
|
|
13105 |
|
|
<p>
|
13106 |
|
|
The extent to which an implementation determines that a type cannot be
|
13107 |
|
|
an input iterator is unspecified, except that as a minimum integral
|
13108 |
|
|
types shall not qualify as input iterators.
|
13109 |
|
|
</p>
|
13110 |
|
|
|
13111 |
|
|
|
13112 |
|
|
|
13113 |
|
|
<p><i>[
|
13114 |
|
|
Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
|
13115 |
|
|
to be accepted, and also agreed that this is surprising behavior. The
|
13116 |
|
|
LWG considered several options, including something like
|
13117 |
|
|
implicit_cast, which doesn't appear to be quite what we want. We
|
13118 |
|
|
considered Howards three options: allow acceptance or rejection,
|
13119 |
|
|
require rejection as a compile time error, and require acceptance. By
|
13120 |
|
|
straw poll (1-6-1), we chose to require a compile time error.
|
13121 |
|
|
Post-Kona: Howard provided wording.
|
13122 |
|
|
]</i></p>
|
13123 |
|
|
|
13124 |
|
|
<p><i>[
|
13125 |
|
|
Sydney: The LWG agreed with this general direction, but there was some
|
13126 |
|
|
discomfort with the wording in the original proposed resolution.
|
13127 |
|
|
Howard submitted new wording, and we will review this again in
|
13128 |
|
|
Redmond.
|
13129 |
|
|
]</i></p>
|
13130 |
|
|
|
13131 |
|
|
<p><i>[Redmond: one very small change in wording: the first argument
|
13132 |
|
|
is cast to size_t. This fixes the problem of something like
|
13133 |
|
|
<tt>vector<vector<int> >(5, 5)</tt>, where int is not
|
13134 |
|
|
implicitly convertible to the value type.]</i></p>
|
13135 |
|
|
|
13136 |
|
|
<p><b>Rationale:</b></p>
|
13137 |
|
|
<p>The proposed resolution fixes:</p>
|
13138 |
|
|
|
13139 |
|
|
<pre> vector<int> v(10, 1);
|
13140 |
|
|
</pre>
|
13141 |
|
|
|
13142 |
|
|
<p>
|
13143 |
|
|
since as integral types 10 and 1 must be disqualified as input
|
13144 |
|
|
iterators and therefore the (size,value) constructor is called (as
|
13145 |
|
|
if).</p>
|
13146 |
|
|
|
13147 |
|
|
<p>The proposed resolution breaks:</p>
|
13148 |
|
|
|
13149 |
|
|
<pre> vector<vector<T> > v(10, 1);
|
13150 |
|
|
</pre>
|
13151 |
|
|
|
13152 |
|
|
<p>
|
13153 |
|
|
because the integral type 1 is not *implicitly* convertible to
|
13154 |
|
|
vector<T>. The wording above requires a diagnostic.</p>
|
13155 |
|
|
|
13156 |
|
|
<p>
|
13157 |
|
|
The proposed resolution leaves the behavior of the following code
|
13158 |
|
|
unspecified.
|
13159 |
|
|
</p>
|
13160 |
|
|
|
13161 |
|
|
<pre> struct A
|
13162 |
|
|
{
|
13163 |
|
|
operator int () const {return 10;}
|
13164 |
|
|
};
|
13165 |
|
|
|
13166 |
|
|
struct B
|
13167 |
|
|
{
|
13168 |
|
|
B(A) {}
|
13169 |
|
|
};
|
13170 |
|
|
|
13171 |
|
|
vector<B> v(A(), A());
|
13172 |
|
|
</pre>
|
13173 |
|
|
|
13174 |
|
|
<p>
|
13175 |
|
|
The implementation may or may not detect that A is not an input
|
13176 |
|
|
iterator and employee the (size,value) constructor. Note though that
|
13177 |
|
|
in the above example if the B(A) constructor is qualified explicit,
|
13178 |
|
|
then the implementation must reject the constructor as A is no longer
|
13179 |
|
|
implicitly convertible to B.
|
13180 |
|
|
</p>
|
13181 |
|
|
<hr>
|
13182 |
|
|
<a name="441"><h3>441. Is fpos::state const?</h3></a><p><b>Section:</b> 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 17 Nov 2003</p>
|
13183 |
|
|
<p>
|
13184 |
|
|
In section 27.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.members"> [lib.fpos.members]</a> fpos<stateT>::state() is declared
|
13185 |
|
|
non const, but in section 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> it is declared const.
|
13186 |
|
|
</p>
|
13187 |
|
|
<p><b>Proposed resolution:</b></p>
|
13188 |
|
|
<p>
|
13189 |
|
|
In section 27.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.members"> [lib.fpos.members]</a>, change the declaration of
|
13190 |
|
|
<tt>fpos<stateT>::state()</tt> to const.
|
13191 |
|
|
</p>
|
13192 |
|
|
<hr>
|
13193 |
|
|
<a name="442"><h3>442. sentry::operator bool() inconsistent signature</h3></a><p><b>Section:</b> 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 18 Nov 2003</p>
|
13194 |
|
|
<p>
|
13195 |
|
|
In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> paragraph 4, in description part
|
13196 |
|
|
basic_ostream<charT, traits>::sentry::operator bool() is declared
|
13197 |
|
|
as non const, but in section 27.6.2.3, in synopsis it is declared
|
13198 |
|
|
const.
|
13199 |
|
|
</p>
|
13200 |
|
|
<p><b>Proposed resolution:</b></p>
|
13201 |
|
|
<p>
|
13202 |
|
|
In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> paragraph 4, change the declaration
|
13203 |
|
|
of <tt>sentry::operator bool()</tt> to const.
|
13204 |
|
|
</p>
|
13205 |
|
|
<hr>
|
13206 |
|
|
<a name="443"><h3>443. filebuf::close() inconsistent use of EOF</h3></a><p><b>Section:</b> 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 20 Nov 2003</p>
|
13207 |
|
|
<p>
|
13208 |
|
|
In section 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> par6, in effects description of
|
13209 |
|
|
basic_filebuf<charT, traits>::close(), overflow(EOF) is used twice;
|
13210 |
|
|
should be overflow(traits::eof()).
|
13211 |
|
|
</p>
|
13212 |
|
|
<p><b>Proposed resolution:</b></p>
|
13213 |
|
|
<p>
|
13214 |
|
|
Change overflow(EOF) to overflow(traits::eof()).
|
13215 |
|
|
</p>
|
13216 |
|
|
<hr>
|
13217 |
|
|
<a name="444"><h3>444. Bad use of casts in fstream</h3></a><p><b>Section:</b> 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 20 Nov 2003</p>
|
13218 |
|
|
<p>
|
13219 |
|
|
27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> p1, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> p1, 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a> p1 seems have same problem as exposed in LWG issue
|
13220 |
|
|
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
|
13221 |
|
|
</p>
|
13222 |
|
|
<p><b>Proposed resolution:</b></p>
|
13223 |
|
|
|
13224 |
|
|
<p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
|
13225 |
|
|
constness. The other two places are stylistic: we could change the
|
13226 |
|
|
C-style casts to const_cast. Post-Sydney: Howard provided wording.
|
13227 |
|
|
]</i></p>
|
13228 |
|
|
|
13229 |
|
|
<p>Change 27.8.1.7/1 from:</p>
|
13230 |
|
|
<blockquote>
|
13231 |
|
|
Returns: (basic_filebuf<charT,traits>*)&sb.
|
13232 |
|
|
</blockquote>
|
13233 |
|
|
|
13234 |
|
|
<p>to:</p>
|
13235 |
|
|
<blockquote>
|
13236 |
|
|
Returns: const_cast<basic_filebuf<charT,traits>*>(&sb).
|
13237 |
|
|
</blockquote>
|
13238 |
|
|
|
13239 |
|
|
<p>Change 27.8.1.10/1 from:</p>
|
13240 |
|
|
<blockquote>
|
13241 |
|
|
Returns: (basic_filebuf<charT,traits>*)&sb.
|
13242 |
|
|
</blockquote>
|
13243 |
|
|
|
13244 |
|
|
<p>to:</p>
|
13245 |
|
|
<blockquote>
|
13246 |
|
|
Returns: const_cast<basic_filebuf<charT,traits>*>(&sb).
|
13247 |
|
|
</blockquote>
|
13248 |
|
|
|
13249 |
|
|
<p>Change 27.8.1.13/1 from:</p>
|
13250 |
|
|
<blockquote>
|
13251 |
|
|
Returns: &sb.
|
13252 |
|
|
</blockquote>
|
13253 |
|
|
|
13254 |
|
|
<p>to:</p>
|
13255 |
|
|
<blockquote>
|
13256 |
|
|
Returns: const_cast<basic_filebuf<charT,traits>*>(&sb).
|
13257 |
|
|
</blockquote>
|
13258 |
|
|
|
13259 |
|
|
|
13260 |
|
|
|
13261 |
|
|
<hr>
|
13262 |
|
|
<a name="445"><h3>445. iterator_traits::reference unspecified for some iterator categories</h3></a><p><b>Section:</b> 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 9 Dec 2003</p>
|
13263 |
|
|
<p>
|
13264 |
|
|
The standard places no restrictions at all on the reference type
|
13265 |
|
|
of input, output, or forward iterators (for forward iterators it
|
13266 |
|
|
only specifies that *x must be value_type& and doesn't mention
|
13267 |
|
|
the reference type). Bidirectional iterators' reference type is
|
13268 |
|
|
restricted only by implication, since the base iterator's
|
13269 |
|
|
reference type is used as the return type of reverse_iterator's
|
13270 |
|
|
operator*, which must be T& in order to be a conforming forward
|
13271 |
|
|
iterator.
|
13272 |
|
|
</p>
|
13273 |
|
|
|
13274 |
|
|
<p>
|
13275 |
|
|
Here's what I think we ought to be able to expect from an input
|
13276 |
|
|
or forward iterator's reference type R, where a is an iterator
|
13277 |
|
|
and V is its value_type
|
13278 |
|
|
</p>
|
13279 |
|
|
|
13280 |
|
|
<ul>
|
13281 |
|
|
<li>
|
13282 |
|
|
*a is convertible to R
|
13283 |
|
|
</li>
|
13284 |
|
|
|
13285 |
|
|
<li>
|
13286 |
|
|
R is convertible to V
|
13287 |
|
|
</li>
|
13288 |
|
|
|
13289 |
|
|
<li>
|
13290 |
|
|
static_cast<V>(static_cast<R>(*a)) is equivalent to
|
13291 |
|
|
static_cast<V>(*a)
|
13292 |
|
|
</li>
|
13293 |
|
|
</ul>
|
13294 |
|
|
|
13295 |
|
|
<p>A mutable forward iterator ought to satisfy, for x of type V:</p>
|
13296 |
|
|
<li>
|
13297 |
|
|
{ R r = *a; r = x; } is equivalent to *a = x;
|
13298 |
|
|
</li>
|
13299 |
|
|
|
13300 |
|
|
<p>
|
13301 |
|
|
I think these requirements capture existing container iterators
|
13302 |
|
|
(including vector<bool>'s), but render istream_iterator invalid;
|
13303 |
|
|
its reference type would have to be changed to a constant
|
13304 |
|
|
reference.
|
13305 |
|
|
</p>
|
13306 |
|
|
|
13307 |
|
|
|
13308 |
|
|
<p>
|
13309 |
|
|
(Jeremy Siek) During the discussion in Sydney, it was felt that a
|
13310 |
|
|
simpler long term solution for this was needed. The solution proposed
|
13311 |
|
|
was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
|
13312 |
|
|
and <tt>pointer</tt> to be the same type as <tt>a-></tt>. Most
|
13313 |
|
|
iterators in the Standard Library already meet this requirement. Some
|
13314 |
|
|
iterators are output iterators, and do not need to meet the
|
13315 |
|
|
requirement, and others are only specified through the general
|
13316 |
|
|
iterator requirements (which will change with this resolution). The
|
13317 |
|
|
sole case where there is an explicit definition of the reference type
|
13318 |
|
|
that will need to change is <tt>istreambuf_iterator</tt> which returns
|
13319 |
|
|
<tt>charT</tt> from <tt>operator*</tt> but has a reference type of
|
13320 |
|
|
<tt>charT&</tt>. We propose changing the reference type of
|
13321 |
|
|
<tt>istreambuf_iterator</tt> to <tt>charT</tt>.
|
13322 |
|
|
</p>
|
13323 |
|
|
|
13324 |
|
|
<p>The other option for resolving the issue with <tt>pointer</tt>,
|
13325 |
|
|
mentioned in the note below, is to remove <tt>pointer</tt>
|
13326 |
|
|
altogether. I prefer placing requirements on <tt>pointer</tt> to
|
13327 |
|
|
removing it for two reasons. First, <tt>pointer</tt> will become
|
13328 |
|
|
useful for implementing iterator adaptors and in particular,
|
13329 |
|
|
<tt>reverse_iterator</tt> will become more well defined. Second,
|
13330 |
|
|
removing <tt>pointer</tt> is a rather drastic and publicly-visible
|
13331 |
|
|
action to take.</p>
|
13332 |
|
|
|
13333 |
|
|
<p>The proposed resolution technically enlarges the requirements for
|
13334 |
|
|
iterators, which means there are existing iterators (such as
|
13335 |
|
|
<tt>istreambuf_iterator</tt>, and potentially some programmer-defined
|
13336 |
|
|
iterators) that will no longer meet the requirements. Will this break
|
13337 |
|
|
existing code? The scenario in which it would is if an algorithm
|
13338 |
|
|
implementation (say in the Standard Library) is changed to rely on
|
13339 |
|
|
<tt>iterator_traits::reference</tt>, and then is used with one of the
|
13340 |
|
|
iterators that do not have an appropriately defined
|
13341 |
|
|
<tt>iterator_traits::reference</tt>.
|
13342 |
|
|
</p>
|
13343 |
|
|
|
13344 |
|
|
|
13345 |
|
|
<p>The proposed resolution makes one other subtle change. Previously,
|
13346 |
|
|
it was required that output iterators have a <tt>difference_type</tt>
|
13347 |
|
|
and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
|
13348 |
|
|
iterator could not be an output iterator. This is clearly a mistake,
|
13349 |
|
|
so I've changed the wording to say that those types may be
|
13350 |
|
|
<tt>void</tt>.
|
13351 |
|
|
</p>
|
13352 |
|
|
|
13353 |
|
|
<p><b>Proposed resolution:</b></p>
|
13354 |
|
|
|
13355 |
|
|
<p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, after:</p>
|
13356 |
|
|
|
13357 |
|
|
<blockquote>
|
13358 |
|
|
be defined as the iterator's difference type, value type and iterator
|
13359 |
|
|
category, respectively.
|
13360 |
|
|
</blockquote>
|
13361 |
|
|
|
13362 |
|
|
<p>add</p>
|
13363 |
|
|
|
13364 |
|
|
<blockquote>
|
13365 |
|
|
In addition, the types
|
13366 |
|
|
<pre>iterator_traits<Iterator>::reference
|
13367 |
|
|
iterator_traits<Iterator>::pointer
|
13368 |
|
|
</pre>
|
13369 |
|
|
must be defined as the iterator's reference and pointer types, that
|
13370 |
|
|
is, the same type as the type of <tt>*a</tt> and <tt>a-></tt>,
|
13371 |
|
|
respectively.
|
13372 |
|
|
</blockquote>
|
13373 |
|
|
|
13374 |
|
|
<p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, change:</p>
|
13375 |
|
|
|
13376 |
|
|
<blockquote>
|
13377 |
|
|
In the case of an output iterator, the types
|
13378 |
|
|
<pre>iterator_traits<Iterator>::difference_type
|
13379 |
|
|
iterator_traits<Iterator>::value_type
|
13380 |
|
|
</pre>
|
13381 |
|
|
are both defined as <tt>void</tt>.
|
13382 |
|
|
</blockquote>
|
13383 |
|
|
|
13384 |
|
|
<p>to:</p>
|
13385 |
|
|
<blockquote>
|
13386 |
|
|
In the case of an output iterator, the types
|
13387 |
|
|
<pre>iterator_traits<Iterator>::difference_type
|
13388 |
|
|
iterator_traits<Iterator>::value_type
|
13389 |
|
|
iterator_traits<Iterator>::reference
|
13390 |
|
|
iterator_traits<Iterator>::pointer
|
13391 |
|
|
</pre>
|
13392 |
|
|
may be defined as <tt>void</tt>.
|
13393 |
|
|
</blockquote>
|
13394 |
|
|
|
13395 |
|
|
<p>In 24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, change:</p>
|
13396 |
|
|
<blockquote>
|
13397 |
|
|
<pre>typename traits::off_type, charT*, charT&>
|
13398 |
|
|
</pre>
|
13399 |
|
|
</blockquote>
|
13400 |
|
|
<p>to:</p>
|
13401 |
|
|
<blockquote>
|
13402 |
|
|
<pre>typename traits::off_type, charT*, charT>
|
13403 |
|
|
</pre>
|
13404 |
|
|
</blockquote>
|
13405 |
|
|
|
13406 |
|
|
<p><i>[
|
13407 |
|
|
Redmond: there was concern in Sydney that this might not be the only place
|
13408 |
|
|
where things were underspecified and needed to be changed. Jeremy
|
13409 |
|
|
reviewed iterators in the standard and confirmed that nothing else
|
13410 |
|
|
needed to be changed.
|
13411 |
|
|
]</i></p>
|
13412 |
|
|
|
13413 |
|
|
<hr>
|
13414 |
|
|
<a name="448"><h3>448. Random Access Iterators over abstract classes</h3></a><p><b>Section:</b> 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 7 Jan 2004</p>
|
13415 |
|
|
<p>
|
13416 |
|
|
Table 76, the random access iterator requirement table, says that the
|
13417 |
|
|
return type of a[n] must be "convertible to T". When an iterator's
|
13418 |
|
|
value_type T is an abstract class, nothing is convertible to T.
|
13419 |
|
|
Surely this isn't an intended restriction?
|
13420 |
|
|
</p>
|
13421 |
|
|
<p><b>Proposed resolution:</b></p>
|
13422 |
|
|
<p>
|
13423 |
|
|
Change the return type to "convertible to T const&".
|
13424 |
|
|
</p>
|
13425 |
|
|
<hr>
|
13426 |
|
|
<a name="449"><h3>449. Library Issue 306 Goes Too Far</h3></a><p><b>Section:</b> 18.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 15 Jan 2004</p>
|
13427 |
|
|
<p>Original text:</p>
|
13428 |
|
|
<blockquote>
|
13429 |
|
|
The macro offsetof accepts a restricted set of type arguments in this
|
13430 |
|
|
International Standard. type shall be a POD structure or a POD union
|
13431 |
|
|
(clause 9). The result of applying the offsetof macro to a field that
|
13432 |
|
|
is a static data member or a function member is undefined."
|
13433 |
|
|
</blockquote>
|
13434 |
|
|
|
13435 |
|
|
<p>Revised text:</p>
|
13436 |
|
|
<blockquote>
|
13437 |
|
|
"If type is not a POD structure or a POD union the results are undefined."
|
13438 |
|
|
</blockquote>
|
13439 |
|
|
|
13440 |
|
|
<p>
|
13441 |
|
|
Looks to me like the revised text should have replaced only the second
|
13442 |
|
|
sentence. It doesn't make sense standing alone.
|
13443 |
|
|
</p>
|
13444 |
|
|
|
13445 |
|
|
<p><b>Proposed resolution:</b></p>
|
13446 |
|
|
<p>Change 18.1, paragraph 5, to:</p>
|
13447 |
|
|
|
13448 |
|
|
<blockquote>
|
13449 |
|
|
The macro offsetof accepts a restricted set of type arguments in this
|
13450 |
|
|
International Standard. If type is not a POD structure or a POD union
|
13451 |
|
|
the results are undefined. The result of applying the offsetof macro
|
13452 |
|
|
to a field that is a static data member or a function member is
|
13453 |
|
|
undefined."
|
13454 |
|
|
</blockquote>
|
13455 |
|
|
<hr>
|
13456 |
|
|
<a name="453"><h3>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p>
|
13457 |
|
|
<pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
|
13458 |
|
|
ios_base::openmode);
|
13459 |
|
|
</pre>
|
13460 |
|
|
<p>
|
13461 |
|
|
is obliged to fail if nothing has been inserted into the stream. This
|
13462 |
|
|
is unnecessary and undesirable. It should be permissible to seek to
|
13463 |
|
|
an effective offset of zero.</p>
|
13464 |
|
|
|
13465 |
|
|
<p><i>[
|
13466 |
|
|
Sydney: Agreed that this is an annoying problem: seeking to zero should be
|
13467 |
|
|
legal. Bill will provide wording.
|
13468 |
|
|
]</i></p>
|
13469 |
|
|
|
13470 |
|
|
<p><b>Proposed resolution:</b></p>
|
13471 |
|
|
<p>Change the sentence from:</p>
|
13472 |
|
|
<blockquote>
|
13473 |
|
|
For a sequence to be positioned, if its next pointer (either
|
13474 |
|
|
gptr() or pptr()) is a null pointer, the positioning operation
|
13475 |
|
|
fails.
|
13476 |
|
|
</blockquote>
|
13477 |
|
|
|
13478 |
|
|
<p>to:</p>
|
13479 |
|
|
|
13480 |
|
|
<blockquote>
|
13481 |
|
|
For a sequence to be positioned, if its next pointer (either
|
13482 |
|
|
gptr() or pptr()) is a null pointer and the new offset newoff
|
13483 |
|
|
is nonzero, the positioning operation fails.
|
13484 |
|
|
</blockquote>
|
13485 |
|
|
<hr>
|
13486 |
|
|
<a name="455"><h3>455. cerr::tie() and wcerr::tie() are overspecified</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p>
|
13487 |
|
|
<p>
|
13488 |
|
|
Both cerr::tie() and wcerr::tie() are obliged to be null at program
|
13489 |
|
|
startup. This is overspecification and overkill. It is both traditional
|
13490 |
|
|
and useful to tie cerr to cout, to ensure that standard output is drained
|
13491 |
|
|
whenever an error message is written. This behavior should at least be
|
13492 |
|
|
permitted if not required. Same for wcerr::tie().
|
13493 |
|
|
</p>
|
13494 |
|
|
<p><b>Proposed resolution:</b></p>
|
13495 |
|
|
|
13496 |
|
|
<p>Add to the description of cerr:</p>
|
13497 |
|
|
<blockquote>
|
13498 |
|
|
After the object cerr is initialized, cerr.tie() returns &cout.
|
13499 |
|
|
Its state is otherwise the same as required for basic_ios<char>::init
|
13500 |
|
|
(lib.basic.ios.cons).
|
13501 |
|
|
</blockquote>
|
13502 |
|
|
|
13503 |
|
|
<p>Add to the description of wcerr:</p>
|
13504 |
|
|
|
13505 |
|
|
<blockquote>
|
13506 |
|
|
After the object wcerr is initialized, wcerr.tie() returns &wcout.
|
13507 |
|
|
Its state is otherwise the same as required for basic_ios<wchar_t>::init
|
13508 |
|
|
(lib.basic.ios.cons).
|
13509 |
|
|
</blockquote>
|
13510 |
|
|
|
13511 |
|
|
<p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
|
13512 |
|
|
permit, cout and cerr to be tied on startup. Pre-Redmond: Bill will
|
13513 |
|
|
provide wording.]</i></p>
|
13514 |
|
|
<hr>
|
13515 |
|
|
<a name="457"><h3>457. bitset constructor: incorrect number of initialized bits</h3></a><p><b>Section:</b> 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Dag Henriksson <b>Date:</b> 30 Jan 2004</p>
|
13516 |
|
|
<p>
|
13517 |
|
|
The constructor from unsigned long says it initializes "the first M
|
13518 |
|
|
bit positions to the corresponding bit values in val. M is the smaller
|
13519 |
|
|
of N and the value CHAR_BIT * sizeof(unsigned long)."
|
13520 |
|
|
</p>
|
13521 |
|
|
|
13522 |
|
|
<p>
|
13523 |
|
|
Object-representation vs. value-representation strikes again. CHAR_BIT *
|
13524 |
|
|
sizeof (unsigned long) does not give us the number of bits an unsigned long
|
13525 |
|
|
uses to hold the value. Thus, the first M bit position above is not
|
13526 |
|
|
guaranteed to have any corresponding bit values in val.
|
13527 |
|
|
</p>
|
13528 |
|
|
<p><b>Proposed resolution:</b></p>
|
13529 |
|
|
<p>In 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> paragraph 2, change "M is the smaller of
|
13530 |
|
|
N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
|
13531 |
|
|
"<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
|
13532 |
|
|
the value representation (section 3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.types"> [basic.types]</a>) of <tt>unsigned
|
13533 |
|
|
long</tt>."
|
13534 |
|
|
</p>
|
13535 |
|
|
<hr>
|
13536 |
|
|
<a name="460"><h3>460. Default modes missing from basic_fstream member specifications</h3></a><p><b>Section:</b> 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Ben Hutchings <b>Date:</b> 1 Apr 2004</p>
|
13537 |
|
|
<p>
|
13538 |
|
|
The second parameters of the non-default constructor and of the open
|
13539 |
|
|
member function for basic_fstream, named "mode", are optional
|
13540 |
|
|
according to the class declaration in 27.8.1.11 [lib.fstream]. The
|
13541 |
|
|
specifications of these members in 27.8.1.12 [lib.fstream.cons] and
|
13542 |
|
|
27.8.1.13 lib.fstream.members] disagree with this, though the
|
13543 |
|
|
constructor declaration has the "explicit" function-specifier implying
|
13544 |
|
|
that it is intended to be callable with one argument.
|
13545 |
|
|
</p>
|
13546 |
|
|
<p><b>Proposed resolution:</b></p>
|
13547 |
|
|
<p>In 27.8.1.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, change</p>
|
13548 |
|
|
<pre> explicit basic_fstream(const char* s, ios_base::openmode mode);
|
13549 |
|
|
</pre>
|
13550 |
|
|
<p>to</p>
|
13551 |
|
|
<pre> explicit basic_fstream(const char* s,
|
13552 |
|
|
ios_base::openmode mode = ios_base::in|ios_base::out);
|
13553 |
|
|
</pre>
|
13554 |
|
|
<p>In 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, change</p>
|
13555 |
|
|
<pre> void open(const char*s, ios_base::openmode mode);
|
13556 |
|
|
</pre>
|
13557 |
|
|
<p>to</p>
|
13558 |
|
|
void open(const char*s,
|
13559 |
|
|
ios_base::openmode mode = ios_base::in|ios_base::out);
|
13560 |
|
|
<hr>
|
13561 |
|
|
<a name="461"><h3>461. time_get hard or impossible to implement</h3></a><p><b>Section:</b> 22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 23 Mar 2004</p>
|
13562 |
|
|
<p>
|
13563 |
|
|
Template time_get currently contains difficult, if not impossible,
|
13564 |
|
|
requirements for do_date_order, do_get_time, and do_get_date. All require
|
13565 |
|
|
the implementation to scan a field generated by the %x or %X conversion
|
13566 |
|
|
specifier in strftime. Yes, do_date_order can always return no_order, but
|
13567 |
|
|
that doesn't help the other functions. The problem is that %x can be
|
13568 |
|
|
nearly anything, and it can vary widely with locales. It's horribly
|
13569 |
|
|
onerous to have to parse "third sunday after Michaelmas in the year of
|
13570 |
|
|
our Lord two thousand and three," but that's what we currently ask of
|
13571 |
|
|
do_get_date. More practically, it leads some people to think that if
|
13572 |
|
|
%x produces 10.2.04, we should know to look for dots as separators. Still
|
13573 |
|
|
not easy.
|
13574 |
|
|
</p>
|
13575 |
|
|
|
13576 |
|
|
<p>
|
13577 |
|
|
Note that this is the <i>opposite</i> effect from the intent stated in the
|
13578 |
|
|
footnote earlier in this subclause:
|
13579 |
|
|
</p>
|
13580 |
|
|
|
13581 |
|
|
<blockquote>
|
13582 |
|
|
"In other words, user confirmation is required for reliable parsing of
|
13583 |
|
|
user-entered dates and times, but machine-generated formats can be
|
13584 |
|
|
parsed reliably. This allows parsers to be aggressive about interpreting
|
13585 |
|
|
user variations on standard formats."
|
13586 |
|
|
</blockquote>
|
13587 |
|
|
|
13588 |
|
|
<p>
|
13589 |
|
|
We should give both implementers and users an easier and more reliable
|
13590 |
|
|
alternative: provide a (short) list of alternative delimiters and say
|
13591 |
|
|
what the default date order is for no_order. For backward compatibility,
|
13592 |
|
|
and maximum latitude, we can permit an implementation to parse whatever
|
13593 |
|
|
%x or %X generates, but we shouldn't require it.
|
13594 |
|
|
</p>
|
13595 |
|
|
<p><b>Proposed resolution:</b></p>
|
13596 |
|
|
|
13597 |
|
|
<p><b>In the description:</b></p>
|
13598 |
|
|
<pre>iter_type do_get_time(iter_type s, iter_type end, ios_base& str,
|
13599 |
|
|
ios_base::iostate& err, tm* t) const;
|
13600 |
|
|
</pre>
|
13601 |
|
|
|
13602 |
|
|
<p>
|
13603 |
|
|
2 Effects: Reads characters starting at suntil it has extracted those
|
13604 |
|
|
struct tm members, and remaining format characters, used by
|
13605 |
|
|
time_put<>::put to produce the format specified by 'X', or until it
|
13606 |
|
|
encounters an error or end of sequence.
|
13607 |
|
|
</p>
|
13608 |
|
|
|
13609 |
|
|
<p><b>change:</b> 'X'</p>
|
13610 |
|
|
|
13611 |
|
|
<p><b>to:</b> "%H:%M:%S"</p>
|
13612 |
|
|
|
13613 |
|
|
|
13614 |
|
|
<p>Change</p>
|
13615 |
|
|
<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base& str,
|
13616 |
|
|
ios_base::iostate& err, tm* t) const;
|
13617 |
|
|
|
13618 |
|
|
4 Effects: Reads characters starting at s until it has extracted those
|
13619 |
|
|
struct tm members, and remaining format characters, used by
|
13620 |
|
|
time_put<>::put to produce the format specified by 'x', or until it
|
13621 |
|
|
encounters an error.
|
13622 |
|
|
</pre>
|
13623 |
|
|
|
13624 |
|
|
<p>to</p>
|
13625 |
|
|
iter_type do_get_date(iter_type s, iter_type end, ios_base& str,
|
13626 |
|
|
ios_base::iostate& err, tm* t) const;
|
13627 |
|
|
|
13628 |
|
|
4 Effects: Reads characters starting at s until it has extracted those
|
13629 |
|
|
struct tm members, and remaining format characters, used by
|
13630 |
|
|
time_put<>::put to produce one of the following formats, or until it
|
13631 |
|
|
encounters an error. The format depends on the value returned by
|
13632 |
|
|
date_order() as follows:
|
13633 |
|
|
|
13634 |
|
|
date_order() format
|
13635 |
|
|
|
13636 |
|
|
no_order "%m/%d/%y"
|
13637 |
|
|
dmy "%d/%m/%y"
|
13638 |
|
|
mdy "%m/%d/%y"
|
13639 |
|
|
ymd "%y/%m/%d"
|
13640 |
|
|
ydm "%y/%d/%m"
|
13641 |
|
|
|
13642 |
|
|
An implementation may also accept additional implementation-defined formats.
|
13643 |
|
|
<pre></pre>
|
13644 |
|
|
|
13645 |
|
|
<p><i>[Redmond: agreed that this is a real problem. The solution is
|
13646 |
|
|
probably to match C99's parsing rules. Bill provided wording.
|
13647 |
|
|
]</i></p>
|
13648 |
|
|
|
13649 |
|
|
<hr>
|
13650 |
|
|
<a name="464"><h3>464. Suggestion for new member functions in standard containers</h3></a><p><b>Section:</b> 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 12 May 2004</p>
|
13651 |
|
|
|
13652 |
|
|
<p>To add slightly more convenience to vector<T> and map<Key,T> we should consider to add</p>
|
13653 |
|
|
<ol>
|
13654 |
|
|
<li> add vector<T>::data() member (const and non-const version)
|
13655 |
|
|
semantics: if( empty() ) return 0; else return buffer_;</li>
|
13656 |
|
|
<li> add map<Key,T>::at( const Key& k ) member (const and non-const version)
|
13657 |
|
|
<i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
|
13658 |
|
|
</ol>
|
13659 |
|
|
|
13660 |
|
|
<p>Rationale:</p>
|
13661 |
|
|
|
13662 |
|
|
<ul>
|
13663 |
|
|
<li>To obtain a pointer to the vector's buffer, one must use either
|
13664 |
|
|
operator[]() (which can give undefined behavior for empty vectors) or
|
13665 |
|
|
at() (which will then throw if the vector is empty). </li>
|
13666 |
|
|
<li>tr1::array<T,sz> already has a data() member</li>
|
13667 |
|
|
<li>e cannot use operator[]() when T is not DefaultDonstructible</li>
|
13668 |
|
|
<li>Neither when the map is const.</li>
|
13669 |
|
|
<li>when we want to make sure we don't add an element accidently</li>
|
13670 |
|
|
<li>when it should be considered an error if a key is not in the map</li>
|
13671 |
|
|
</ul>
|
13672 |
|
|
|
13673 |
|
|
<p><b>Proposed resolution:</b></p>
|
13674 |
|
|
<p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, add the following to the <tt>vector</tt>
|
13675 |
|
|
synopsis after "element access" and before "modifiers":</p>
|
13676 |
|
|
<pre> // <i>[lib.vector.data] data access</i>
|
13677 |
|
|
pointer data();
|
13678 |
|
|
const_pointer data() const;
|
13679 |
|
|
</pre>
|
13680 |
|
|
|
13681 |
|
|
<p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>:</p>
|
13682 |
|
|
<blockquote>
|
13683 |
|
|
<p>23.2.4.x <tt>vector</tt> data access</p>
|
13684 |
|
|
<pre> pointer data();
|
13685 |
|
|
const_pointer data() const;
|
13686 |
|
|
</pre>
|
13687 |
|
|
<p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
|
13688 |
|
|
range. For a non-empty vector, data() == &front().</p>
|
13689 |
|
|
<p><b>Complexity:</b> Constant time.</p>
|
13690 |
|
|
<p><b>Throws:</b> Nothing.</p>
|
13691 |
|
|
</blockquote>
|
13692 |
|
|
|
13693 |
|
|
<p>In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, add the following to the <tt>map</tt>
|
13694 |
|
|
synopsis immediately after the line for operator[]:</p>
|
13695 |
|
|
<pre> T& at(const key_type& x);
|
13696 |
|
|
const T& at(const key_type& x) const;
|
13697 |
|
|
</pre>
|
13698 |
|
|
|
13699 |
|
|
<p>Add the following to 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a>:</p>
|
13700 |
|
|
<blockquote>
|
13701 |
|
|
<pre> T& at(const key_type& x);
|
13702 |
|
|
const T& at(const key_type& x) const;
|
13703 |
|
|
</pre>
|
13704 |
|
|
|
13705 |
|
|
<p><b>Returns:</b> A reference to the element whose key is equivalent
|
13706 |
|
|
to x, if such an element is present in the map.</p>
|
13707 |
|
|
<p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
|
13708 |
|
|
|
13709 |
|
|
</blockquote>
|
13710 |
|
|
|
13711 |
|
|
<p><b>Rationale:</b></p>
|
13712 |
|
|
<p>Neither of these additions provides any new functionality but the
|
13713 |
|
|
LWG agreed that they are convenient, especially for novices. The
|
13714 |
|
|
exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
|
13715 |
|
|
was chosen to match <tt>vector::at</tt>.</p>
|
13716 |
|
|
<hr>
|
13717 |
|
|
<a name="465"><h3>465. Contents of <ciso646></h3></a><p><b>Section:</b> 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 3 Jun 2004</p>
|
13718 |
|
|
<p>C header <iso646.h> defines macros for some operators, such as
|
13719 |
|
|
not_eq for !=.</p>
|
13720 |
|
|
|
13721 |
|
|
<p>Section 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> "Headers" says that except as noted in
|
13722 |
|
|
clauses 18 through 27, the <cname> C++ header contents are the same
|
13723 |
|
|
as the C header <name.h>. In particular, table 12 lists
|
13724 |
|
|
<ciso646> as a C++ header.</p>
|
13725 |
|
|
|
13726 |
|
|
<p>I don't find any other mention of <ciso646>, or any mention of
|
13727 |
|
|
<iso646.h>, in clauses 17 thorough 27. That implies that the
|
13728 |
|
|
contents of <ciso646> are the same as C header <iso646.h>.</p>
|
13729 |
|
|
|
13730 |
|
|
<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
|
13731 |
|
|
"Header <iso646.h>" says that the alternative tokens are not
|
13732 |
|
|
defined as macros in <ciso646>, but does not mention the contents
|
13733 |
|
|
of <iso646.h>.</p>
|
13734 |
|
|
|
13735 |
|
|
<p>I don't find any normative text to support C.2.2.2.</p>
|
13736 |
|
|
|
13737 |
|
|
<p><b>Proposed resolution:</b></p>
|
13738 |
|
|
<p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
|
13739 |
|
|
paragraph 6 (the one about functions must be functions):</p>
|
13740 |
|
|
|
13741 |
|
|
<blockquote>
|
13742 |
|
|
<p>Identifiers that are keywords or operators in C++ shall not be defined
|
13743 |
|
|
as macros in C++ standard library headers.
|
13744 |
|
|
[Footnote:In particular, including the standard header <iso646.h>
|
13745 |
|
|
or <ciso646> has no effect. </p>
|
13746 |
|
|
</blockquote>
|
13747 |
|
|
|
13748 |
|
|
<p><i>[post-Redmond: Steve provided wording.]</i></p>
|
13749 |
|
|
|
13750 |
|
|
<hr>
|
13751 |
|
|
<a name="467"><h3>467. char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b> 21.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.char"> [lib.char.traits.specializations.char]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p>
|
13752 |
|
|
|
13753 |
|
|
<p>
|
13754 |
|
|
Table 37 describes the requirements on Traits::compare() in terms of
|
13755 |
|
|
those on Traits::lt(). 21.1.3.1, p6 requires char_traits<char>::lt()
|
13756 |
|
|
to yield the same result as operator<(char, char).
|
13757 |
|
|
</p>
|
13758 |
|
|
|
13759 |
|
|
<p>
|
13760 |
|
|
Most, if not all, implementations of char_traits<char>::compare()
|
13761 |
|
|
call memcmp() for efficiency. However, the C standard requires both
|
13762 |
|
|
memcmp() and strcmp() to interpret characters under comparison as
|
13763 |
|
|
unsigned, regardless of the signedness of char. As a result, all
|
13764 |
|
|
these char_traits implementations fail to meet the requirement
|
13765 |
|
|
imposed by Table 37 on compare() when char is signed.
|
13766 |
|
|
</p>
|
13767 |
|
|
|
13768 |
|
|
|
13769 |
|
|
<p>Read email thread starting with c++std-lib-13499 for more. </p>
|
13770 |
|
|
<p><b>Proposed resolution:</b></p>
|
13771 |
|
|
|
13772 |
|
|
|
13773 |
|
|
<p>Change 21.1.3.1, p6 from</p>
|
13774 |
|
|
<blockquote>
|
13775 |
|
|
The two-argument members assign, eq, and lt are defined identically
|
13776 |
|
|
to the built-in operators =, ==, and < respectively.
|
13777 |
|
|
</blockquote>
|
13778 |
|
|
<p>to</p>
|
13779 |
|
|
<blockquote>
|
13780 |
|
|
The two-argument member assign is defined identically to
|
13781 |
|
|
the built-in operator =. The two
|
13782 |
|
|
argument members eq and lt are defined identically to
|
13783 |
|
|
the built-in operators == and < for type unsigned char.
|
13784 |
|
|
</blockquote>
|
13785 |
|
|
|
13786 |
|
|
<p><i>[Redmond: The LWG agreed with this general direction, but we
|
13787 |
|
|
also need to change <tt>eq</tt> to be consistent with this change.
|
13788 |
|
|
Post-Redmond: Martin provided wording.]</i></p>
|
13789 |
|
|
|
13790 |
|
|
<hr>
|
13791 |
|
|
<a name="468"><h3>468. unexpected consequences of ios_base::operator void*()</h3></a><p><b>Section:</b> 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p>
|
13792 |
|
|
|
13793 |
|
|
<p>The program below is required to compile but when run it typically
|
13794 |
|
|
produces unexpected results due to the user-defined conversion from
|
13795 |
|
|
std::cout or any object derived from basic_ios to void*.
|
13796 |
|
|
</p>
|
13797 |
|
|
|
13798 |
|
|
<pre> #include <cassert>
|
13799 |
|
|
#include <iostream>
|
13800 |
|
|
|
13801 |
|
|
int main ()
|
13802 |
|
|
{
|
13803 |
|
|
assert (std::cin.tie () == std::cout);
|
13804 |
|
|
// calls std::cout.ios::operator void*()
|
13805 |
|
|
}
|
13806 |
|
|
</pre>
|
13807 |
|
|
|
13808 |
|
|
<p><b>Proposed resolution:</b></p>
|
13809 |
|
|
|
13810 |
|
|
<p>
|
13811 |
|
|
Replace std::basic_ios<charT, traits>::operator void*() with another
|
13812 |
|
|
conversion operator to some unspecified type that is guaranteed not
|
13813 |
|
|
to be convertible to any other type except for bool (a pointer-to-member
|
13814 |
|
|
might be one such suitable type). In addition, make it clear that the
|
13815 |
|
|
pointer type need not be a pointer to a complete type and when non-null,
|
13816 |
|
|
the value need not be valid.
|
13817 |
|
|
</p>
|
13818 |
|
|
|
13819 |
|
|
<p>Specifically, change in [lib.ios] the signature of</p>
|
13820 |
|
|
<pre> operator void*() const;
|
13821 |
|
|
</pre>
|
13822 |
|
|
<p>to</p>
|
13823 |
|
|
<pre> operator unspecified-bool-type() const;
|
13824 |
|
|
</pre>
|
13825 |
|
|
<p>and change [lib.iostate.flags], p1 from</p>
|
13826 |
|
|
<pre> operator void*() const;
|
13827 |
|
|
</pre>
|
13828 |
|
|
<p>to</p>
|
13829 |
|
|
<pre>operator unspecified-bool-type() const;
|
13830 |
|
|
|
13831 |
|
|
-1- Returns: if fail() then a value that will evaluate false in a
|
13832 |
|
|
boolean context; otherwise a value that will evaluate true in a
|
13833 |
|
|
boolean context. The value type returned shall not be
|
13834 |
|
|
convertible to int.
|
13835 |
|
|
|
13836 |
|
|
-2- [Note: This conversion can be used in contexts where a bool
|
13837 |
|
|
is expected (e.g., an if condition); however, implicit
|
13838 |
|
|
conversions (e.g., to int) that can occur with bool are not
|
13839 |
|
|
allowed, eliminating some sources of user error. One possible
|
13840 |
|
|
implementation choice for this type is pointer-to-member. - end
|
13841 |
|
|
note]
|
13842 |
|
|
</pre>
|
13843 |
|
|
|
13844 |
|
|
<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
|
13845 |
|
|
<p><i>[Lillehammer: Doug provided revised wording for
|
13846 |
|
|
"unspecified-bool-type".]</i></p>
|
13847 |
|
|
|
13848 |
|
|
<hr>
|
13849 |
|
|
<a name="469"><h3>469. vector<bool> ill-formed relational operators</h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p>
|
13850 |
|
|
|
13851 |
|
|
<p>
|
13852 |
|
|
The overloads of relational operators for vector<bool> specified
|
13853 |
|
|
in [lib.vector.bool] are redundant (they are semantically identical
|
13854 |
|
|
to those provided for the vector primary template) and may even be
|
13855 |
|
|
diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
|
13856 |
|
|
in c++std-lib-13647).
|
13857 |
|
|
</p>
|
13858 |
|
|
|
13859 |
|
|
<p><b>Proposed resolution:</b></p>
|
13860 |
|
|
<p>
|
13861 |
|
|
Remove all overloads of overloads of relational operators for
|
13862 |
|
|
vector<bool> from [lib.vector.bool].
|
13863 |
|
|
</p>
|
13864 |
|
|
<hr>
|
13865 |
|
|
<a name="474"><h3>474. confusing Footnote 297</h3></a><p><b>Section:</b> 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 1 Jul 2004</p>
|
13866 |
|
|
|
13867 |
|
|
<p>
|
13868 |
|
|
I think Footnote 297 is confused. The paragraph it applies to seems
|
13869 |
|
|
quite clear in that widen() is only called if the object is not a char
|
13870 |
|
|
stream (i.e., not basic_ostream<char>), so it's irrelevant what the
|
13871 |
|
|
value of widen(c) is otherwise.
|
13872 |
|
|
</p>
|
13873 |
|
|
<p><b>Proposed resolution:</b></p>
|
13874 |
|
|
<p>
|
13875 |
|
|
I propose to strike the Footnote.
|
13876 |
|
|
</p>
|
13877 |
|
|
<hr>
|
13878 |
|
|
<a name="496"><h3>496. Illegal use of "T" in vector<bool></h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 10 Feb 2005</p>
|
13879 |
|
|
<p>
|
13880 |
|
|
In the synopsis of the std::vector<bool> specialisation in 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>,
|
13881 |
|
|
the non-template assign() function has the signature</p>
|
13882 |
|
|
|
13883 |
|
|
<pre> void assign( size_type n, const T& t );
|
13884 |
|
|
</pre>
|
13885 |
|
|
|
13886 |
|
|
<p>The type, T, is not defined in this context.</p>
|
13887 |
|
|
<p><b>Proposed resolution:</b></p>
|
13888 |
|
|
<p>Replace "T" with "value_type".</p>
|
13889 |
|
|
<p>----- End of document -----</p>
|
13890 |
|
|
</body></html>
|