1<!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>
3
4<style>ins {background-color:#FFFFA0}
5del {background-color:#FFFFA0}</style></head>
6
7<body bgcolor="#ffffff" text="#000000">
8<table>
9<tbody><tr>
10<td align="left">Doc. no.</td>
11<td align="left">N2131=06-0201</td>
12</tr>
13<tr>
14<td align="left">Date:</td>
15<td align="left">2006-11-03</td>
16</tr>
17<tr>
18<td align="left">Project:</td>
19<td align="left">Programming Language C++</td>
20</tr>
21<tr>
22<td align="left">Reply to:</td>
23<td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
24</tr>
25</tbody></table>
26<h1>C++ Standard Library Defect Report List (Revision R45)</h1>
27  <p>Reference ISO/IEC IS 14882:1998(E)</p>
28  <p>Also see:</p>
29    <ul>
30      <li>
31<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
32      <li>
33<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
34      <li>
35<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
36      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
37      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
38    </ul>
39  <p>This document contains only library issues which have been closed
40  by the Library Working Group (LWG) after being found to be defects
41  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
42  <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
43  <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
44  introductory material in that document also applies to this
45  document.</p>
46<h2>Revision History</h2>
47<ul>
48<li>R45:
492006-11-03 post-Portland mailing.
50Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP.
51Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD.
52Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.
53Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <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#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.
54Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#605">605</a> to Ready.
55Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</a> to Review.
56Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#609">609</a>.
57</li>
58<li>R44:
592006-09-08 pre-Portland mailing.
60Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#592">592</a>.
61</li>
62<li>R43:
632006-06-23 mid-term mailing.
64Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.
65Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.
66Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.
67</li>
68<li>R42:
692006-04-21 post-Berlin mailing.
70Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#572">572</a>.
71Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.
72Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#548">548</a> to Open.
73Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.
74Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.
75Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#534">534</a> to Review.
76</li>
77<li>R41:
782006-02-24 pre-Berlin mailing.
79Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#566">566</a>.
80Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.
81Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.
82</li>
83<li>R40:
842005-12-16 mid-term mailing.
85Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.
86</li>
87<li>R39:
882005-10-14 post-Mont Tremblant mailing.
89Added 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>.
90Moved 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.
91Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
92Moved 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-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
93Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
94Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
95Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
96</li>
97<li>R38:
982005-07-03 pre-Mont Tremblant mailing.
99Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
100Added 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>
101</li>
102<li>R37:
1032005-06 mid-term mailing.
104Added 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>.
105</li>
106<li>R36:
1072005-04 post-Lillehammer mailing. All issues in "ready" status except
108for <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
109previously in "DR" status were moved to "WP".
110</li>
111<li>R35:
1122005-03 pre-Lillehammer mailing.
113</li>
114<li>R34:
1152005-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>.
116</li>
117<li>R33:
1182004-11 post-Redmond mailing. Reflects actions taken in Redmond.
119</li>
120<li>R32:
1212004-09 pre-Redmond mailing: reflects new proposed resolutions and
122new issues received after the 2004-07 mailing.  Added
123new 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>.
124</li>
125<li>R31:
1262004-07 mid-term mailing: reflects new proposed resolutions and
127new issues received after the post-Sydney mailing.  Added
128new 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-defects.html#478">478</a>.
129</li>
130<li>R30:
131Post-Sydney mailing: reflects decisions made at the Sydney meeting.
132Voted all "Ready" issues from R29 into the working paper.
133Added 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>.
134</li>
135<li>R29:
136Pre-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>.
137</li>
138<li>R28:
139Post-Kona mailing: reflects decisions made at the Kona meeting.
140Added 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>.
141</li>
142<li>R27:
143Pre-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>.
144</li>
145<li>R26:
146Post-Oxford mailing: reflects decisions made at the Oxford meeting.
147All issues in Ready status were voted into DR status.  All issues in
148DR status were voted into WP status.
149</li>
150<li>R25:
151Pre-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>.
152</li>
153<li>R24:
154Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
155meeting.  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
156moved 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
157at 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
158concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
159</li>
160<li>R23:
161Pre-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>.
162Moved issues in the TC to TC status.
163</li>
164<li>R22:
165Post-Cura�ao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
166</li>
167<li>R21:
168Pre-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>.
169</li>
170<li>R20:
171Post-Redmond mailing; reflects actions taken in Redmond.  Added
172new 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
173<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
174not discussed at the meeting.
175
176All Ready issues were moved to DR status, with the exception of issues
177<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>.
178
179Noteworthy issues discussed at Redmond include
180<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>,
181<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>.
182</li>
183<li>R19:
184Pre-Redmond mailing.  Added new issues
185<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>.
186</li>
187<li>R18:
188Post-Copenhagen mailing; reflects actions taken in Copenhagen.
189Added 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
190new 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>.
191
192Changed status of issues
193<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>
194<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>
195<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>
196<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>
197<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>
198<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>
199<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
200to DR.
201
202Changed status of issues
203<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>
204<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>
205<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>
206<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>
207<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>
208<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>
209<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>
210<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>
211<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>
212to Ready.
213
214Closed issues
215<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>
216<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>
217<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
218as NAD.
219
220</li>
221<li>R17:
222Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
223resolutions 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>.
224Added 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>.
225</li>
226<li>R16:
227post-Toronto mailing; reflects actions taken in Toronto. Added new
228issues <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
229<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>,
230<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>,
231<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>,
232<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>,
233<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>,
234<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>,
235<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>,
236<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>,
237<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>,
238<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>,
239<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>,
240<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>,
241<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
242issue <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
243<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
244issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
245appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
246the bug in enough places.
247</li>
248<li>R15:
249pre-Toronto mailing. Added issues
250<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
251changes so that we pass Weblint tests.
252</li>
253<li>R14:
254post-Tokyo II mailing; reflects committee actions taken in
255Tokyo. 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)
256</li>
257<li>R13:
258pre-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>.
259</li>
260<li>R12:
261pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
262<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
263of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
264<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
265</li>
266<li>R11:
267post-Kona mailing: Updated to reflect LWG and full committee actions
268in Kona (99-0048/N1224). Note changed resolution of issues
269<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>
270to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
271"closed" documents.  Changed the proposed resolution of issue
272<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
273of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
274</li>
275<li>R10:
276pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
277<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>,
278<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
279<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
280</li>
281<li>R9:
282pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
283<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
284"closed" documents. (99-0030/N1206, 25 Aug 99)
285</li>
286<li>R8:
287post-Dublin mailing. Updated to reflect LWG and full committee actions
288in Dublin. (99-0016/N1193, 21 Apr 99)
289</li>
290<li>R7:
291pre-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>,
292<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>,
293<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>,
294<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)
295</li>
296<li>R6:
297pre-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>,
298and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
299</li>
300<li>R5:
301update 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
302<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
303for making list public. (30 Dec 98)
304</li>
305<li>R4:
306post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
307<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
308issues corrected. (22 Oct 98)
309</li>
310<li>R3:
311post-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>
312added, many issues updated to reflect LWG consensus (12 Oct 98)
313</li>
314<li>R2:
315pre-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,
316issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
317</li>
318<li>R1:
319Correction 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
320format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
321</li>
322</ul>
323<h2>Defect Reports</h2>
324<hr>
325<a name="1"><h3>1.&nbsp;C library linkage editing oversight</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;16 Nov 1997</p>
326<p>The change specified in the proposed resolution below did not make
327it into the Standard. This change was accepted in principle at the
328London meeting, and the exact wording below was accepted at the
329Morristown meeting.</p>
330<p><b>Proposed resolution:</b></p>
331<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
332from:</p>
333
334<blockquote>
335  <p>It is unspecified whether a name from the Standard C library
336  declared with external linkage has either extern "C" or
337  extern "C++" linkage.</p>
338</blockquote>
339
340<p>to:</p>
341
342<blockquote>
343  <p>Whether a name from the Standard C library declared with external
344  linkage has extern "C" or extern "C++" linkage
345  is implementation defined. It is recommended that an implementation
346  use extern "C++" linkage for this purpose.</p>
347</blockquote>
348<hr>
349<a name="3"><h3>3.&nbsp;Atexit registration during atexit() call is not described</h3></a><p><b>Section:</b>&nbsp;18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.cstdint"> [lib.cstdint]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;12 Dec 1997</p>
350<p>We appear not to have covered all the possibilities of
351 exit processing with respect to
352atexit registration. <br>
353<br>
354Example 1: (C and C++)</p>
355
356<pre>    #include &lt;stdlib.h&gt;
357    void f1() { }
358    void f2() { atexit(f1); }
359
360    int main()
361    {
362        atexit(f2); // the only use of f2
363        return 0; // for C compatibility
364    }</pre>
365
366<p>At program exit, f2 gets called due to its registration in
367main. Running f2 causes f1 to be newly registered during the exit
368processing. Is this a valid program? If so, what are its
369semantics?</p>
370
371<p>
372Interestingly, neither the C standard, nor the C++ draft standard nor
373the forthcoming C9X Committee Draft says directly whether you can
374register a function with atexit during exit processing.</p>
375
376<p>
377All 3 standards say that functions are run in reverse order of their
378registration. Since f1 is registered last, it ought to be run first,
379but by the time it is registered, it is too late to be first.</p>
380
381<p>If the program is valid, the standards are self-contradictory about
382its semantics.</p>
383
384<p>Example 2: (C++ only)</p>
385
386<pre>
387    void F() { static T t; } // type T has a destructor
388
389    int main()
390    {
391        atexit(F); // the only use of F
392    }
393</pre>
394
395<p>Function F registered with atexit has a local static variable t,
396and F is called for the first time during exit processing. A local
397static object is initialized the first time control flow passes
398through its definition, and all static objects are destroyed during
399exit processing. Is the code valid? If so, what are its semantics?</p>
400
401<p>
402Section 18.3 "Start and termination" says that if a function
403F is registered with atexit before a static object t is initialized, F
404will not be called until after t's destructor completes.</p>
405
406<p>
407In example 2, function F is registered with atexit before its local
408static object O could possibly be initialized. On that basis, it must
409not be called by exit processing until after O's destructor
410completes. But the destructor cannot be run until after F is called,
411since otherwise the object could not be constructed in the first
412place.</p>
413
414<p>If the program is valid, the standard is self-contradictory about
415its semantics.</p>
416
417<p>I plan to submit Example 1 as a public comment on the C9X CD, with
418a recommendation that the results be undefined. (Alternative: make it
419unspecified. I don't think it is worthwhile to specify the case where
420f1 itself registers additional functions, each of which registers
421still more functions.)</p>
422
423<p>I think we should resolve the situation in the whatever way the C
424committee decides. </p>
425
426<p>For Example 2, I recommend we declare the results undefined.</p>
427
428<p><i>[See reflector message lib-6500 for further discussion.]</i></p>
429
430<p><b>Proposed resolution:</b></p>
431<p>Change section 18.3/8 from:</p>
432<blockquote>
433  First, objects with static storage duration are destroyed and
434  functions registered by calling atexit are called. Objects with
435  static storage duration are destroyed in the reverse order of the
436  completion of their constructor.  (Automatic objects are not
437  destroyed as a result of calling exit().) Functions registered with
438  atexit are called in the reverse order of their registration.  A
439  function registered with atexit before an object obj1 of static
440  storage duration is initialized will not be called until obj1's
441  destruction has completed. A function registered with atexit after
442  an object obj2 of static storage duration is initialized will be
443  called before obj2's destruction starts.
444</blockquote>
445<p>to:</p>
446<blockquote>
447  First, objects with static storage duration are destroyed and
448  functions registered by calling atexit are called. Non-local objects
449  with static storage duration are destroyed in the reverse order of
450  the completion of their constructor. (Automatic objects are not
451  destroyed as a result of calling exit().) Functions registered with
452  atexit are called in the reverse order of their registration, except
453  that a function is called after any previously registered functions
454  that had already been called at the time it was registered. A
455  function registered with atexit before a non-local object obj1 of
456  static storage duration is initialized will not be called until
457  obj1's destruction has completed. A function registered with atexit
458  after a non-local object obj2 of static storage duration is
459  initialized will be called before obj2's destruction starts. A local
460  static object obj3 is destroyed at the same time it would be if a
461  function calling the obj3 destructor were registered with atexit at
462  the completion of the obj3 constructor.
463</blockquote>
464<p><b>Rationale:</b></p>
465<p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
466supporting to the proposed resolution.</p>
467<hr>
468<a name="5"><h3>5.&nbsp;String::compare specification questionable</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jack Reeves&nbsp; <b>Date:</b>&nbsp;11 Dec 1997</p>
469<p>At the very end of the basic_string class definition is the signature: int
470compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
471following text this is defined as: returns
472basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
473basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
474
475<p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
476= Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
477throws length_error if n == npos, it appears the compare() signature above should always
478throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
479null terminated character array. </p>
480
481<p>This appears to be a typo since the obvious intent is to allow either the call above or
482something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
483
484<p>This would imply that what was really intended was two signatures int compare(size_type
485pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
486charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
487<p><b>Proposed resolution:</b></p>
488<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>
489(at the very end of the basic_string synopsis) which reads:</p>
490
491<blockquote>
492  <p><tt>int compare(size_type pos1, size_type n1,<br>
493  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
494  size_type n2 = npos) const;</tt></p>
495</blockquote>
496
497<p>with:</p>
498
499<blockquote>
500  <p><tt>int compare(size_type pos1, size_type n1,<br>
501  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
502  int compare(size_type pos1, size_type n1,<br>
503  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
504  size_type n2) const;</tt></p>
505</blockquote>
506
507<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>
508paragraphs 5 and 6 which read:</p>
509
510<blockquote>
511  <p><tt>int compare(size_type pos, size_type n1,<br>
512  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
513  = npos) const;<br>
514  </tt>Returns:<tt><br>
515  basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
516  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
517  basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
518</blockquote>
519
520<p>with:</p>
521
522<blockquote>
523  <p><tt>int compare(size_type pos, size_type n1,<br>
524  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
525  </tt>Returns:<tt><br>
526  basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
527  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
528  basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
529  <br>
530  int compare(size_type pos, size_type n1,<br>
531  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
532  size_type n2) const;<br>
533  </tt>Returns:<tt><br>
534  basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
535  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
536  basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
537</blockquote>
538
539<p>Editors please note that in addition to splitting the signature, the third argument
540becomes const, matching the existing synopsis.</p>
541<p><b>Rationale:</b></p>
542<p>While the LWG dislikes adding signatures, this is a clear defect in
543the Standard which must be fixed.&nbsp; The same problem was also
544identified in issues 7 (item 5) and 87.</p>
545<hr>
546<a name="7"><h3>7.&nbsp;String clause minor problems</h3></a><p><b>Section:</b>&nbsp;21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;15 Dec 1997</p>
547<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
548&lt;class InputIterator&gt; insert(iterator, InputIterator,
549InputIterator) makes no sense. It refers to a member function that
550doesn't exist. It also talks about the return value of a void
551function. </p>
552
553<p>(2) Several versions of basic_string::replace don't appear in the
554class synopsis. </p>
555
556<p>(3) basic_string::push_back appears in the synopsis, but is never
557described elsewhere.  In the synopsis its argument is const charT,
558which doesn't makes much sense; it should probably be charT, or
559possible const charT&amp;. </p>
560
561<p>(4) basic_string::pop_back is missing. </p>
562
563<p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
564= npos) make no sense. First, it's const charT* in the synopsis and
565charT* in the description. Second, given what it says in RETURNS,
566leaving out the final argument will always result in an exception
567getting thrown. This is paragraphs 5 and 6 of
56821.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>
569
570<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>,
571there's a note for X::move(s, p, n). It says "Copies correctly
572even where p is in [s, s+n)". This is correct as far as it goes,
573but it doesn't go far enough; it should also guarantee that the copy
574is correct even where s in in [p, p+n). These are two orthogonal
575guarantees, and neither one follows from the other. Both guarantees
576are necessary if X::move is supposed to have the same sort of
577semantics as memmove (which was clearly the intent), and both
578guarantees are necessary if X::move is actually supposed to be
579useful. </p>
580<p><b>Proposed resolution:</b></p>
581<p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
582<br>
583&nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
584<br>
585ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
586the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
587<br>
588ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
589[lib.basic.string]) from:</p>
590
591<p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
592<br>
593to<br>
594<br>
595&nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
596<br>
597Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
598<br>
599&nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
600&nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
601<br>
602ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
603<br>
604ITEM 5: Duplicate; see issue 5 (and 87).<br>
605<br>
606ITEM 6: In table 37, Replace:<br>
607<br>
608&nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
609<br>
610with:<br>
611<br>
612&nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
613s+n) overlap."</p>
614<hr>
615<a name="8"><h3>8.&nbsp;Locale::global lacks guarantee</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Dec 1997</p>
616<p>It appears there's an important guarantee missing from clause
61722. We're told that invoking locale::global(L) sets the C locale if L
618has a name. However, we're not told whether or not invoking
619setlocale(s) sets the global C++ locale. </p>
620
621<p>The intent, I think, is that it should not, but I can't find any
622such words anywhere. </p>
623<p><b>Proposed resolution:</b></p>
624<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>,
625paragraph 2:&nbsp; </p>
626
627<blockquote>
628  <p>No library function other than <tt>locale::global()</tt> shall affect
629  the value returned by <tt>locale()</tt>. </p>
630
631</blockquote>
632<hr>
633<a name="9"><h3>9.&nbsp;Operator new(0) calls should not yield the same pointer</h3></a><p><b>Section:</b>&nbsp;18.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;4 Jan 1998</p>
634<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
635section 3.7.3.1 of CD2 seems to allow for the possibility that all
636calls to operator new(0) yield the same pointer, an implementation
637technique specifically prohibited by ARM 5.3.3.Was this prohibition
638really lifted? Does the FDIS agree with CD2 in the regard? [Issues
639list maintainer's note: the IS is the same.]</p>
640<p><b>Proposed resolution:</b></p>
641<p>Change the last paragraph of 3.7.3 from:</p>
642<blockquote>
643  <p>Any allocation and/or deallocation functions defined in a C++ program shall
644  conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
645</blockquote>
646<p>to:</p>
647<blockquote>
648  <p>Any allocation and/or deallocation functions defined in a C++ program,
649  including the default versions in the library, shall conform to the semantics
650  specified in 3.7.3.1 and 3.7.3.2.</p>
651</blockquote>
652<p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
653<blockquote>
654  <p>If the size of the space requested is zero, the value returned shall not be
655  a null pointer value (4.10).</p>
656</blockquote>
657<p>to:</p>
658<blockquote>
659  <p>Even if the size of the space requested is zero, the request can fail. If
660  the request succeeds, the value returned shall be a non-null pointer value
661  (4.10) p0 different from any previously returned value p1, unless that value
662  p1 was since passed to an operator delete.</p>
663</blockquote>
664<p>5.3.4/7 currently reads:</p>
665<blockquote>
666  <p>When the value of the expression in a direct-new-declarator is zero, the
667  allocation function is called to allocate an array with no elements. The
668  pointer returned by the new-expression is non-null. [Note: If the library
669  allocation function is called, the pointer returned is distinct from the
670  pointer to any other object.]</p>
671</blockquote>
672<p>Retain the first sentence, and delete the remainder.</p>
673<p>18.5.1 currently has no text. Add the following:</p>
674<blockquote>
675  <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
676  library versions of operator new and operator delete.</p>
677</blockquote>
678<p>To 18.5.1.3, add the following text:</p>
679<blockquote>
680  <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
681  operator new and operator delete.</p>
682</blockquote>
683<p><b>Rationale:</b></p>
684<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
685supporting to the proposed resolution.</p>
686<hr>
687<a name="11"><h3>11.&nbsp;Bitset minor problems</h3></a><p><b>Section:</b>&nbsp;23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Jan 1998</p>
688<p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
689not documented in 23.3.5.2. </p>
690
691<p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
692reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
693on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
694
695<p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
696trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
697go in the Effects clause.</p>
698<p><b>Proposed resolution:</b></p>
699<p>ITEMS 1 AND 2:<br>
700<br>
701In 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>),
702replace the member function <br>
703<br>
704<tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
705</tt><br>
706with the two member functions<br>
707<br>
708<tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
709&nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
710</tt><br>
711Add 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>,
712immediately after paragraph 45:</p>
713
714<blockquote>
715  <p><tt>bool operator[](size_t pos) const;</tt><br>
716  Requires: pos is valid<br>
717  Throws: nothing<br>
718  Returns: <tt>test(pos)</tt><br>
719  <br>
720  <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
721  Requires: pos is valid<br>
722  Throws: nothing<br>
723  Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
724  == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
725  val);</tt></p>
726</blockquote>
727<p><b>Rationale:</b></p>
728<p>The LWG believes Item 3 is not a defect. "Formatted
729input" 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>.
730</p>
731<hr>
732<a name="13"><h3>13.&nbsp;Eos refuses to die</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;William M. Miller&nbsp; <b>Date:</b>&nbsp;3 Mar 1998</p>
733<p>In 27.6.1.2.3, there is a reference to "eos", which is
734the only one in the whole draft (at least using Acrobat search), so
735it's undefined. </p>
736<p><b>Proposed resolution:</b></p>
737<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
738"charT()"</p>
739<hr>
740<a name="14"><h3>14.&nbsp;Locale::combine should be const</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
741<p>locale::combine is the only member function of locale (other than constructors and
742destructor) that is not const. There is no reason for it not to be const, and good reasons
743why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
744paragraph 6: "An instance of a locale is immutable." </p>
745
746<p>History: this member function originally was a constructor. it happened that the
747interface it specified had no corresponding language syntax, so it was changed to a member
748function. As constructors are never const, there was no "const" in the interface
749which was transformed into member "combine". It should have been added at that
750time, but the omission was not noticed. </p>
751<p><b>Proposed resolution:</b></p>
752<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
753"const" to the declaration of member combine: </p>
754<blockquote>
755  <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
756</blockquote>
757<hr>
758<a name="15"><h3>15.&nbsp;Locale::name requirement inconsistent</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
759<p>locale::name() is described as returning a string that can be passed to a locale
760constructor, but there is no matching constructor. </p>
761<p><b>Proposed resolution:</b></p>
762<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
763"<tt>locale(name())</tt>" with
764"<tt>locale(name().c_str())</tt>".
765</p>
766<hr>
767<a name="16"><h3>16.&nbsp;Bad ctype_byname&lt;char&gt; decl</h3></a><p><b>Section:</b>&nbsp;22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
768<p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
769edited in properly. Instead, the member do_widen appears four times, with wrong argument
770lists. </p>
771<p><b>Proposed resolution:</b></p>
772<p>The correct declarations for the overloaded members
773<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
774from 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>
775<hr>
776<a name="17"><h3>17.&nbsp;Bad bool parsing</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
777<p>This section describes the process of parsing a text boolean value from the input
778stream. It does not say it recognizes either of the sequences "true" or
779"false" and returns the corresponding bool value; instead, it says it recognizes
780only one of those sequences, and chooses which according to the received value of a
781reference argument intended for returning the result, and reports an error if the other
782sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
783facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
784flag wrongly; it doesn't define the value "loc"; and finally, it computes
785wrongly whether to use numeric or "alpha" parsing.<br>
786<br>
787I believe the correct algorithm is "as if": </p>
788
789<pre>  // in, err, val, and str are arguments.
790  err = 0;
791  const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
792  const string_type t = np.truename(), f = np.falsename();
793  bool tm = true, fm = true;
794  size_t pos = 0;
795  while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
796    if (in == end) { err = str.eofbit; }
797    bool matched = false;
798    if (tm &amp;&amp; pos &lt; t.size()) {
799      if (!err &amp;&amp; t[pos] == *in) matched = true;
800      else tm = false;
801    }
802    if (fm &amp;&amp; pos &lt; f.size()) {
803      if (!err &amp;&amp; f[pos] == *in) matched = true;
804      else fm = false;
805    }
806    if (matched) { ++in; ++pos; }
807    if (pos &gt; t.size()) tm = false;
808    if (pos &gt; f.size()) fm = false;
809  }
810  if (tm == fm || pos == 0) { err |= str.failbit; }
811  else                      { val = tm; }
812  return in;</pre>
813
814<p>Notice this works reasonably when the candidate strings are both empty, or equal, or
815when one is a substring of the other. The proposed text below captures the logic of the
816code above.</p>
817<p><b>Proposed resolution:</b></p>
818<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,
819change "&amp;&amp;" to "&amp;".</p>
820
821<p>Then, replace paragraphs 15 and 16 as follows:</p>
822
823<blockquote>
824
825  <p>Otherwise target sequences are determined "as if" by
826  calling the members <tt>falsename()</tt> and
827  <tt>truename()</tt> of the facet obtained by
828  <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.
829  Successive characters in the range <tt>[in,end)</tt> (see
830  [lib.sequence.reqmts]) are obtained and matched against
831  corresponding positions in the target sequences only as necessary to
832  identify a unique match. The input iterator <tt>in</tt> is
833  compared to <tt>end</tt> only when necessary to obtain a
834  character. If and only if a target sequence is uniquely matched,
835  <tt>val</tt> is set to the corresponding value.</p>
836
837</blockquote>
838
839<blockquote>
840  <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
841  successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
842  <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
843  <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
844  <tt>(str.failbit|str.eofbit)</tt>if
845  the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
846  <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
847  <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
848  <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
849  <tt>true</tt>:"1"
850  and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
851  and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
852  <tt>err==str.failbit</tt>. --end example]</p>
853</blockquote>
854<hr>
855<a name="18"><h3>18.&nbsp;Get(...bool&amp;) omitted</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
856<p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
857that parses bool values was omitted from the list of definitions of non-virtual
858members, though it is listed in the class definition and the corresponding
859virtual is listed everywhere appropriate. </p>
860<p><b>Proposed resolution:</b></p>
861<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>
862another get member for bool&amp;, copied from the entry in
86322.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>
864<hr>
865<a name="19"><h3>19.&nbsp;"Noconv" definition too vague</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
866<p>
867In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
868specified to return noconv if "no conversion is
869needed". This definition is too vague, and does not say
870normatively what is done with the buffers.
871</p>
872<p><b>Proposed resolution:</b></p>
873<p>
874Change the entry for noconv in the table under paragraph 4 in section
875<font color="red">22.2.1.5.2</font> to read:
876</p>
877<blockquote>
878  <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
879  and input sequence is identical to converted sequence.</p>
880</blockquote>
881<p>Change the Note in paragraph 2 to normative text as follows:</p>
882<blockquote>
883  <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
884  same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
885  <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
886  unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
887</blockquote>
888<hr>
889<a name="20"></a><h3><a name="20">20.&nbsp;Thousands_sep returns wrong type</a></h3><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
890<p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
891definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
892that it returns a value of type char_type. Here it is erroneously
893described as returning a "string_type". </p>
894<p><b>Proposed resolution:</b></p>
895<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
896"string_type" to "char_type". </p>
897<hr>
898<a name="21"><h3>21.&nbsp;Codecvt_byname&lt;&gt; instantiations</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
899<p>In the second table in the section, captioned "Required
900instantiations", the instantiations for codecvt_byname&lt;&gt;
901have been omitted. These are necessary to allow users to construct a
902locale by name from facets. </p>
903<p><b>Proposed resolution:</b></p>
904<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
905"Required instantiations", in the category "ctype"
906the lines </p>
907
908<blockquote>
909  <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
910codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
911</blockquote>
912<hr>
913<a name="22"><h3>22.&nbsp;Member open vs. flags</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
914<p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
915responds to or changes flags in the error status for the stream. A strict reading
916indicates that it ignores the bits and does not change them, which confuses users who do
917not expect eofbit and failbit to remain set after a successful open. There are three
918reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
919and eofbit on call to open(). </p>
920<p><b>Proposed resolution:</b></p>
921<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:
922</p>
923
924<blockquote>
925  <p>A successful open does not change the error state.</p>
926</blockquote>
927<p><b>Rationale:</b></p>
928<p>This may seem surprising to some users, but it's just an instance
929of a general rule: error flags are never cleared by the
930implementation. The only way error flags are are ever cleared is if
931the user explicitly clears them by hand.</p>
932
933<p>The LWG believed that preserving this general rule was
934important enough so that an exception shouldn't be made just for this
935one case.  The resolution of this issue clarifies what the LWG
936believes to have been the original intent.</p>
937
938<hr>
939<a name="24"><h3>24.&nbsp;"do_convert" doesn't exist</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
940<p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
941symbol "do_convert" which is not defined in the
942standard. This is a leftover from an edit, and should be "do_in
943and do_out". </p>
944<p><b>Proposed resolution:</b></p>
945<p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, paragraph 3, change
946"do_convert" to "do_in or do_out". Also, in <font color="red">22.2.1.5.2</font>, change "do_convert()" to "do_in
947or do_out". </p>
948<hr>
949<a name="25"><h3>25.&nbsp;String operator&lt;&lt; uses width() value wrong</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
950<p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
951the smaller of os.width() and str.size(), to pad "as described in stage 3"
952elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
953<p><b>Proposed resolution:</b></p>
954<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>
955<br>
956&nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
957..."<br>
958<br>
959to: <br>
960<br>
961&nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
962..."</p>
963<hr>
964<a name="26"><h3>26.&nbsp;Bad sentry example</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
965<p>In paragraph 6, the code in the example: </p>
966
967<pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
968  basic_istream&lt;charT,traits&gt;::sentry(
969           basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
970      ...
971      int_type c;
972      typedef ctype&lt;charT&gt; ctype_type;
973      const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
974      while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
975        if (ctype.is(ctype.space,c)==0) {
976          is.rdbuf()-&gt;sputbackc (c);
977          break;
978        }
979      }
980      ...
981   }</pre>
982
983<p>fails to demonstrate correct use of the facilities described. In
984particular, it fails to use traits operators, and specifies incorrect
985semantics. (E.g. it specifies skipping over the first character in the
986sequence without examining it.) </p>
987<p><b>Proposed resolution:</b></p>
988<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>
989paragraph 6.</p>
990<p><b>Rationale:</b></p>
991<p>The originally proposed replacement code for the example was not
992correct. The LWG tried in Kona and again in Tokyo to correct it
993without success. In Tokyo, an implementor reported that actual working
994code ran over one page in length and was quite complicated. The LWG
995decided that it would be counter-productive to include such a lengthy
996example, which might well still contain errors.</p>
997<hr>
998<a name="27"><h3>27.&nbsp;String::erase(range) yields wrong iterator</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
999<p>The string::erase(iterator first, iterator last) is specified to return an element one
1000place beyond the next element after the last one erased. E.g. for the string
1001"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
1002while 'd' has not been erased. </p>
1003<p><b>Proposed resolution:</b></p>
1004<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>
1005
1006<blockquote>
1007  <p>Returns: an iterator which points to the element immediately following _last_ prior to
1008  the element being erased. </p>
1009</blockquote>
1010
1011<p>to read </p>
1012
1013<blockquote>
1014  <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
1015  other elements being erased. </p>
1016</blockquote>
1017<hr>
1018<a name="28"><h3>28.&nbsp;Ctype&lt;char&gt;is ambiguous</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1019<p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
1020something very different from what was intended. Paragraph 4 says </p>
1021
1022<blockquote>
1023  <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
1024  table()[(unsigned char)*p]. </p>
1025</blockquote>
1026
1027<p>This is intended to copy the value indexed from table()[] into the place identified in
1028vec[]. </p>
1029<p><b>Proposed resolution:</b></p>
1030<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>
1031
1032<blockquote>
1033  <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
1034  the value table()[(unsigned char)*p]. </p>
1035</blockquote>
1036<hr>
1037<a name="29"><h3>29.&nbsp;Ios_base::init doesn't exist</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1038<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
1039a function ios_base::init, which is not defined. Probably they mean
1040basic_ios&lt;&gt;::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>,
1041paragraph 3. </p>
1042<p><b>Proposed resolution:</b></p>
1043<p>[R12: modified to include paragraph 5.]</p>
1044
1045<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>
1046
1047<blockquote>
1048  <p>ios_base::init </p>
1049</blockquote>
1050
1051<p>to </p>
1052
1053<blockquote>
1054  <p>basic_ios&lt;char&gt;::init </p>
1055</blockquote>
1056
1057<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
1058should read </p>
1059
1060<blockquote>
1061  <p>basic_ios&lt;wchar_t&gt;::init </p>
1062</blockquote>
1063<hr>
1064<a name="30"><h3>30.&nbsp;Wrong header for LC_*</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1065<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
1066where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
1067<p><b>Proposed resolution:</b></p>
1068<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
1069"&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
1070<hr>
1071<a name="31"><h3>31.&nbsp;Immutable locale values</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1072<p>Paragraph 6, says "An instance of <tt>locale</tt> is
1073<i>immutable</i>; once a facet reference is obtained from it,
1074...". This has caused some confusion, because locale variables
1075are manifestly assignable. </p>
1076<p><b>Proposed resolution:</b></p>
1077<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>
1078
1079<blockquote>
1080  <p>An instance of <tt>locale</tt> is immutable; once a facet
1081  reference is obtained from it, that reference remains usable as long
1082  as the locale value itself exists.</p>
1083</blockquote>
1084
1085<p>with</p>
1086
1087<blockquote>
1088  <p>Once a facet reference is obtained from a locale object by
1089  calling use_facet&lt;&gt;, that reference remains usable, and the
1090  results from member functions of it may be cached and re-used, as
1091  long as some locale object refers to that facet.</p>
1092</blockquote>
1093<hr>
1094<a name="32"><h3>32.&nbsp;Pbackfail description inconsistent</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1095<p>The description of the required state before calling virtual member
1096basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
1097described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
1098Specifically, the latter says it calls pbackfail if: </p>
1099
1100<p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
1101
1102<p>where pbackfail claims to require: </p>
1103
1104<p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
1105
1106<p>It appears that the pbackfail description is wrong. </p>
1107<p><b>Proposed resolution:</b></p>
1108<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>
1109
1110<blockquote>
1111  <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
1112</blockquote>
1113
1114<p>to </p>
1115
1116<blockquote>
1117  <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
1118  </p>
1119</blockquote>
1120<p><b>Rationale:</b></p>
1121<p>Note deliberate reordering of arguments for clarity in addition to the correction of
1122the argument value.</p>
1123<hr>
1124<a name="33"><h3>33.&nbsp;Codecvt&lt;&gt; mentions from_type</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1125<p>In the table defining the results from do_out and do_in, the specification for the
1126result <i>error</i> says </p>
1127
1128<blockquote>
1129  <p>encountered a from_type character it could not convert </p>
1130</blockquote>
1131
1132<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
1133an internT for do_out. </p>
1134<p><b>Proposed resolution:</b></p>
1135<p>In <font color="red">22.2.1.5.2</font> paragraph 4, replace the definition
1136in the table for the case of _error_ with </p>
1137
1138<blockquote>
1139  <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
1140</blockquote>
1141<hr>
1142<a name="34"><h3>34.&nbsp;True/falsename() not in ctype&lt;&gt;</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1143<p>In paragraph 19, Effects:, members truename() and falsename are used from facet
1144ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
114522.2.2.1.2, addressed in (4). </p>
1146<p><b>Proposed resolution:</b></p>
1147<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:
1148clause for member put(...., bool), replace the initialization of the
1149string_type value s as follows: </p>
1150
1151<blockquote>
1152  <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
1153string_type s = val ? np.truename() : np.falsename(); </pre>
1154</blockquote>
1155<hr>
1156<a name="35"><h3>35.&nbsp;No manipulator unitbuf in synopsis</h3></a><p><b>Section:</b>&nbsp;27.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1157<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
1158named "unitbuf". Unlike other manipulators, it's not listed
1159in synopsis. Similarly for "nounitbuf". </p>
1160<p><b>Proposed resolution:</b></p>
1161<p>Add to the synopsis for &lt;ios&gt; 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
1162the entry for "nouppercase", the prototypes: </p>
1163
1164<blockquote>
1165  <pre>ios_base&amp; unitbuf(ios_base&amp; str);
1166ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
1167</blockquote>
1168<hr>
1169<a name="36"><h3>36.&nbsp;Iword &amp; pword storage lifetime omitted</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1170<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
1171specified badly, so that an implementation which only keeps the last value stored appears
1172to conform. In particular, it says: </p>
1173
1174<p>The reference returned may become invalid after another call to the object's iword
1175member with a different index ... </p>
1176
1177<p>This is not idle speculation; at least one implementation was done this way. </p>
1178<p><b>Proposed resolution:</b></p>
1179<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
1180paragraph 4, replace the sentence: </p>
1181
1182<blockquote>
1183  <p>The reference returned may become invalid after another call to the object's iword
1184  [pword] member with a different index, after a call to its copyfmt member, or when the
1185  object is destroyed. </p>
1186</blockquote>
1187
1188<p>with: </p>
1189
1190<blockquote>
1191  <p>The reference returned is invalid after any other operations on the object. However,
1192  the value of the storage referred to is retained, so that until the next call to copyfmt,
1193  calling iword [pword] with the same index yields another reference to the same value. </p>
1194</blockquote>
1195
1196<p>substituting "iword" or "pword" as appropriate. </p>
1197<hr>
1198<a name="37"><h3>37.&nbsp;Leftover "global" reference</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1199<p>In the overview of locale semantics, paragraph 4, is the sentence </p>
1200
1201<blockquote>
1202  <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
1203  the standard exception bad_cast. </p>
1204</blockquote>
1205
1206<p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
1207from an old draft. </p>
1208<p><b>Proposed resolution:</b></p>
1209<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
1210expression </p>
1211
1212<blockquote>
1213  <p>(or, failing that, in the global locale) </p>
1214</blockquote>
1215<hr>
1216<a name="38"><h3>38.&nbsp;Facet definition incomplete</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1217<p>It has been noticed by Esa Pulkkinen that the definition of
1218"facet" is incomplete. In particular, a class derived from
1219another facet, but which does not define a member <i>id</i>, cannot
1220safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
1221because there is no guarantee that a reference to the facet instance
1222stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
1223<p><b>Proposed resolution:</b></p>
1224<p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
1225reads: </p>
1226
1227<blockquote>
1228  <p>Get a reference to a facet of a locale. </p>
1229</blockquote>
1230
1231<p>with: </p>
1232
1233<blockquote>
1234  <p>Requires: <tt>Facet</tt> is a facet class whose definition
1235  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>
1236</blockquote>
1237
1238<p><i>[
1239Kona: strike as overspecification the text "(not inherits)"
1240from the original resolution, which read "... whose definition
1241contains (not inherits) the public static member
1242<tt>id</tt>..."
1243]</i></p>
1244
1245<hr>
1246<a name="39"><h3>39.&nbsp;istreambuf_iterator&lt;&gt;::operator++(int) definition garbled</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1247<p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
12483, the standard contains three lines of garbage text left over from a previous edit. </p>
1249
1250<blockquote>
1251  <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
1252sbuf_-&gt;sbumpc();
1253return(tmp); </pre>
1254</blockquote>
1255<p><b>Proposed resolution:</b></p>
1256<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
1257end of paragraph 3. </p>
1258<hr>
1259<a name="40"><h3>40.&nbsp;Meaningless normative paragraph in examples</h3></a><p><b>Section:</b>&nbsp;22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1260<p>Paragraph 3 of the locale examples is a description of part of an
1261implementation technique that has lost its referent, and doesn't mean
1262anything. </p>
1263<p><b>Proposed resolution:</b></p>
1264<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
1265initialization/identification system depends...", or (at the
1266editor's option) replace it with a place-holder to keep the paragraph
1267numbering the same. </p>
1268<hr>
1269<a name="41"><h3>41.&nbsp;Ios_base needs clear(), exceptions()</h3></a><p><b>Section:</b>&nbsp;27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1270<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,
1271which may throw an exception". However, ios_base offers no
1272interface to set or to test badbit; those interfaces are defined in
1273basic_ios&lt;&gt;. </p>
1274<p><b>Proposed resolution:</b></p>
1275<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
1276paragraph 2, and also in paragraph 4, as follows. Replace</p>
1277
1278<blockquote>
1279  <p>If the function fails it sets badbit, which may throw an exception.</p>
1280</blockquote>
1281
1282<p>with</p>
1283
1284<blockquote>
1285  <p>If the function fails, and <tt>*this</tt> is a base sub-object of
1286  a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
1287  equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
1288  on the derived object (which may throw <tt>failure</tt>).</p>
1289</blockquote>
1290
1291<p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
1292setstate(badbit).]</i></p>
1293
1294<hr>
1295<a name="42"><h3>42.&nbsp;String ctors specify wrong default allocator</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1296<p>The basic_string&lt;&gt; copy constructor: </p>
1297
1298<pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1299             size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
1300
1301<p>specifies an Allocator argument default value that is
1302counter-intuitive. The natural choice for a the allocator to copy from
1303is str.get_allocator(). Though this cannot be expressed in
1304default-argument notation, overloading suffices. </p>
1305
1306<p>Alternatively, the other containers in Clause 23 (deque, list,
1307vector) do not have this form of constructor, so it is inconsistent,
1308and an evident source of confusion, for basic_string&lt;&gt; to have
1309it, so it might better be removed. </p>
1310<p><b>Proposed resolution:</b></p>
1311<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
1312constructor as follows: </p>
1313
1314<blockquote>
1315  <pre>basic_string(const basic_string&amp; str);
1316basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
1317             const Allocator&amp; a = Allocator());</pre>
1318</blockquote>
1319
1320<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
1321as above. Add to paragraph 5, Effects:</p>
1322
1323<blockquote>
1324  <p>In the first form, the Allocator value used is copied from
1325  <tt>str.get_allocator()</tt>.</p>
1326</blockquote>
1327<p><b>Rationale:</b></p>
1328<p>The LWG believes the constructor is actually broken, rather than
1329just an unfortunate design choice.</p>
1330
1331<p>The LWG considered two other possible resolutions:</p>
1332
1333<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
1334constructor as follows:</p>
1335
1336<blockquote>
1337  <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1338             size_type n = npos);
1339basic_string(const basic_string&amp; str, size_type pos,
1340             size_type n, const Allocator&amp; a); </pre>
1341</blockquote>
1342
1343<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
1344as above. Add to paragraph 5, Effects: </p>
1345
1346<blockquote>
1347  <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
1348  value <tt>str.get_allocator()</tt>. </p>
1349</blockquote>
1350
1351<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
1352the declaration of the copy constructor as follows: </p>
1353
1354<blockquote>
1355  <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1356             size_type n = npos); </pre>
1357</blockquote>
1358
1359<p>The proposed resolution reflects the original intent of the LWG. It
1360was also noted by Pete Becker that this fix "will cause
1361a small amount of existing code to now work correctly."</p>
1362
1363<p><i>[
1364Kona: issue editing snafu fixed - the proposed resolution now correctly
1365reflects the LWG consensus.
1366]</i></p>
1367<hr>
1368<a name="44"><h3>44.&nbsp;Iostreams use operator== on int_type values</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1369<p>Many of the specifications for iostreams specify that character
1370values or their int_type equivalents are compared using operators ==
1371or !=, though in other places traits::eq() or traits::eq_int_type is
1372specified to be used throughout. This is an inconsistency; we should
1373change uses of == and != to use the traits members instead. </p>
1374<p><b>Proposed resolution:</b></p>
1375
1376<p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
1377
1378<p>List of changes to clause 27:</p>
1379<ol>
1380<li>
1381   In lib.basic.ios.members paragraph 13 (postcondition clause for
1382   'fill(cT)') change
1383
1384<blockquote>
1385     fillch == fill()
1386</blockquote>
1387
1388   to
1389
1390<blockquote>
1391     traits::eq(fillch, fill())
1392</blockquote>
1393
1394
1395</li>
1396<li>
1397   In lib.istream.unformatted paragraph 7 (effects clause for
1398   'get(cT,streamsize,cT)'), third bullet, change
1399
1400<blockquote>
1401     c == delim for the next available input character c
1402</blockquote>
1403
1404   to
1405
1406<blockquote>
1407     traits::eq(c, delim) for the next available input character c
1408  </blockquote>
1409
1410</li>
1411<li>
1412   In lib.istream.unformatted paragraph 12 (effects clause for
1413   'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
1414
1415<blockquote>
1416     c == delim for the next available input character c
1417</blockquote>
1418
1419   to
1420
1421<blockquote>
1422     traits::eq(c, delim) for the next available input character c
1423</blockquote>
1424
1425</li>
1426<li>
1427   In lib.istream.unformatted paragraph 17 (effects clause for
1428   'getline(cT,streamsize,cT)'), second bullet, change
1429
1430<blockquote>
1431     c == delim for the next available input character c
1432</blockquote>
1433
1434   to
1435
1436<blockquote>
1437     traits::eq(c, delim) for the next available input character c
1438  </blockquote>
1439
1440</li>
1441<li>
1442   In lib.istream.unformatted paragraph 24 (effects clause for
1443   'ignore(int,int_type)'), second bullet, change
1444
1445<blockquote>
1446     c == delim for the next available input character c
1447</blockquote>
1448
1449   to
1450
1451<blockquote>
1452     traits::eq_int_type(c, delim) for the next available input
1453     character c
1454</blockquote>
1455
1456</li>
1457<li>
1458   In lib.istream.unformatted paragraph 25 (notes clause for
1459   'ignore(int,int_type)'), second bullet, change
1460
1461<blockquote>
1462     The last condition will never occur if delim == traits::eof()
1463</blockquote>
1464
1465   to
1466
1467<blockquote>
1468     The last condition will never occur if
1469     traits::eq_int_type(delim, traits::eof()).
1470</blockquote>
1471
1472</li>
1473<li>
1474   In lib.istream.sentry paragraph 6 (example implementation for the
1475   sentry constructor) change
1476
1477<blockquote>
1478     while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
1479</blockquote>
1480
1481   to
1482
1483<blockquote>
1484     while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
1485</blockquote>
1486
1487</li>
1488</ol>
1489
1490<p>List of changes to Chapter 21:</p>
1491
1492<ol>
1493<li>
1494   In lib.string::find paragraph 1 (effects clause for find()),
1495   second bullet, change
1496
1497<blockquote>
1498     at(xpos+I) == str.at(I) for all elements ...
1499</blockquote>
1500
1501   to
1502
1503<blockquote>
1504     traits::eq(at(xpos+I), str.at(I)) for all elements ...
1505</blockquote>
1506
1507</li>
1508<li>
1509   In lib.string::rfind paragraph 1 (effects clause for rfind()),
1510   second bullet, change
1511
1512<blockquote>
1513     at(xpos+I) == str.at(I) for all elements ...
1514</blockquote>
1515
1516   to
1517
1518<blockquote>
1519     traits::eq(at(xpos+I), str.at(I)) for all elements ...
1520</blockquote>
1521
1522</li>
1523<li>
1524   In lib.string::find.first.of paragraph 1 (effects clause for
1525   find_first_of()), second bullet, change
1526
1527<blockquote>
1528     at(xpos+I) == str.at(I) for all elements ...
1529</blockquote>
1530
1531   to
1532
1533<blockquote>
1534     traits::eq(at(xpos+I), str.at(I)) for all elements ...
1535</blockquote>
1536
1537</li>
1538<li>
1539   In lib.string::find.last.of paragraph 1 (effects clause for
1540   find_last_of()), second bullet, change
1541
1542<blockquote>
1543     at(xpos+I) == str.at(I) for all elements ...
1544</blockquote>
1545
1546   to
1547
1548<blockquote>
1549     traits::eq(at(xpos+I), str.at(I)) for all elements ...
1550</blockquote>
1551
1552</li>
1553<li>
1554   In lib.string::find.first.not.of paragraph 1 (effects clause for
1555   find_first_not_of()), second bullet, change
1556
1557<blockquote>
1558     at(xpos+I) == str.at(I) for all elements ...
1559</blockquote>
1560
1561   to
1562
1563<blockquote>
1564     traits::eq(at(xpos+I), str.at(I)) for all elements ...
1565</blockquote>
1566</li>
1567
1568<li>
1569   In lib.string::find.last.not.of paragraph 1 (effects clause for
1570   find_last_not_of()), second bullet, change
1571
1572<blockquote>
1573     at(xpos+I) == str.at(I) for all elements ...
1574</blockquote>
1575
1576   to
1577
1578<blockquote>
1579     traits::eq(at(xpos+I), str.at(I)) for all elements ...
1580</blockquote>
1581</li>
1582
1583<li>
1584   In lib.string.ios paragraph 5 (effects clause for getline()),
1585   second bullet, change
1586
1587<blockquote>
1588     c == delim for the next available input character c
1589</blockquote>
1590
1591   to
1592
1593<blockquote>
1594     traits::eq(c, delim) for the next available input character c
1595</blockquote>
1596</li>
1597
1598</ol>
1599
1600<p>Notes:</p>
1601<ul>
1602<li>
1603  Fixing this issue highlights another sloppyness in
1604  lib.istream.unformatted paragraph 24: this clause mentions a "character"
1605  which is then compared to an 'int_type' (see item 5. in the list
1606  below). It is not clear whether this requires explicit words and
1607  if so what these words are supposed to be. A similar issue exists,
1608  BTW, for operator*() of istreambuf_iterator which returns the result
1609  of sgetc() as a character type (see lib.istreambuf.iterator::op*
1610  paragraph 1), and for operator++() of istreambuf_iterator which
1611  passes the result of sbumpc() to a constructor taking a char_type
1612  (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
1613  assignment operator ostreambuf_iterator passes a char_type to a function
1614  taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
1615</li>
1616<li>
1617  It is inconsistent to use comparisons using the traits functions in
1618  Chapter 27 while not using them in Chapter 21, especially as some
1619  of the inconsistent uses actually involve streams (eg. getline() on
1620  streams). To avoid leaving this issue open still longer due to this
1621  inconsistency (it is open since 1998), a list of changes to Chapter
1622  21 is below.
1623</li>
1624<li>
1625  In Chapter 24 there are several places with statements like "the end
1626  of stream is reached (streambuf_type::sgetc() returns traits::eof())"
1627  (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
1628  paragraph 5). It is unclear whether these should be clarified to use
1629  traits::eq_int_type() for detecting traits::eof().
1630</li>
1631</ul>
1632
1633<hr>
1634<a name="46"><h3>46.&nbsp;Minor Annex D errors</h3></a><p><b>Section:</b>&nbsp;D.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.str.strstreams"> [depr.str.strstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Brendan Kehoe&nbsp; <b>Date:</b>&nbsp; 1 Jun 1998</p>
1635<p>See lib-6522 and edit-814.</p>
1636<p><b>Proposed resolution:</b></p>
1637<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
1638basic_streambuf&lt;char&gt;) from:</p>
1639
1640<pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
1641
1642<p>to:</p>
1643
1644<pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
1645
1646<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
1647int_type:</p>
1648
1649<pre>     namespace std {
1650       class strstream
1651         : public basic_iostream&lt;char&gt; {
1652       public:
1653         // Types
1654         typedef char                                char_type;
1655         typedef typename char_traits&lt;char&gt;::int_type int_type
1656         typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
1657<hr>
1658<a name="47"><h3>47.&nbsp;Imbue() and getloc() Returns clauses swapped</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1659<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
1660section has two RETURNS clauses, and they make no sense as
1661stated. They make perfect sense, though, if you swap them. Am I
1662correct in thinking that paragraphs 2 and 4 just got mixed up by
1663accident?</p>
1664<p><b>Proposed resolution:</b></p>
1665<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>
1666<hr>
1667<a name="48"><h3>48.&nbsp;Use of non-existent exception constructor</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1668<p>27.4.2.1.1, paragraph 2, says that class failure initializes the
1669base class, exception, with exception(msg). Class exception (see
167018.6.1) has no such constructor.</p>
1671<p><b>Proposed resolution:</b></p>
1672<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>
1673
1674<blockquote>
1675  <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
1676</blockquote>
1677<hr>
1678<a name="49"><h3>49.&nbsp;Underspecification of ios_base::sync_with_stdio</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1679<p>Two problems</p>
1680
1681<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
1682returns. Does it return f, or does it return the previous
1683synchronization state? My guess is the latter, but the standard
1684doesn't say so.</p>
1685
1686<p>(2) 27.4.2.4 doesn't say what it means for streams to be
1687synchronized with stdio.  Again, of course, I can make some
1688guesses. (And I'm unhappy about the performance implications of those
1689guesses, but that's another matter.)</p>
1690<p><b>Proposed resolution:</b></p>
1691<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>
1692returns clause from:</p>
1693
1694<blockquote>
1695  <p><tt>true</tt> if the standard iostream objects (27.3) are
1696  synchronized and otherwise returns <tt>false</tt>.</p>
1697</blockquote>
1698
1699<p>to:</p>
1700
1701<blockquote>
1702  <p><tt>true</tt> if the previous state of the standard iostream
1703  objects (27.3) was synchronized and otherwise returns
1704  <tt>false</tt>.</p>
1705</blockquote>
1706
1707<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>,
1708paragraph 2:</p>
1709
1710<blockquote>
1711<p>When a standard iostream object str is <i>synchronized</i> with a
1712standard stdio stream f, the effect of inserting a character c by</p>
1713<pre>  fputc(f, c);
1714</pre>
1715
1716<p>is the same as the effect of</p>
1717<pre>  str.rdbuf()-&gt;sputc(c);
1718</pre>
1719
1720<p>for any sequence of characters; the effect of extracting a
1721character c by</p>
1722<pre>  c = fgetc(f);
1723</pre>
1724
1725<p>is the same as the effect of:</p>
1726<pre>  c = str.rdbuf()-&gt;sbumpc(c);
1727</pre>
1728
1729<p>for any sequences of characters; and the effect of pushing
1730back a character c by</p>
1731<pre>  ungetc(c, f);
1732</pre>
1733
1734<p>is the same as the effect of</p>
1735<pre>  str.rdbuf()-&gt;sputbackc(c);
1736</pre>
1737
1738<p>for any sequence of characters.  [<i>Footnote</i>: This implies
1739that operations on a standard iostream object can be mixed arbitrarily
1740with operations on the corresponding stdio stream.  In practical
1741terms, synchronization usually means that a standard iostream object
1742and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
1743</blockquote>
1744
1745<p><i>[pre-Copenhagen: PJP and Matt contributed the definition
1746of "synchronization"]</i></p>
1747
1748<p><i>[post-Copenhagen: proposed resolution was revised slightly:
1749text was added in the non-normative footnote to say that operations
1750on the two streams can be mixed arbitrarily.]</i></p>
1751<hr>
1752<a name="50"><h3>50.&nbsp;Copy constructor and assignment operator of ios_base</h3></a><p><b>Section:</b>&nbsp;27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1753<p>As written, ios_base has a copy constructor and an assignment
1754operator. (Nothing in the standard says it doesn't have one, and all
1755classes have copy constructors and assignment operators unless you
1756take specific steps to avoid them.) However, nothing in 27.4.2 says
1757what the copy constructor and assignment operator do. </p>
1758
1759<p>My guess is that this was an oversight, that ios_base is, like
1760basic_ios, not supposed to have a copy constructor or an assignment
1761operator.</p>
1762
1763<p>
1764Jerry Schwarz comments: Yes, its an oversight, but in the opposite
1765sense to what you're suggesting. At one point there was a definite
1766intention that you could copy ios_base. It's an easy way to save the
1767entire state of a stream for future use. As you note, to carry out
1768that intention would have required a explicit description of the
1769semantics (e.g. what happens to the iarray and parray stuff).
1770</p>
1771<p><b>Proposed resolution:</b></p>
1772<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
1773constructor and operator= members as being private.</p>
1774<p><b>Rationale:</b></p>
1775<p>The LWG believes the difficulty of specifying correct semantics
1776outweighs any benefit of allowing ios_base objects to be copyable.</p>
1777<hr>
1778<a name="51"><h3>51.&nbsp;Requirement to not invalidate iterators missing</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;David Vandevoorde&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1779<p>The std::sort algorithm can in general only sort a given sequence
1780by moving around values. The list&lt;&gt;::sort() member on the other
1781hand could move around values or just update internal pointers. Either
1782method can leave iterators into the list&lt;&gt; dereferencable, but
1783they would point to different things. </p>
1784
1785<p>Does the FDIS mandate anywhere which method should be used for
1786list&lt;&gt;::sort()?</p>
1787
1788<p>Matt Austern comments:</p>
1789
1790<p>I think you've found an omission in the standard. </p>
1791
1792<p>The library working group discussed this point, and there was
1793supposed to be a general requirement saying that list, set, map,
1794multiset, and multimap may not invalidate iterators, or change the
1795values that iterators point to, except when an operation does it
1796explicitly. So, for example, insert() doesn't invalidate any iterators
1797and erase() and remove() only invalidate iterators pointing to the
1798elements that are being erased. </p>
1799
1800<p>I looked for that general requirement in the FDIS, and, while I
1801found a limited form of it for the sorted associative containers, I
1802didn't find it for list. It looks like it just got omitted. </p>
1803
1804<p>The intention, though, is that list&lt;&gt;::sort does not
1805invalidate any iterators and does not change the values that any
1806iterator points to. There would be no reason to have the member
1807function otherwise.</p>
1808<p><b>Proposed resolution:</b></p>
1809<p>Add a new paragraph at the end of 23.1:</p>
1810
1811<blockquote>
1812  <p>Unless otherwise specified (either explicitly or by defining a function in terms of
1813  other functions), invoking a container member function or passing a container as an
1814  argument to a library function shall not invalidate iterators to, or change the values of,
1815  objects within that container. </p>
1816</blockquote>
1817<p><b>Rationale:</b></p>
1818<p>This was US issue CD2-23-011; it was accepted in London but the
1819change was not made due to an editing oversight. The wording in the
1820proposed resolution below is somewhat updated from CD2-23-011,
1821particularly the addition of the phrase "or change the values
1822of"</p>
1823<hr>
1824<a name="52"><h3>52.&nbsp;Small I/O problems</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1825<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:
1826it should be titled "basic_ios&lt;&gt;() effects", not
1827"ios_base() effects". </p>
1828
1829<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
1830resolution.]</p>
1831
1832<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
1833different things wrong with it, some of which I've already discussed
1834with Jerry, but the most obvious mechanical sort of error is that it
1835uses expressions like P(i) and p(i), without ever defining what sort
1836of thing "i" is.
1837</p>
1838
1839<p>(The other problem is that it requires support for streampos
1840arithmetic. This is impossible on some systems, i.e. ones where file
1841position is a complicated structure rather than just a number. Jerry
1842tells me that the intention was to require syntactic support for
1843streampos arithmetic, but that it wasn't actually supposed to do
1844anything meaningful except on platforms, like Unix, where genuine
1845arithmetic is possible.) </p>
1846<p><b>Proposed resolution:</b></p>
1847<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
1848"ios_base() effects" to "basic_ios&lt;&gt;()
1849effects". </p>
1850<hr>
1851<a name="53"><h3>53.&nbsp;Basic_ios destructor unspecified</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1852<p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
1853The important question is whether basic_ios::~basic_ios() destroys
1854rdbuf().</p>
1855<p><b>Proposed resolution:</b></p>
1856<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>
1857
1858<blockquote>
1859  <p><tt>virtual ~basic_ios();</tt></p>
1860  <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
1861</blockquote>
1862<p><b>Rationale:</b></p>
1863<p>The LWG reviewed the additional question of whether or not
1864<tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
1865clearly 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
1866by the LWG, which removed from the original proposed resolution a
1867footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
1868<tt>badbit</tt>".</p>
1869<hr>
1870<a name="54"><h3>54.&nbsp;Basic_streambuf's destructor</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Jun 1998</p>
1871<p>The class synopsis for basic_streambuf shows a (virtual)
1872destructor, but the standard doesn't say what that destructor does. My
1873assumption is that it does nothing, but the standard should say so
1874explicitly. </p>
1875<p><b>Proposed resolution:</b></p>
1876<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>
1877
1878<blockquote>
1879  <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
1880  <p><b>Effects</b>: None.</p>
1881</blockquote>
1882<hr>
1883<a name="55"><h3>55.&nbsp;Invalid stream position is undefined</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;26 Jun 1998</p>
1884<p>Several member functions in clause 27 are defined in certain
1885circumstances to return an "invalid stream position", a term
1886that is defined nowhere in the standard. Two places (27.5.2.4.2,
1887paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
1888a definition in _lib.iostreams.definitions_, a nonexistent
1889section. </p>
1890
1891<p>I suspect that the invalid stream position is just supposed to be
1892pos_type(-1).  Probably best to say explicitly in (for example)
189327.5.2.4.2 that the return value is pos_type(-1), rather than to use
1894the term "invalid stream position", define that term
1895somewhere, and then put in a cross-reference. </p>
1896
1897<p>The phrase "invalid stream position" appears ten times in
1898the C++ Standard.  In seven places it refers to a return value, and it
1899should be changed. In three places it refers to an argument, and it
1900should not be changed. Here are the three places where "invalid
1901stream position" should not be changed:</p>
1902
1903<blockquote>
1904  <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>
1905  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>
1906  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
1907  </p>
1908</blockquote>
1909<p><b>Proposed resolution:</b></p>
1910<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
1911object of class pos_type that stores an invalid stream position
1912(_lib.iostreams.definitions_)" to "Returns
1913<tt>pos_type(off_type(-1))</tt>".
1914</p>
1915
1916<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
1917an object of class pos_type that stores an invalid stream
1918position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
1919
1920<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
1921stores an invalid stream position" to "the return value is
1922<tt>pos_type(off_type(-1))</tt>". </p>
1923
1924<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
1925invalid stream position (27.4.3)" to "returns
1926<tt>pos_type(off_type(-1))</tt>" </p>
1927
1928<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
1929returns an invalid stream position (_lib.iostreams.definitions_)"
1930to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
1931</p>
1932
1933<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
1934stores an invalid stream position" to "the return value is
1935<tt>pos_type(off_type(-1))</tt>" </p>
1936
1937<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
1938stores an invalid stream position" to "the return value is
1939<tt>pos_type(off_type(-1))</tt>"</p>
1940<hr>
1941<a name="56"><h3>56.&nbsp;Showmanyc's return type</h3></a><p><b>Section:</b>&nbsp;27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;29 Jun 1998</p>
1942<p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
1943showmanyc has return type int. However, 27.5.2.4.3 says that its
1944return type is streamsize. </p>
1945<p><b>Proposed resolution:</b></p>
1946<p>Change <tt>showmanyc</tt>'s return type in the
194727.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>
1948<hr>
1949<a name="57"><h3>57.&nbsp;Mistake in char_traits</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;1 Jul 1998</p>
1950<p>21.1.3.2, paragraph 3, says "The types streampos and
1951wstreampos may be different if the implementation supports no shift
1952encoding in narrow-oriented iostreams but supports one or more shift
1953encodings in wide-oriented streams". </p>
1954
1955<p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
1956in 27.2 says that streampos and wstreampos are, respectively, synonyms
1957for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
1958fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
1959to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
1960char_traits&lt;char&gt;::state_type and
1961char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
1962<p><b>Proposed resolution:</b></p>
1963<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
1964begins "The types streampos and wstreampos may be
1965different..." . </p>
1966<hr>
1967<a name="59"><h3>59.&nbsp;Ambiguity in specification of gbump</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;28 Jul 1998</p>
1968<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
1969next pointer for the input sequence by n." </p>
1970
1971<p>The straightforward interpretation is that it is just gptr() +=
1972n. An alternative interpretation, though, is that it behaves as if it
1973calls sbumpc n times. (The issue, of course, is whether it might ever
1974call underflow.) There is a similar ambiguity in the case of
1975pbump. </p>
1976
1977<p>(The "classic" AT&amp;T implementation used the
1978former interpretation.)</p>
1979<p><b>Proposed resolution:</b></p>
1980<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>
1981
1982<blockquote>
1983  <p>Effects: Advances the next pointer for the input sequence by n.</p>
1984</blockquote>
1985
1986<p>to:</p>
1987
1988<blockquote>
1989  <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
1990</blockquote>
1991
1992<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
1993effects.</p>
1994<hr>
1995<a name="60"><h3>60.&nbsp;What is a formatted input function?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;3 Aug 1998</p>
1996<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
1997formatted input functions. Some of the functions defined in section
199827.6.1.2 explicitly say that those requirements apply ("Behaves
1999like a formatted input member (as described in 27.6.1.2.1)"), but
2000others don't. The question: is 27.6.1.2.1 supposed to apply to
2001everything in 27.6.1.2, or only to those member functions that
2002explicitly say "behaves like a formatted input member"? Or
2003to put it differently: are we to assume that everything that appears
2004in a section called "Formatted input functions" really is a
2005formatted input function? I assume that 27.6.1.2.1 is intended to
2006apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
2007is not intended to apply to extractors like </p>
2008
2009<pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
2010
2011<p>and </p>
2012
2013<pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
2014
2015<p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
2016output. </p>
2017
2018<p>Comments from Judy Ward: It seems like the problem is that the
2019basic_istream and basic_ostream operator &lt;&lt;()'s that are used
2020for the manipulators and streambuf* are in the wrong section and
2021should have their own separate section or be modified to make it clear
2022that the "Common requirements" listed in section 27.6.1.2.1
2023(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
2024apply to them. </p>
2025
2026<p>Additional comments from Dietmar K�hl: It appears to be somewhat
2027nonsensical 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
2028function" but since these functions are defined in a section
2029labeled "Formatted input functions" it is unclear to me
2030whether these operators are considered formatted input functions which
2031have 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
2032just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
2033set (... but setting <tt>noskipws</tt> using the manipulator syntax
2034would also skip whitespace :-)</p> <p>It is not clear which functions
2035are to be considered unformatted input functions. As written, it seems
2036that 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
2037functions. However, it does not really make much sense to construct a
2038sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
2039unclear what happens to the <tt>gcount()</tt> if
2040eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
2041<tt>sync()</tt> is called: These functions don't extract characters,
2042some of them even "unextract" a character. Should this still
2043be reflected in <tt>gcount()</tt>? Of course, it could be read as if
2044after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
2045(the last unformatted input function, <tt>gcount()</tt>, didn't
2046extract any character) and after a call to <tt>putback()</tt>
2047<tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
2048function <tt>putback()</tt> did "extract" back into the
2049stream). Correspondingly for <tt>unget()</tt>. Is this what is
2050intended?  If so, this should be clarified. Otherwise, a corresponding
2051clarification should be used.</p>
2052<p><b>Proposed resolution:</b></p>
2053<p>
2054In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
2055Change the beginning of the second sentence from "The conversion
2056occurs" to "These extractors behave as formatted input functions (as
2057described in 27.6.1.2.1).  After a sentry object is constructed,
2058the conversion occurs"
2059</p>
2060
2061<p>
2062In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
2063Add an effects clause.  "Effects: None.  This extractor does
2064not behave as a formatted input function (as described in
206527.6.1.2.1).
2066</p>
2067
2068<p>
2069In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
2070effects clause to "Effects: Calls pf(*this).  This extractor does not
2071behave as a formatted input function (as described in 27.6.1.2.1).
2072</p>
2073
2074<p>
2075In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
2076effects clause to "Effects: Calls pf(*this).  This extractor does not
2077behave as a formatted input function (as described in 27.6.1.2.1).
2078</p>
2079
2080<p>
2081In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
2082first two sentences from "If sb is null, calls setstate(failbit),
2083which may throw ios_base::failure (27.4.4.3).  Extracts characters
2084from *this..." to "Behaves as a formatted input function (as described
2085in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
2086throw ios_base::failure (27.4.4.3).  After a sentry object is
2087constructed, extracts characters from *this...".
2088</p>
2089
2090<p>
2091In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
2092effects clause.  "Effects: none. This member function does not behave
2093as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
2094</p>
2095
2096<p>
2097In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
2098beginning of the first sentence of the effects clause from "Extracts a
2099character" to "Behaves as an unformatted input function (as described
2100in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2101character"
2102</p>
2103
2104<p>
2105In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
2106beginning of the first sentence of the effects clause from "Extracts a
2107character" to "Behaves as an unformatted input function (as described
2108in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2109character"
2110</p>
2111
2112<p>
2113In 27.6.1.3, [lib.istream.unformatted], paragraph 7.  Change the
2114beginning of the first sentence of the effects clause from "Extracts
2115characters" to "Behaves as an unformatted input function (as described
2116in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2117characters"
2118</p>
2119
2120<p>
2121[No change needed in paragraph 10, because it refers to paragraph 7.]
2122</p>
2123
2124<p>
2125In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
2126beginning of the first sentence of the effects clause from "Extracts
2127characters" to "Behaves as an unformatted input function (as described
2128in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2129characters"
2130</p>
2131
2132<p>
2133[No change needed in paragraph 15.]
2134</p>
2135
2136<p>
2137In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
2138beginning of the first sentence of the effects clause from "Extracts
2139characters" to "Behaves as an unformatted input function (as described
2140in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2141characters"
2142</p>
2143
2144<p>
2145[No change needed in paragraph 23.]
2146</p>
2147
2148<p>
2149In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
2150beginning of the first sentence of the effects clause from "Extracts
2151characters" to "Behaves as an unformatted input function (as described
2152in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2153characters"
2154</p>
2155
2156<p>
2157In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
2158Effects clause: "Effects: Behaves as an unformatted input function (as
2159described in 27.6.1.3, paragraph 1).  After constructing a sentry
2160object, reads but does not extract the current input character."
2161</p>
2162
2163<p>
2164In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
2165first sentence of the Effects clause from "If !good() calls" to
2166Behaves as an unformatted input function (as described in 27.6.1.3,
2167paragraph 1).  After constructing a sentry object, if !good() calls"
2168</p>
2169
2170<p>
2171In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
2172first sentence of the Effects clause from "If !good() calls" to
2173"Behaves as an unformatted input function (as described in 27.6.1.3,
2174paragraph 1).  After constructing a sentry object, if !good() calls"
2175</p>
2176
2177<p>
2178In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
2179first sentence of the Effects clause from "If !good() calls..." to
2180"Behaves as an unformatted input function (as described in 27.6.1.3,
2181paragraph 1).  After constructing a sentry object, if !good()
2182calls..."  Add a new sentence to the end of the Effects clause:
2183"[Note: this function extracts no characters, so the value returned
2184by the next call to gcount() is 0.]"
2185</p>
2186
2187<p>
2188In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
2189first sentence of the Effects clause from "If !good() calls" to
2190"Behaves as an unformatted input function (as described in 27.6.1.3,
2191paragraph 1).  After constructing a sentry object, if !good() calls".
2192Add a new sentence to the end of the Effects clause: "[Note: this
2193function extracts no characters, so the value returned by the next
2194call to gcount() is 0.]"
2195</p>
2196
2197<p>
2198In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
2199first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
2200as an unformatted input function (as described in 27.6.1.3, paragraph
22011), except that it does not count the number of characters extracted
2202and does not affect the value returned by subsequent calls to
2203gcount().  After constructing a sentry object, if rdbuf() is"
2204</p>
2205
2206<p>
2207In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
2208Effects clause: "Effects: Behaves as an unformatted input function (as
2209described in 27.6.1.3, paragraph 1), except that it does not count the
2210number of characters extracted and does not affect the value returned
2211by subsequent calls to gcount()."  Change the first sentence of
2212paragraph 37 from "if fail()" to "after constructing a sentry object,
2213if fail()".
2214</p>
2215
2216<p>
2217In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
2218first sentence of the Effects clause from "If fail()" to "Behaves
2219as an unformatted input function (as described in 27.6.1.3, paragraph
22201), except that it does not count the number of characters extracted
2221and does not affect the value returned by subsequent calls to
2222gcount().  After constructing a sentry object, if fail()
2223</p>
2224
2225<p>
2226In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
2227first sentence of the Effects clause from "If fail()" to "Behaves
2228as an unformatted input function (as described in 27.6.1.3, paragraph
22291), except that it does not count the number of characters extracted
2230and does not affect the value returned by subsequent calls to
2231gcount().  After constructing a sentry object, if fail()
2232</p>
2233
2234<p>
2235In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
2236the beginning of the third sentence from "The formatting conversion"
2237to "These extractors behave as formatted output functions (as
2238described in 27.6.2.5.1).  After the sentry object is constructed, the
2239conversion occurs".
2240</p>
2241
2242<p>
2243In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
2244effects clause: "Effects: None. Does not behave as a formatted output
2245function (as described in 27.6.2.5.1).".
2246</p>
2247
2248<p>
2249In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
2250effects clause to "Effects: calls pf(*this).  This extractor does not
2251behave as a formatted output function (as described in 27.6.2.5.1).".
2252</p>
2253
2254<p>
2255In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
2256effects clause to "Effects: calls pf(*this).  This extractor does not
2257behave as a formatted output function (as described in 27.6.2.5.1).".
2258</p>
2259
2260<p>
2261In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
2262sentence from "If sb" to "Behaves as a formatted output function (as
2263described in 27.6.2.5.1).  After the sentry object is constructed, if
2264sb".
2265</p>
2266
2267<p>
2268In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
2269sentence from "Inserts the character" to "Behaves as an unformatted
2270output function (as described in 27.6.2.6, paragraph 1).  After
2271constructing a sentry object, inserts the character".
2272</p>
2273
2274<p>
2275In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
2276sentence from "Obtains characters" to "Behaves as an unformatted
2277output function (as described in 27.6.2.6, paragraph 1).  After
2278constructing a sentry object, obtains characters".
2279</p>
2280
2281<p>
2282In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
2283sentence at the end of the paragraph: "Does not behave as an
2284unformatted output function (as described in 27.6.2.6, paragraph 1)."
2285</p>
2286<p><b>Rationale:</b></p>
2287<p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
2288by Judy Ward and Matt Austern.  This proposed resolution is section
2289VI of that paper.</p>
2290<hr>
2291<a name="61"><h3>61.&nbsp;Ambiguity in iostreams exception policy</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
2292<p>The introduction to the section on unformatted input (27.6.1.3)
2293says that every unformatted input function catches all exceptions that
2294were thrown during input, sets badbit, and then conditionally rethrows
2295the exception. That seems clear enough. Several of the specific
2296functions, however, such as get() and read(), are documented in some
2297circumstances as setting eofbit and/or failbit. (The standard notes,
2298correctly, that setting eofbit or failbit can sometimes result in an
2299exception being thrown.) The question: if one of these functions
2300throws an exception triggered by setting failbit, is this an exception
2301"thrown during input" and hence covered by 27.6.1.3, or does
230227.6.1.3 only refer to a limited class of exceptions? Just to make
2303this concrete, suppose you have the following snippet. </p>
2304
2305<pre>
2306  char buffer[N];
2307  istream is;
2308  ...
2309  is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
2310  is.read(buffer, N);</pre>
2311
2312<p>Now suppose we reach EOF before we've read N characters. What
2313iostate bits can we expect to be set, and what exception (if any) will
2314be thrown? </p>
2315<p><b>Proposed resolution:</b></p>
2316<p>
2317In 27.6.1.3, paragraph 1, after the sentence that begins
2318"If an exception is thrown...", add the following
2319parenthetical comment: "(Exceptions thrown from
2320<tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
2321</p>
2322<p><b>Rationale:</b></p>
2323<p>The LWG looked to two alternative wordings, and choose the proposed
2324resolution as better standardese.</p>
2325<hr>
2326<a name="62"><h3>62.&nbsp;<tt>Sync</tt>'s return value</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
2327<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
2328"calls rdbuf()-&gt;pubsync() and, if that function returns -1
2329... returns traits::eof()." </p>
2330
2331<p>That looks suspicious, because traits::eof() is of type
2332traits::int_type while the return type of sync() is int. </p>
2333<p><b>Proposed resolution:</b></p>
2334<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
2335<tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
2336</p>
2337<hr>
2338<a name="63"><h3>63.&nbsp;Exception-handling policy for unformatted output</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;11 Aug 1998</p>
2339<p>Clause 27 details an exception-handling policy for formatted input,
2340unformatted input, and formatted output. It says nothing for
2341unformatted output (27.6.2.6). 27.6.2.6 should either include the same
2342kind of exception-handling policy as in the other three places, or
2343else it should have a footnote saying that the omission is
2344deliberate. </p>
2345<p><b>Proposed resolution:</b></p>
2346<p>
2347In 27.6.2.6, paragraph 1, replace the last sentence ("In any
2348case, the unformatted output function ends by destroying the sentry
2349object, then returning the value specified for the formatted output
2350function.") with the following text:
2351</p>
2352<blockquote>
2353If an exception is thrown during output, then <tt>ios::badbit</tt> is
2354turned on [Footnote: without causing an <tt>ios::failure</tt> to be
2355thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
2356badbit) != 0</tt> then the exception is rethrown.  In any case, the
2357unformatted output function ends by destroying the sentry object,
2358then, if no exception was thrown, returning the value specified for
2359the formatted output function.
2360</blockquote>
2361<p><b>Rationale:</b></p>
2362<p>
2363This exception-handling policy is consistent with that of formatted
2364input, unformatted input, and formatted output.
2365</p>
2366<hr>
2367<a name="64"><h3>64.&nbsp;Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt>
2368</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;11 Aug 1998 </p>
2369<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
2370different ways, depending on whether the second sentence is read as an
2371elaboration of the first. </p>
2372<p><b>Proposed resolution:</b></p>
2373<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
2374"If the function inserts no characters ..." with:</p>
2375
2376<blockquote>
2377  <p>If the function inserts no characters, it calls
2378  <tt>setstate(failbit)</tt>, which may throw
2379  <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
2380  because it caught an exception thrown while extracting characters
2381  from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
2382  (27.4.4.3), then the caught exception is rethrown. </p>
2383</blockquote>
2384<hr>
2385<a name="66"><h3>66.&nbsp;Strstreambuf::setbuf</h3></a><p><b>Section:</b>&nbsp;D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Aug 1998</p>
2386<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
2387"Performs an operation that is defined separately for each class
2388derived from strstreambuf". This is obviously an incorrect
2389cut-and-paste from basic_streambuf. There are no classes derived from
2390strstreambuf. </p>
2391<p><b>Proposed resolution:</b></p>
2392<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
2393clause which currently says "Performs an operation that is
2394defined separately for each class derived from strstreambuf"
2395with:</p>
2396
2397<blockquote>
2398  <p><b>Effects</b>: implementation defined, except that
2399  <tt>setbuf(0,0)</tt> has no effect.</p>
2400</blockquote>
2401<hr>
2402<a name="68"><h3>68.&nbsp;Extractors for char* should store null at end</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;14 Jul 1998</p>
2403<p>Extractors for char* (27.6.1.2.3) do not store a null character
2404after the extracted character sequence whereas the unformatted
2405functions like get() do. Why is this?</p>
2406
2407<p>Comment from Jerry Schwarz: There is apparently an editing
2408glitch. You'll notice that the last item of the list of what stops
2409extraction doesn't make any sense. It was supposed to be the line that
2410said a null is stored.</p>
2411<p><b>Proposed resolution:</b></p>
2412<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
2413item from:</p>
2414
2415<blockquote>
2416  A null byte (<tt>charT()</tt>) in the next position, which may be
2417  the first position if no characters were extracted.
2418</blockquote>
2419
2420<p>to become a new paragraph which reads:</p>
2421
2422<blockquote>
2423  Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
2424  next position, which may be the first position if no characters were
2425  extracted.
2426</blockquote>
2427<hr>
2428<a name="69"><h3>69.&nbsp;Must elements of a vector be contiguous?</h3></a><p><b>Section:</b>&nbsp;23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;29 Jul 1998</p>
2429<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
2430
2431<p>(Please note that this is entirely separate from the question of
2432whether a vector iterator is required to be a pointer; the answer to
2433that question is clearly "no," as it would rule out
2434debugging implementations)</p>
2435<p><b>Proposed resolution:</b></p>
2436<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.container.adaptors"> [lib.container.adaptors]</a>,
2437paragraph 1. </p>
2438
2439<blockquote>
2440  <p>The elements of a vector are stored contiguously, meaning that if
2441  v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
2442  other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
2443  == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
2444</blockquote>
2445<p><b>Rationale:</b></p>
2446<p>The LWG feels that as a practical matter the answer is clearly
2447"yes".  There was considerable discussion as to the best way
2448to express the concept of "contiguous", which is not
2449directly defined in the standard.  Discussion included:</p>
2450
2451<ul>
2452  <li>An operational definition similar to the above proposed resolution is
2453    already used for valarray (<font color="red">26.3.2.3</font>).</li>
2454  <li>There is no need to explicitly consider a user-defined operator&amp;
2455    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)
2456    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
2457    requirements for operator&amp;.</li>
2458  <li>There is no issue of one-past-the-end because of language rules.</li>
2459</ul>
2460<hr>
2461<a name="70"><h3>70.&nbsp;Uncaught_exception() missing throw() specification</h3></a><p><b>Section:</b>&nbsp;18.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;Unknown</p>
2462<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
2463
2464<p>uncaught_exception() doesn't have a throw specification.</p>
2465
2466<p>It is intentional ? Does it means that one should be prepared to
2467handle exceptions thrown from uncaught_exception() ?</p>
2468
2469<p>uncaught_exception() is called in exception handling contexts where
2470exception safety is very important.</p>
2471<p><b>Proposed resolution:</b></p>
2472<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.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.7.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>
2473<hr>
2474<a name="71"><h3>71.&nbsp;Do_get_monthname synopsis missing argument</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;13 Aug 1998</p>
2475<p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
2476is 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,
2477consistent with do_get_weekday and with its specified use by member
2478get_monthname. However, in the synopsis, it is specified instead with
2479four arguments. The missing argument is the "end" iterator
2480value.</p>
2481<p><b>Proposed resolution:</b></p>
2482<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
2483the declaration of member do_monthname as follows:</p>
2484
2485<pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
2486                                     ios_base::iostate&amp; err, tm* t) const;</pre>
2487<hr>
2488<a name="74"><h3>74.&nbsp;Garbled text for <tt>codecvt::do_max_length</tt>
2489</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;8 Sep 1998</p>
2490<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
2491clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
2492parentheses and a spurious <b>n</b>.</p>
2493<p><b>Proposed resolution:</b></p>
2494<p>Replace <font color="red">22.2.1.5.2</font> paragraph 11 with the
2495following:</p>
2496
2497<blockquote>
2498  <b>Returns</b>: The maximum value that
2499  <tt>do_length(state, from, from_end, 1)</tt> can return for any
2500  valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
2501  <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
2502  mbstate_t&gt;::do_max_length()</tt> returns 1.
2503</blockquote>
2504<hr>
2505<a name="75"><h3>75.&nbsp;Contradiction in <tt>codecvt::length</tt>'s argument types</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp; Matt
2506Austern&nbsp; <b>Date:</b>&nbsp; 18 Sep 1998</p>
2507<p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
2508and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
2509parameter of the member functions <tt>length</tt> and
2510<tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
2511function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
2512paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
2513synopsis or the summary must be changed. </p>
2514
2515<p>If (as I believe) the member function descriptions are correct,
2516then we must also add text saying how <tt>do_length</tt> changes its
2517<tt>stateT</tt> argument. </p>
2518<p><b>Proposed resolution:</b></p>
2519<p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>, and also in <font color="red">22.2.1.6</font>,
2520change the <tt>stateT</tt> argument type on both member
2521<tt>length()</tt> and member <tt>do_length()</tt> from </p>
2522
2523<blockquote>
2524  <p><tt>const stateT&amp;</tt></p>
2525</blockquote>
2526
2527<p>to</p>
2528
2529<blockquote>
2530  <p><tt>stateT&amp;</tt></p>
2531</blockquote>
2532
2533<p>In <font color="red">22.2.1.5.2</font>, add to the definition for member
2534<tt>do_length</tt> a paragraph:</p>
2535
2536<blockquote>
2537  <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
2538  it called <tt>do_in(state, from, from_end, from, to, to+max,
2539  to)</tt> for <tt>to</tt> pointing to a buffer of at least
2540  <tt>max</tt> elements.</p>
2541</blockquote>
2542<hr>
2543<a name="76"><h3>76.&nbsp;Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Sep 1998</p>
2544<p>This issue concerns the requirements on classes derived from
2545<tt>codecvt</tt>, including user-defined classes. What are the
2546restrictions on the conversion from external characters
2547(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
2548Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
2549the I/O library make? </p>
2550
2551<p>The question is whether it's possible to convert from internal
2552characters to external characters one internal character at a time,
2553and whether, given a valid sequence of external characters, it's
2554possible to pick off internal characters one at a time. Or, to put it
2555differently: given a sequence of external characters and the
2556corresponding sequence of internal characters, does a position in the
2557internal sequence correspond to some position in the external
2558sequence? </p>
2559
2560<p>To make this concrete, suppose that <tt>[first, last)</tt> is a
2561sequence of <i>M</i> external characters and that <tt>[ifirst,
2562ilast)</tt> is the corresponding sequence of <i>N</i> internal
2563characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
2564applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
2565ilast)</tt>. Now the question: does there necessarily exist a
2566subsequence of external characters, <tt>[first, last_1)</tt>, such
2567that the corresponding sequence of internal characters is the single
2568character <tt>*ifirst</tt>?
2569</p>
2570
2571<p>(What a "no" answer would mean is that
2572<tt>my_encoding</tt> translates sequences only as blocks. There's a
2573sequence of <i>M</i> external characters that maps to a sequence of
2574<i>N</i> internal characters, but that external sequence has no
2575subsequence that maps to <i>N-1</i> internal characters.) </p>
2576
2577<p>Some of the wording in the standard, such as the description of
2578<tt>codecvt::do_max_length</tt> (<font color="red">22.2.1.5.2</font>,
2579paragraph 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
2580possible to pick off internal characters one at a time from a sequence
2581of external characters. However, this is never explicitly stated one
2582way or the other. </p>
2583
2584<p>This issue seems (and is) quite technical, but it is important if
2585we expect users to provide their own encoding facets. This is an area
2586where the standard library calls user-supplied code, so a well-defined
2587set of requirements for the user-supplied code is crucial. Users must
2588be aware of the assumptions that the library makes. This issue affects
2589positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
2590and several of <tt>codecvt</tt>'s member functions. </p>
2591<p><b>Proposed resolution:</b></p>
2592<p>Add the following text as a new paragraph, following <font color="red">22.2.1.5.2</font> paragraph 2:</p>
2593
2594<blockquote>
2595<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
2596(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>
2597<pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
2598</pre>
2599would return <tt>ok</tt>, where <tt>from != from_end</tt>, then
2600<pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
2601</pre>
2602must also return <tt>ok</tt>, and that if
2603<pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
2604</pre>
2605would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
2606<pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
2607</pre>
2608<p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
2609means that <tt>basic_filebuf</tt> assumes that the mapping from
2610internal to external characters is 1 to N: a <tt>codecvt</tt> that is
2611used by <tt>basic_filebuf</tt> must be able to translate characters
2612one internal character at a time.  <i>--End Footnote</i>]</p>
2613</blockquote>
2614
2615<p><i>[Redmond: Minor change in proposed resolution.  Original
2616proposed resolution talked about "success", with a parenthetical
2617comment that success meant returning <tt>ok</tt>.  New wording
2618removes all talk about "success", and just talks about the
2619return value.]</i></p>
2620
2621<p><b>Rationale:</b></p>
2622
2623  <p>The proposed resoluion says that conversions can be performed one
2624  internal character at a time.  This rules out some encodings that
2625  would otherwise be legal.  The alternative answer would mean there
2626  would be some internal positions that do not correspond to any
2627  external file position.</p>
2628  <p>
2629  An example of an encoding that this rules out is one where the
2630  <tt>internT</tt> and <tt>externT</tt> are of the same type, and
2631  where the internal sequence <tt>c1 c2</tt> corresponds to the
2632  external sequence <tt>c2 c1</tt>.
2633  </p>
2634  <p>It was generally agreed that <tt>basic_filebuf</tt> relies
2635  on this property: it was designed under the assumption that
2636  the external-to-internal mapping is N-to-1, and it is not clear
2637  that <tt>basic_filebuf</tt> is implementable without that
2638  restriction.
2639  </p>
2640  <p>
2641  The proposed resolution is expressed as a restriction on
2642  <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
2643  than a blanket restriction on all <tt>codecvt</tt> facets,
2644  because <tt>basic_filebuf</tt> is the only other part of the
2645  library that uses <tt>codecvt</tt>.  If a user wants to define
2646  a <tt>codecvt</tt> facet that implements a more general N-to-M
2647  mapping, there is no reason to prohibit it, so long as the user
2648  does not expect <tt>basic_filebuf</tt> to be able to use it.
2649  </p>
2650<hr>
2651<a name="78"><h3>78.&nbsp;Typo: event_call_back</h3></a><p><b>Section:</b>&nbsp;27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2652<p>typo: event_call_back should be event_callback &nbsp; </p>
2653<p><b>Proposed resolution:</b></p>
2654<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
2655"event_call_back" to "event_callback". </p>
2656<hr>
2657<a name="79"><h3>79.&nbsp;Inconsistent declaration of polar()</h3></a><p><b>Section:</b>&nbsp;26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2658<p>In 26.3.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>
2659<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
2660
2661<p>In 26.3.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>
2662<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2663
2664<p>Thus whether the second parameter is optional is not clear. </p>
2665<p><b>Proposed resolution:</b></p>
2666<p>In 26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p>
2667<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
2668
2669<p>to:</p>
2670<pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2671<hr>
2672<a name="80"><h3>80.&nbsp;Global Operators of complex declared twice</h3></a><p><b>Section:</b>&nbsp;26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cfenv.syn"> [lib.cfenv.syn]</a>, 26.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.fenv"> [lib.fenv]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2673<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
2674class complex. This redundancy should be removed.</p>
2675<p><b>Proposed resolution:</b></p>
2676<p>Reduce redundancy according to the general style of the standard. </p>
2677<hr>
2678<a name="83"><h3>83.&nbsp;String::npos vs. string::max_size()</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2679<p>Many string member functions throw if size is getting or exceeding
2680npos. However, I wonder why they don't throw if size is getting or
2681exceeding max_size() instead of npos.  May be npos is known at compile
2682time, while max_size() is known at runtime. However, what happens if
2683size exceeds max_size() but not npos, then? It seems the standard
2684lacks some clarifications here.</p>
2685<p><b>Proposed resolution:</b></p>
2686<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
2687described in this clause...") add a new paragraph:</p>
2688
2689<blockquote>
2690  <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
2691  <tt> max_size()</tt> then
2692  the operation throws <tt>length_error</tt>.</p>
2693</blockquote>
2694<p><b>Rationale:</b></p>
2695<p>The LWG believes length_error is the correct exception to throw.</p>
2696<hr>
2697<a name="86"><h3>86.&nbsp;String constructors don't describe exceptions</h3></a><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2698<p>The constructor from a range:</p>
2699
2700<pre>template&lt;class InputIterator&gt;
2701         basic_string(InputIterator begin, InputIterator end,
2702                      const Allocator&amp; a = Allocator());</pre>
2703
2704<p>lacks a throws clause. However, I would expect that it throws
2705according to the other constructors if the numbers of characters in
2706the range equals npos (or exceeds max_size(), see above). </p>
2707<p><b>Proposed resolution:</b></p>
2708<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
2709constructors which say "Throws: length_error if n ==
2710npos."</p>
2711<p><b>Rationale:</b></p>
2712<p>Throws clauses for length_error if n == npos are no longer needed
2713because they are subsumed by the general wording added by the
2714resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
2715<hr>
2716<a name="90"><h3>90.&nbsp;Incorrect description of operator &gt;&gt; for strings</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2717<p>The effect of operator &gt;&gt; for strings contain the following item:</p>
2718
2719<p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
2720character c.</p>
2721
2722<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
2723<p><b>Proposed resolution:</b></p>
2724<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>
2725
2726<blockquote>
2727  <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
2728</blockquote>
2729
2730<p>with:</p>
2731
2732<blockquote>
2733  <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
2734</blockquote>
2735<hr>
2736<a name="91"><h3>91.&nbsp;Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2737<p>Operator &gt;&gt; and getline() for strings read until eof()
2738in the input stream is true. However, this might never happen, if the
2739stream can't read anymore without reaching EOF. So shouldn't it be
2740changed into that it reads until !good() ? </p>
2741<p><b>Proposed resolution:</b></p>
2742<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>
2743<blockquote>
2744Effects: Begins by constructing a sentry object k as if k were
2745constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
2746bool( k) is true, it calls str.erase() and then extracts characters
2747from is and appends them to str as if by calling str.append(1, c). If
2748is.width() is greater than zero, the maximum number n of characters
2749appended is is.width(); otherwise n is str.max_size(). Characters are
2750extracted and appended until any of the following occurs:
2751</blockquote>
2752<p>with:</p>
2753<blockquote>
2754Effects: 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
2755sentry converts to true, calls str.erase() and then extracts
2756characters from is and appends them to str as if by calling
2757str.append(1,c). If is.width() is greater than zero, the maximum
2758number n of characters appended is is.width(); otherwise n is
2759str.max_size(). Characters are extracted and appended until any of the
2760following occurs:
2761</blockquote>
2762
2763<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>
2764<blockquote>
2765Effects: Begins by constructing a sentry object k as if by typename
2766basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
2767it calls str.erase() and then extracts characters from is and appends
2768them to str as if by calling str.append(1, c) until any of the
2769following occurs:
2770</blockquote>
2771<p>with:</p>
2772<blockquote>
2773Effects: 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
2774by subsequent calls to basic_istream&lt;&gt;::gcount().  After
2775constructing a sentry object, if the sentry converts to true, calls
2776str.erase() and then extracts characters from is and appends them to
2777str as if by calling str.append(1,c) until any of the following
2778occurs:
2779</blockquote>
2780
2781<p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
2782should be a formatted input function, not an unformatted input function.
2783<tt>getline</tt> should not be required to set <tt>gcount</tt>, since
2784there is no mechanism for <tt>gcount</tt> to be set except by one of
2785<tt>basic_istream</tt>'s member functions.]</i></p>
2786
2787<p><i>[Cura�ao: Nico agrees with proposed resolution.]</i></p>
2788
2789<p><b>Rationale:</b></p>
2790<p>The real issue here is whether or not these string input functions
2791get their characters from a streambuf, rather than by calling an
2792istream's member functions, a streambuf signals failure either by
2793returning eof or by throwing an exception; there are no other
2794possibilities.  The proposed resolution makes it clear that these two
2795functions do get characters from a streambuf.</p>
2796<hr>
2797<a name="92"><h3>92.&nbsp;Incomplete Algorithm Requirements</h3></a><p><b>Section:</b>&nbsp;25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2798<p>The standard does not state, how often a function object is copied,
2799called, or the order of calls inside an algorithm. This may lead to
2800surprising/buggy behavior. Consider the following example: </p>
2801
2802<pre>class Nth {    // function object that returns true for the nth element
2803  private:
2804    int nth;     // element to return true for
2805    int count;   // element counter
2806  public:
2807    Nth (int n) : nth(n), count(0) {
2808    }
2809    bool operator() (int) {
2810        return ++count == nth;
2811    }
2812};
2813....
2814// remove third element
2815    list&lt;int&gt;::iterator pos;
2816    pos = remove_if(coll.begin(),coll.end(),  // range
2817                    Nth(3)),                  // remove criterion
2818    coll.erase(pos,coll.end()); </pre>
2819
2820<p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
2821happens because the usual implementation of the algorithm copies the
2822function object internally: </p>
2823
2824<pre>template &lt;class ForwIter, class Predicate&gt;
2825ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
2826{
2827    beg = find_if(beg, end, op);
2828    if (beg == end) {
2829        return beg;
2830    }
2831    else {
2832        ForwIter next = beg;
2833        return remove_copy_if(++next, end, beg, op);
2834    }
2835} </pre>
2836
2837<p>The algorithm uses find_if() to find the first element that should
2838be removed. However, it then uses a copy of the passed function object
2839to process the resulting elements (if any). Here, Nth is used again
2840and removes also the sixth element. This behavior compromises the
2841advantage of function objects being able to have a state. Without any
2842cost it could be avoided (just implement it directly instead of
2843calling find_if()). </p>
2844<p><b>Proposed resolution:</b></p>
2845
2846<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>
2847<blockquote>
2848[Note: Unless otherwise specified, algorithms that take function
2849objects as arguments are permitted to copy those function objects
2850freely.  Programmers for whom object identity is important should
2851consider using a wrapper class that points to a noncopied
2852implementation object, or some equivalent solution.]
2853</blockquote>
2854
2855<p><i>[Dublin: Pete Becker felt that this may not be a defect,
2856but rather something that programmers need to be educated about.
2857There was discussion of adding wording to the effect that the number
2858and order of calls to function objects, including predicates, not
2859affect the behavior of the function object.]</i></p>
2860
2861<p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
2862have a clear statement of "predicate" in the
2863standard. People including me seemed to think "a function
2864returning a Boolean value and being able to be called by an STL
2865algorithm or be used as sorting criterion or ... is a
2866predicate". But a predicate has more requirements: It should
2867never change its behavior due to a call or being copied. IMHO we have
2868to state this in the standard. If you like, see section 8.1.4 of my
2869library book for a detailed discussion.]</i></p>
2870
2871<p><i>[Kona: Nico will provide wording to the effect that "unless
2872otherwise specified, the number of copies of and calls to function
2873objects by algorithms is unspecified".&nbsp; Consider placing in
287425 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> after paragraph 9.]</i></p>
2875
2876<p><i>[Santa Cruz: The standard doesn't currently guarantee that
2877  functions object won't be copied, and what isn't forbidden is
2878  allowed.  It is believed (especially since implementations that were
2879  written in concert with the standard do make copies of function
2880  objects) that this was intentional.  Thus, no normative change is
2881  needed.  What we should put in is a non-normative note suggesting to
2882  programmers that if they want to guarantee the lack of copying they
2883  should use something like the <tt>ref</tt> wrapper.]</i></p>
2884
2885<p><i>[Oxford: Matt provided wording.]</i></p>
2886
2887
2888<hr>
2889<a name="98"><h3>98.&nbsp;Input iterator requirements are badly written</h3></a><p><b>Section:</b>&nbsp;24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2890<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
2891<tt>*r++</tt> of:</p>
2892
2893<p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
2894
2895<p>There are two problems with this.  First, the return type is
2896specified to be "T", as opposed to something like "convertible to T".
2897This is too specific: we want to allow *r++ to return an lvalue.</p>
2898
2899<p>Second, writing the semantics in terms of code misleadingly
2900suggests that the effects *r++ should precisely replicate the behavior
2901of this code, including side effects.  (Does this mean that *r++
2902should invoke the copy constructor exactly as many times as the sample
2903code above would?) See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a> for a similar
2904problem.</p>
2905
2906<p><b>Proposed resolution:</b></p>
2907In 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
2908for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".
2909<p><b>Rationale:</b></p>
2910<p>This issue has two parts: the return type, and the number of times
2911  the copy constructor is invoked.</p>
2912
2913<p>The LWG believes the the first part is a real issue.  It's
2914  inappropriate for the return type to be specified so much more
2915  precisely for *r++ than it is for *r.  In particular, if r is of
2916  (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
2917  but <tt>int&amp;</tt>.</p>
2918
2919<p>The LWG does not believe that the number of times the copy
2920  constructor is invoked is a real issue.  This can vary in any case,
2921  because of language rules on copy constructor elision.  That's too
2922  much to read into these semantics clauses.</p>
2923
2924<p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
2925   we're told (24.1/3) that forward iterators satisfy all the requirements
2926   of input iterators, we can't impose any requirements in the Input
2927   Iterator requirements table that forward iterators don't satisfy.</p>
2928<hr>
2929<a name="103"><h3>103.&nbsp;set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2930<p>Set::iterator is described as implementation-defined with a
2931reference to the container requirement; the container requirement says
2932that const_iterator is an iterator pointing to const T and iterator an
2933iterator pointing to T.</p>
2934
2935<p>23.1.2 paragraph 2 implies that the keys should not be modified to
2936break the ordering of elements. But that is not clearly
2937specified. Especially considering that the current standard requires
2938that iterator for associative containers be different from
2939const_iterator. Set, for example, has the following: </p>
2940
2941<p><tt>typedef implementation defined iterator;<br>
2942&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
2943
2944<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
2945to T (table 65). Disallowing user modification of keys by changing the
2946standard to require an iterator for associative container to be the
2947same as const_iterator would be overkill since that will unnecessarily
2948significantly restrict the usage of associative container. A class to
2949be used as elements of set, for example, can no longer be modified
2950easily without either redesigning the class (using mutable on fields
2951that have nothing to do with ordering), or using const_cast, which
2952defeats requiring iterator to be const_iterator. The proposed solution
2953goes in line with trusting user knows what he is doing. </p>
2954
2955<p><b>Other Options Evaluated:</b> </p>
2956
2957<p>Option A.&nbsp;&nbsp; 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
2958first sentence, and before "In addition,...", add one line:
2959</p>
2960
2961<blockquote>
2962  <p>Modification of keys shall not change their strict weak ordering. </p>
2963</blockquote>
2964
2965<p>Option B.&nbsp;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>
2966
2967<blockquote>
2968  <p>At the end of paragraph 5: "Keys in an associative container
2969  are immutable." At the end of paragraph 6: "For
2970  associative containers where the value type is the same as the key
2971  type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
2972  constant iterators. It is unspecified whether or not
2973  <tt>iterator</tt> and <tt>const_iterator</tt> are the same
2974  type."</p>
2975</blockquote>
2976
2977<p>Option C.&nbsp;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
2978currently reads:</p>
2979
2980<blockquote>
2981  <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
2982  comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
2983  container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
2984  == false &amp;&amp; comp(k2, k1) == false.</p>
2985</blockquote>
2986
2987<p>&nbsp; add the following:</p>
2988
2989<blockquote>
2990  <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
2991  value whenever it is evaluated. [Note: If k2 is removed from the container and later
2992  reinserted, comp(k1, k2) must still return a consistent value but this value may be
2993  different than it was the first time k1 and k2 were in the same container. This is
2994  intended to allow usage like a string key that contains a filename, where comp compares
2995  file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
2996  reinserted, comp(k1, k2) must again return a consistent value but this value may be
2997  different than it was the previous time k2 was in the container.]</p>
2998</blockquote>
2999<p><b>Proposed resolution:</b></p>
3000<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
3001the indicated location:</p>
3002
3003<blockquote>
3004  <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
3005  calling comp(k1, k2) shall always return the same
3006  value."</p>
3007  <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
3008  <p>At the end of paragraph 6: "For associative containers where the value type is the
3009  same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
3010  iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
3011  are the same type."</p>
3012</blockquote>
3013<p><b>Rationale:</b></p>
3014<p>Several arguments were advanced for and against allowing set elements to be
3015mutable as long as the ordering was not effected. The argument which swayed the
3016LWG was one of safety; if elements were mutable, there would be no compile-time
3017way to detect of a simple user oversight which caused ordering to be
3018modified.  There was a report that this had actually happened in practice,
3019and had been painful to diagnose.  If users need to modify elements,
3020it is possible to use mutable members or const_cast.</p>
3021
3022<p>Simply requiring that keys be immutable is not sufficient, because the comparison
3023object may indirectly (via pointers) operate on values outside of the keys.</p>
3024
3025<p>
3026The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
3027to be different types to allow for potential future work in which some
3028member functions might be overloaded between the two types.  No such
3029member functions exist now, and the LWG believes that user functionality
3030will not be impaired by permitting the two types to be the same.  A
3031function that operates on both iterator types can be defined for
3032<tt>const_iterator</tt> alone, and can rely on the automatic
3033conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
3034</p>
3035
3036<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
3037<hr>
3038<a name="106"><h3>106.&nbsp;Numeric library private members are implementation defined</h3></a><p><b>Section:</b>&nbsp;26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.member.ops"> [lib.complex.member.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
3039<p>This is the only place in the whole standard where the implementation has to document
3040something private.</p>
3041<p><b>Proposed resolution:</b></p>
3042<p>
3043Remove the comment which says "// remainder implementation defined" from:
3044</p>
3045
3046<ul>
3047  <li>26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.member.ops"> [lib.complex.member.ops]</a>
3048</li>
3049  <li>26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a>
3050</li>
3051  <li>26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.transcendentals"> [lib.complex.transcendentals]</a>
3052</li>
3053  <li>26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cmplx.over"> [lib.cmplx.over]</a>
3054</li>
3055</ul>
3056<hr>
3057<a name="108"><h3>108.&nbsp;Lifetime of exception::what() return unspecified</h3></a><p><b>Section:</b>&nbsp;18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
3058<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
3059exception::what() is left unspecified. This issue has implications
3060with exception safety of exception handling: some exceptions should
3061not throw bad_alloc.</p>
3062<p><b>Proposed resolution:</b></p>
3063<p>Add to 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a> paragraph 9 (exception::what notes
3064clause) the sentence:</p>
3065
3066<blockquote>
3067  <p>The return value remains valid until the exception object from which it is obtained is
3068  destroyed or a non-const member function of the exception object is called.</p>
3069</blockquote>
3070<p><b>Rationale:</b></p>
3071<p>If an exception object has non-const members, they may be used
3072to set internal state that should affect the contents of the string
3073returned by <tt>what()</tt>.
3074</p>
3075<hr>
3076<a name="109"><h3>109.&nbsp;Missing binders for non-const sequence elements</h3></a><p><b>Section:</b>&nbsp;20.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.arithmetic.operations"> [lib.arithmetic.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Bjarne Stroustrup&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
3077
3078<p>There are no versions of binders that apply to non-const elements
3079of a sequence. This makes examples like for_each() using bind2nd() on
3080page 521 of "The C++ Programming Language (3rd)"
3081non-conforming. Suitable versions of the binders need to be added.</p>
3082
3083<p>Further discussion from Nico:</p>
3084
3085<p>What is probably meant here is shown in the following example:</p>
3086
3087<pre>class Elem {
3088  public:
3089    void print (int i) const { }
3090    void modify (int i) { }
3091}; </pre>
3092<pre>int main()
3093{
3094    vector&lt;Elem&gt; coll(2);
3095    for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK
3096    for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR
3097}</pre>
3098
3099<p>The error results from the fact that bind2nd() passes its first
3100argument (the argument of the sequence) as constant reference. See the
3101following typical implementation:</p>
3102
3103<blockquote>
3104  <pre>template &lt;class Operation&gt;
3105class binder2nd
3106  : public unary_function&lt;typename Operation::first_argument_type,
3107                          typename Operation::result_type&gt; {
3108protected:
3109  Operation op;
3110  typename Operation::second_argument_type value;
3111public:
3112  binder2nd(const Operation&amp; o,
3113            const typename Operation::second_argument_type&amp; v)
3114      : op(o), value(v) {} </pre>
3115  <pre> typename Operation::result_type
3116  operator()(const typename Operation::first_argument_type&amp; x) const {
3117    return op(x, value);
3118  }
3119};</pre>
3120</blockquote>
3121
3122<p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
3123
3124<blockquote>
3125  <pre>template &lt;class Operation&gt;
3126class binder2nd
3127  : public unary_function&lt;typename Operation::first_argument_type,
3128                          typename Operation::result_type&gt; {
3129protected:
3130  Operation op;
3131  typename Operation::second_argument_type value;
3132public:
3133  binder2nd(const Operation&amp; o,
3134            const typename Operation::second_argument_type&amp; v)
3135      : op(o), value(v) {} </pre>
3136  <pre> typename Operation::result_type
3137  operator()(const typename Operation::first_argument_type&amp; x) const {
3138    return op(x, value);
3139  }
3140  typename Operation::result_type
3141  operator()(typename Operation::first_argument_type&amp; x) const {
3142    return op(x, value);
3143  }
3144};</pre>
3145</blockquote>
3146<p><b>Proposed resolution:</b></p>
3147
3148<p><b>Howard believes there is a flaw</b> in this resolution.
3149See c++std-lib-9127.  We may need to reopen this issue.</p>
3150
3151<p>In <font color="red">20.5.6.1</font> in the declaration of binder1st after:</p>
3152<blockquote>
3153  <p><tt>typename Operation::result_type<br>
3154  &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
3155</blockquote>
3156<p>insert:</p>
3157<blockquote>
3158  <p><tt>typename Operation::result_type<br>
3159  &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
3160</blockquote>
3161<p>In <font color="red">20.5.6.3</font> in the declaration of binder2nd after:</p>
3162<blockquote>
3163  <p><tt>typename Operation::result_type<br>
3164  &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
3165</blockquote>
3166<p>insert:</p>
3167<blockquote>
3168  <p><tt>typename Operation::result_type<br>
3169  &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
3170</blockquote>
3171
3172<p><i>[Kona: The LWG discussed this at some length.It was agreed that
3173this is a mistake in the design, but there was no consensus on whether
3174it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
3175proposed resolution - 3.  Leave open - 6.]</i></p>
3176
3177<p><i>[Copenhagen: It was generally agreed that this was a defect.
3178Strap poll: NAD - 0.  Accept proposed resolution - 10.
3179Leave open - 1.]</i></p>
3180
3181<hr>
3182<a name="110"><h3>110.&nbsp;istreambuf_iterator::equal not const</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;15 Oct 1998</p>
3183<p>Member istreambuf_iterator&lt;&gt;::equal is not declared
3184"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==,
3185which is const, calls it. This is contradictory. </p>
3186<p><b>Proposed resolution:</b></p>
3187<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>,
3188replace:</p>
3189
3190<blockquote>
3191  <pre>bool equal(istreambuf_iterator&amp; b);</pre>
3192</blockquote>
3193
3194<p>with:</p>
3195
3196<blockquote>
3197  <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
3198</blockquote>
3199<hr>
3200<a name="112"><h3>112.&nbsp;Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Oct 1998</p>
3201<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
3202constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
3203reads "<i>s</i> is not null". However, <i>s</i> is a
3204reference, and references can't be null. </p>
3205<p><b>Proposed resolution:</b></p>
3206<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>
3207
3208<p>Move the current paragraph 1, which reads "Requires: s is not
3209null.", from the first constructor to the second constructor.</p>
3210
3211<p>Insert a new paragraph 1 Requires clause for the first constructor
3212reading:</p>
3213
3214<blockquote>
3215  <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
3216</blockquote>
3217<hr>
3218<a name="114"><h3>114.&nbsp;Placement forms example in error twice</h3></a><p><b>Section:</b>&nbsp;18.5.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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;28 Oct 1998</p>
3219<p>Section 18.5.1.3 contains the following example: </p>
3220
3221<pre>[Example: This can be useful for constructing an object at a known address:
3222        char place[sizeof(Something)];
3223        Something* p = new (place) Something();
3224 -end example]</pre>
3225
3226<p>First code line: "place" need not have any special alignment, and the
3227following constructor could fail due to misaligned data.</p>
3228
3229<p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
3230believes the () are correct.]</p>
3231
3232<p>Examples are not normative, but nevertheless should not show code that is invalid or
3233likely to fail.</p>
3234<p><b>Proposed resolution:</b></p>
3235<p>Replace the <u> first line of code</u> in the example in
323618.5.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:
3237</p>
3238
3239<blockquote>
3240  <pre>void* place = operator new(sizeof(Something));</pre>
3241</blockquote>
3242<hr>
3243<a name="115"><h3>115.&nbsp;Typo in strstream constructors</h3></a><p><b>Section:</b>&nbsp;D.7.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstream.cons"> [depr.strstream.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;2 Nov 1998</p>
3244<p>D.7.4.1 strstream constructors paragraph 2 says: </p>
3245
3246<blockquote>
3247  <p>Effects: Constructs an object of class strstream, initializing the base class with
3248  iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
3249  <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3250  elements. The constructor is strstreambuf(s, n, s). </p>
3251  <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3252  elements that contains an NTBS whose first element is designated by s. The constructor is
3253  strstreambuf(s, n, s+std::strlen(s)).</p>
3254</blockquote>
3255
3256<p>Notice the second condition is the same as the first. I think the second condition
3257should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
3258the append bit is set.</p>
3259<p><b>Proposed resolution:</b></p>
3260<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>
3261paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
3262and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
3263<hr>
3264<a name="117"><h3>117.&nbsp;<tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Nov 1998</p>
3265<p>The <b>effects</b> clause for numeric inserters says that
3266insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
3267<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3268int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
3269<tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
3270delegated to <tt>num_put</tt>, and that insertion is performed as if
3271through the following code fragment: </p>
3272
3273<pre>bool failed = use_facet&lt;
3274   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3275   &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
3276
3277<p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
3278overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
3279long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
3280void*</tt>. That is, the code fragment in the standard is incorrect
3281(it is diagnosed as ambiguous at compile time) for the types
3282<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3283int</tt>, and <tt>float</tt>. </p>
3284
3285<p>We must either add new member functions to <tt>num_put</tt>, or
3286else change the description in <tt>ostream</tt> so that it only calls
3287functions that are actually there. I prefer the latter. </p>
3288<p><b>Proposed resolution:</b></p>
3289<p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
3290
3291<blockquote>
3292<p>
3293The classes num_get&lt;&gt; and num_put&lt;&gt; handle locale�dependent numeric
3294formatting and parsing.  These inserter functions use the imbued
3295locale value to perform numeric formatting.  When val is of type bool,
3296long, unsigned long, double, long double, or const void*, the
3297formatting conversion occurs as if it performed the following code
3298fragment:
3299</p>
3300
3301<pre>bool failed = use_facet&lt;
3302   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3303   &gt;(getloc()).put(*this, *this, fill(), val). failed();
3304</pre>
3305
3306<p>
3307When val is of type short the formatting conversion occurs as if it
3308performed the following code fragment:
3309</p>
3310
3311<pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3312bool failed = use_facet&lt;
3313   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3314   &gt;(getloc()).put(*this, *this, fill(),
3315      baseflags == ios_base::oct || baseflags == ios_base::hex
3316         ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
3317         : static_cast&lt;long&gt;(val)). failed();
3318</pre>
3319
3320<p>
3321When val is of type int the formatting conversion occurs as if it performed
3322the following code fragment:
3323</p>
3324
3325<pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3326bool failed = use_facet&lt;
3327   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3328   &gt;(getloc()).put(*this, *this, fill(),
3329      baseflags == ios_base::oct || baseflags == ios_base::hex
3330         ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
3331         : static_cast&lt;long&gt;(val)). failed();
3332</pre>
3333
3334<p>
3335When val is of type unsigned short or unsigned int the formatting conversion
3336occurs as if it performed the following code fragment:
3337</p>
3338
3339<pre>bool failed = use_facet&lt;
3340   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3341   &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
3342failed();
3343</pre>
3344
3345<p>
3346When val is of type float the formatting conversion occurs as if it
3347performed the following code fragment:
3348</p>
3349
3350<pre>bool failed = use_facet&lt;
3351   num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3352   &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
3353failed();
3354</pre>
3355
3356</blockquote>
3357
3358<p><i>[post-Toronto: This differs from the previous proposed
3359resolution; PJP provided the new wording.  The differences are in
3360signed short and int output.]</i></p>
3361<p><b>Rationale:</b></p>
3362<p>The original proposed resolution was to cast int and short to long,
3363unsigned int and unsigned short to unsigned long, and float to double,
3364thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
3365member functions.  The current proposed resolution is more
3366complicated, but gives more expected results for hex and octal output
3367of signed short and signed int.  (On a system with 16-bit short, for
3368example, printing short(-1) in hex format should yield 0xffff.)</p>
3369<hr>
3370<a name="118"><h3>118.&nbsp;<tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Nov 1998</p>
3371<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
3372<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
3373<tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
3374formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
3375
3376<pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3377iostate err = 0;
3378use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val);
3379setstate(err);</pre>
3380
3381<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,
3382<tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
3383<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
3384int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
3385<tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
3386<tt>void*</tt>. Comparing the lists from the two sections, we find
3387that 27.6.1.2.2 is using a nonexistent function for types
3388<tt>short</tt> and <tt>int</tt>. </p>
3389<p><b>Proposed resolution:</b></p>
3390<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
3391two lines (1st and 3rd) which read:</p>
3392<blockquote>
3393  <pre>operator&gt;&gt;(short&amp; val);
3394...
3395operator&gt;&gt;(int&amp; val);</pre>
3396</blockquote>
3397
3398<p>And add the following at the end of that section (27.6.1.2.2) :</p>
3399
3400<blockquote>
3401  <pre>operator&gt;&gt;(short&amp; val);</pre>
3402  <p>The conversion occurs as if performed by the following code fragment (using
3403  the same notation as for the preceding code fragment):</p>
3404  <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3405  iostate err = 0;
3406  long lval;
3407  use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3408        if (err == 0
3409                &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
3410                err = ios_base::failbit;
3411  setstate(err);</pre>
3412  <pre>operator&gt;&gt;(int&amp; val);</pre>
3413  <p>The conversion occurs as if performed by the following code fragment (using
3414  the same notation as for the preceding code fragment):</p>
3415  <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3416  iostate err = 0;
3417  long lval;
3418  use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3419        if (err == 0
3420                &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
3421                err = ios_base::failbit;
3422  setstate(err);</pre>
3423</blockquote>
3424
3425<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
3426<hr>
3427<a name="119"><h3>119.&nbsp;Should virtual functions be allowed to strengthen the exception specification?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3428<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>
3429
3430<p>"An implementation may strengthen the exception-specification
3431for a function by removing listed exceptions." </p>
3432
3433<p>The problem is that if an implementation is allowed to do this for
3434virtual functions, then a library user cannot write a class that
3435portably derives from that class. </p>
3436
3437<p>For example, this would not compile if ios_base::failure::~failure
3438had an empty exception specification: </p>
3439
3440<pre>#include &lt;ios&gt;
3441#include &lt;string&gt;
3442
3443class D : public std::ios_base::failure {
3444public:
3445        D(const std::string&amp;);
3446        ~D(); // error - exception specification must be compatible with
3447              // overridden virtual function ios_base::failure::~failure()
3448};</pre>
3449<p><b>Proposed resolution:</b></p>
3450<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>
3451
3452<p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3453exception-specification for a function"</p>
3454
3455<p>to:</p>
3456
3457<p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3458exception-specification for a non-virtual function". </p>
3459<hr>
3460<a name="120"><h3>120.&nbsp;Can an implementor add specializations?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3461
3462<p>The original issue asked whether a library implementor could
3463specialize standard library templates for built-in types.  (This was
3464an issue because users are permitted to explicitly instantiate
3465standard library templates.)</p>
3466
3467<p>Specializations are no longer a problem, because of the resolution
3468to core issue 259.  Under the proposed resolution, it will be legal
3469for a translation unit to contain both a specialization and an
3470explicit instantiation of the same template, provided that the
3471specialization comes first.  In such a case, the explicit
3472instantiation will be ignored.  Further discussion of library issue
3473120 assumes that the core 259 resolution will be adopted.</p>
3474
3475<p>However, as noted in lib-7047, one piece of this issue still
3476remains: what happens if a standard library implementor explicitly
3477instantiates a standard library templates?  It's illegal for a program
3478to contain two different explicit instantiations of the same template
3479for the same type in two different translation units (ODR violation),
3480and the core working group doesn't believe it is practical to relax
3481that restriction.</p>
3482
3483<p>The issue, then, is: are users allowed to explicitly instantiate
3484standard library templates for non-user defined types?  The status quo
3485answer is 'yes'.  Changing it to 'no' would give library implementors
3486more freedom.</p>
3487
3488<p>This is an issue because, for performance reasons, library
3489implementors often need to explicitly instantiate standard library
3490templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
3491users freedom to explicitly instantiate standard library templates for
3492non-user defined types make it impossible or painfully difficult for
3493library implementors to do this?</p>
3494
3495<p>John Spicer suggests, in lib-8957, that library implementors have a
3496mechanism they can use for explicit instantiations that doesn't
3497prevent users from performing their own explicit instantiations: put
3498each explicit instantiation in its own object file.  (Different
3499solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
3500some platforms, library implementors might not need to do anything
3501special: the "undefined behavior" that results from having two
3502different explicit instantiations might be harmless.</p>
3503
3504<p><b>Proposed resolution:</b></p>
3505  <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>
3506  <blockquote>
3507    A program may explicitly instantiate any templates in the standard
3508    library only if the declaration depends on the name of a user-defined
3509    type of external linkage and the instantiation meets the standard library
3510    requirements for the original template.
3511  </blockquote>
3512
3513<p><i>[Kona: changed the wording from "a user-defined name" to "the name of
3514  a user-defined type"]</i></p>
3515
3516<p><b>Rationale:</b></p>
3517<p>The LWG considered another possible resolution:</p>
3518<blockquote>
3519  <p>In light of the resolution to core issue 259, no normative changes
3520  in the library clauses are necessary.  Add the following non-normative
3521  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>
3522  <blockquote>
3523    [<i>Note:</i> A program may explicitly instantiate standard library
3524    templates, even when an explicit instantiation does not depend on
3525    a user-defined name. <i>--end note</i>]
3526  </blockquote>
3527</blockquote>
3528
3529<p>The LWG rejected this because it was believed that it would make
3530  it unnecessarily difficult for library implementors to write
3531  high-quality implementations.  A program may not include an
3532  explicit instantiation of the same template, for the same template
3533  arguments, in two different translation units.  If users are
3534  allowed to provide explicit instantiations of Standard Library
3535  templates for built-in types, then library implementors aren't,
3536  at least not without nonportable tricks.</p>
3537
3538<p>The most serious problem is a class template that has writeable
3539  static member variables.  Unfortunately, such class templates are
3540  important and, in existing Standard Library implementations, are
3541  often explicitly specialized by library implementors: locale facets,
3542  which have a writeable static member variable <tt>id</tt>.  If a
3543  user's explicit instantiation collided with the implementations
3544  explicit instantiation, iostream initialization could cause locales
3545  to be constructed in an inconsistent state.</p>
3546
3547<p>One proposed implementation technique was for Standard Library
3548  implementors to provide explicit instantiations in separate object
3549  files, so that they would not be picked up by the linker when the
3550  user also provides an explicit instantiation.  However, this
3551  technique only applies for Standard Library implementations that
3552  are packaged as static archives.  Most Standard Library
3553  implementations nowadays are packaged as dynamic libraries, so this
3554  technique would not apply.</p>
3555
3556<p>The Committee is now considering standardization of dynamic
3557  linking.  If there are such changes in the future, it may be
3558  appropriate to revisit this issue later.</p>
3559<hr>
3560<a name="122"><h3>122.&nbsp;streambuf/wstreambuf description should not say they are specializations</h3></a><p><b>Section:</b>&nbsp;27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3561<p>Section 27.5.2 describes the streambuf classes this way: </p>
3562
3563<blockquote>
3564
3565<p>The class streambuf is a specialization of the template class basic_streambuf
3566specialized for the type char. </p>
3567
3568<p>The class wstreambuf is a specialization of the template class basic_streambuf
3569specialized for the type wchar_t. </p>
3570
3571</blockquote>
3572
3573<p>This implies that these classes must be template specializations, not typedefs. </p>
3574
3575<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
3576<p><b>Proposed resolution:</b></p>
3577<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
3578sentences). </p>
3579<p><b>Rationale:</b></p>
3580<p>The <tt>streambuf</tt>  synopsis already has a declaration for the
3581typedefs and that is sufficient. </p>
3582<hr>
3583<a name="123"><h3>123.&nbsp;Should valarray helper arrays fill functions be const?</h3></a><p><b>Section:</b>&nbsp;26.5.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.5.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.5.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.5.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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998 </p>
3584<p>One of the operator= in the valarray helper arrays is const and one
3585is not. For example, look at slice_array. This operator= in Section
358626.5.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>
3587
3588<p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
3589
3590<p>but this one in Section 26.5.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>
3591
3592<p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
3593
3594<p>The description of the semantics for these two functions is similar. </p>
3595<p><b>Proposed resolution:</b></p>
3596
3597<p>26.5.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>
3598<blockquote>
3599
3600   <p>In the class template definition for slice_array, replace the member
3601   function declaration</p>
3602    <pre>      void operator=(const T&amp;);
3603    </pre>
3604   <p>with</p>
3605    <pre>      void operator=(const T&amp;) const;
3606    </pre>
3607</blockquote>
3608
3609<p>26.5.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>
3610<blockquote>
3611
3612   <p>Change the function declaration</p>
3613    <pre>      void operator=(const T&amp;);
3614    </pre>
3615   <p>to</p>
3616    <pre>      void operator=(const T&amp;) const;
3617    </pre>
3618</blockquote>
3619
3620<p>26.5.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>
3621<blockquote>
3622
3623   <p>In the class template definition for gslice_array, replace the member
3624   function declaration</p>
3625    <pre>      void operator=(const T&amp;);
3626    </pre>
3627   <p>with</p>
3628    <pre>      void operator=(const T&amp;) const;
3629    </pre>
3630</blockquote>
3631
3632<p>26.5.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>
3633<blockquote>
3634
3635   <p>Change the function declaration</p>
3636    <pre>      void operator=(const T&amp;);
3637    </pre>
3638   <p>to</p>
3639    <pre>      void operator=(const T&amp;) const;
3640    </pre>
3641</blockquote>
3642
3643<p>26.5.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>
3644<blockquote>
3645
3646   <p>In the class template definition for mask_array, replace the member
3647   function declaration</p>
3648    <pre>      void operator=(const T&amp;);
3649    </pre>
3650   <p>with</p>
3651    <pre>      void operator=(const T&amp;) const;
3652    </pre>
3653</blockquote>
3654
3655<p>26.5.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>
3656<blockquote>
3657
3658   <p>Change the function declaration</p>
3659    <pre>      void operator=(const T&amp;);
3660    </pre>
3661   <p>to</p>
3662    <pre>      void operator=(const T&amp;) const;
3663    </pre>
3664</blockquote>
3665
3666<p>26.5.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>
3667<blockquote>
3668
3669   <p>In the class template definition for indirect_array, replace the member
3670   function declaration</p>
3671    <pre>      void operator=(const T&amp;);
3672    </pre>
3673   <p>with</p>
3674    <pre>      void operator=(const T&amp;) const;
3675    </pre>
3676</blockquote>
3677
3678<p>26.5.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>
3679<blockquote>
3680
3681   <p>Change the function declaration</p>
3682    <pre>      void operator=(const T&amp;);
3683    </pre>
3684   <p>to</p>
3685    <pre>      void operator=(const T&amp;) const;
3686    </pre>
3687</blockquote>
3688
3689
3690<p><i>[Redmond: Robert provided wording.]</i></p>
3691
3692<p><b>Rationale:</b></p>
3693<p>There's no good reason for one version of operator= being const and
3694another one not.  Because of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, this now
3695matters: these functions are now callable in more circumstances.  In
3696many existing implementations, both versions are already const.</p>
3697<hr>
3698<a name="124"><h3>124.&nbsp;ctype_byname&lt;charT&gt;::do_scan_is &amp; do_scan_not return type should be const charT*</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3699<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>
3700ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
3701to return a const char* not a const charT*. </p>
3702<p><b>Proposed resolution:</b></p>
3703<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
3704<tt>do_scan_not()</tt> to return a <tt> const
3705charT*</tt>. </p>
3706<hr>
3707<a name="125"><h3>125.&nbsp;valarray&lt;T&gt;::operator!() return type is inconsistent</h3></a><p><b>Section:</b>&nbsp;26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3708<p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> valarray&lt;T&gt;::operator!() is
3709declared to return a valarray&lt;T&gt;, but in Section <font color="red">26.3.2.5</font> it is declared to return a valarray&lt;bool&gt;. The
3710latter appears to be correct. </p>
3711<p><b>Proposed resolution:</b></p>
3712<p>Change in Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> the declaration of
3713<tt>operator!()</tt> so that the return type is
3714<tt>valarray&lt;bool&gt;</tt>. </p>
3715<hr>
3716<a name="126"><h3>126.&nbsp;typos in Effects clause of ctype::do_narrow()</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3717<p>Typos in 22.2.1.1.2 need to be fixed.</p>
3718<p><b>Proposed resolution:</b></p>
3719<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>
3720
3721<pre>   do_widen(do_narrow(c),0) == c</pre>
3722
3723<p>to:</p>
3724
3725<pre>   do_widen(do_narrow(c,0)) == c</pre>
3726
3727<p>and change:</p>
3728
3729<pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
3730
3731<p>to:</p>
3732
3733<pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
3734<hr>
3735<a name="127"><h3>127.&nbsp;auto_ptr&lt;&gt; conversion issues</h3></a><p><b>Section:</b>&nbsp;20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Colvin&nbsp; <b>Date:</b>&nbsp;17 Feb 1999</p>
3736<p>There are two problems with the current <tt>auto_ptr</tt> wording
3737in the standard: </p>
3738
3739<p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
3740because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
3741<tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
3742Nathan Myers, with the same proposed resolution.</i></p>
3743
3744<p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
3745<tt>auto_ptr_ref</tt> argument. </p>
3746
3747<p>I have discussed these problems with my proposal coauthor, Bill
3748Gibbons, and with some compiler and library implementors, and we
3749believe that these problems are not desired or desirable implications
3750of the standard. </p>
3751
3752<p>25 Aug 1999: The proposed resolution now reflects changes suggested
3753by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
3754"assignment operator" to "public assignment
3755operator", 2) changed effects to specify use of release(), 3)
3756made the conversion to auto_ptr_ref const. </p>
3757
3758<p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
3759states that the conversion from auto_ptr to auto_ptr_ref should
3760be const.  This is not acceptable, because it would allow
3761initialization and assignment from _any_ const auto_ptr!  It also
3762introduces an implementation difficulty in writing this conversion
3763function -- namely, somewhere along the line, a const_cast will be
3764necessary to remove that const so that release() may be called.  This
3765may result in undefined behavior [7.1.5.1/4]. The conversion
3766operator does not have to be const, because a non-const implicit
3767object parameter may be bound to an rvalue [13.3.3.1.4/3]
3768[13.3.1/5]. </p>
3769
3770  <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
3771
3772  <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>, paragraph 2, and 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary.prop"> [lib.meta.unary.prop]</a>,
3773  paragraph 2, make the conversion to auto_ptr_ref const:</p>
3774  <blockquote>
3775    <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
3776  </blockquote>
3777<p><b>Proposed resolution:</b></p>
3778<p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>, paragraph 2, move
3779the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
3780
3781<p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>, paragraph 2, add
3782a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
3783
3784<blockquote>
3785  <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
3786</blockquote>
3787
3788<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.meta.unary.prop"> [lib.meta.unary.prop]</a>: </p>
3789
3790<blockquote>
3791  <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
3792
3793  <b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
3794  p</tt> that <tt>r</tt> holds a reference to.<br>
3795  <b>Returns: </b><tt>*this</tt>.
3796
3797</blockquote>
3798<hr>
3799<a name="129"><h3>129.&nbsp;Need error indication from seekp() and seekg()</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;22 Feb 1999</p>
3800<p>Currently, the standard does not specify how seekg() and seekp()
3801indicate failure. They are not required to set failbit, and they can't
3802return an error indication because they must return *this, i.e. the
3803stream. Hence, it is undefined what happens if they fail. And they
3804<i>can</i> fail, for instance, when a file stream is disconnected from the
3805underlying file (is_open()==false) or when a wide character file
3806stream must perform a state-dependent code conversion, etc. </p>
3807
3808<p>The stream functions seekg() and seekp() should set failbit in the
3809stream state in case of failure.</p>
3810<p><b>Proposed resolution:</b></p>
3811<p>Add to the Effects: clause of&nbsp; seekg() in
381227.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
381327.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>
3814
3815<blockquote>
3816  <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
3817  </p>
3818</blockquote>
3819<p><b>Rationale:</b></p>
3820<p>Setting failbit is the usual error reporting mechanism for streams</p>
3821<hr>
3822<a name="130"><h3>130.&nbsp;Return type of container::erase(iterator) differs for associative containers</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;2 Mar 1999</p>
3823<p>Table 67 (23.1.1) says that container::erase(iterator) returns an
3824iterator. Table 69 (23.1.2) says that in addition to this requirement,
3825associative containers also say that container::erase(iterator)
3826returns void.  That's not an addition; it's a change to the
3827requirements, which has the effect of making associative containers
3828fail to meet the requirements for containers.</p>
3829<p><b>Proposed resolution:</b></p>
3830
3831<p>
3832In 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
3833requirements, change the return type of <tt>a.erase(q)</tt> from
3834<tt>void</tt> to <tt>iterator</tt>.  Change the
3835assertion/not/pre/post-condition from "erases the element pointed to
3836by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
3837Returns an iterator pointing to the element immediately following q
3838prior to the element being erased. If no such element exists, a.end()
3839is returned."
3840</p>
3841
3842<p>
3843In 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
3844requirements, change the return type of <tt>a.erase(q1, q2)</tt>
3845from <tt>void</tt> to <tt>iterator</tt>.  Change the
3846assertion/not/pre/post-condition from "erases the elements in the
3847range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
3848q2)</tt>.  Returns q2."
3849</p>
3850
3851<p>
3852In 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
3853in 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
3854in 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
3855in 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:
3856change the signature of the first <tt>erase</tt> overload to
3857</p>
3858<pre>   iterator erase(iterator position);
3859</pre>
3860<p>and change the signature of the third <tt>erase</tt> overload to</p>
3861<pre>  iterator erase(iterator first, iterator last);
3862</pre>
3863
3864
3865<p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
3866
3867<p><i>[Post-Kona: the LWG agrees the return type should be
3868<tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
3869Matt provided wording.]</i></p>
3870
3871<p><i>[
3872 Sydney: the proposed wording went in the right direction, but it
3873 wasn't good enough. We want to return an iterator from the range form
3874 of erase as well as the single-iterator form. Also, the wording is
3875 slightly different from the wording we have for sequences; there's no
3876 good reason for having a difference.  Matt provided new wording,
3877 which we will review at the next meeting.
3878]</i></p>
3879
3880<hr>
3881<a name="132"><h3>132.&nbsp;list::resize description uses random access iterators</h3></a><p><b>Section:</b>&nbsp;23.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.capacity"> [lib.deque.capacity]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3882<p>The description reads:</p>
3883
3884<p>-1- Effects:</p>
3885
3886<pre>         if (sz &gt; size())
3887           insert(end(), sz-size(), c);
3888         else if (sz &lt; size())
3889           erase(begin()+sz, end());
3890         else
3891           ;                           //  do nothing</pre>
3892
3893<p>Obviously list::resize should not be specified in terms of random access iterators.</p>
3894<p><b>Proposed resolution:</b></p>
3895<p>Change 23.2.2.2 paragraph 1 to:</p>
3896
3897<p>Effects:</p>
3898
3899<pre>         if (sz &gt; size())
3900           insert(end(), sz-size(), c);
3901         else if (sz &lt; size())
3902         {
3903           iterator i = begin();
3904           advance(i, sz);
3905           erase(i, end());
3906         }</pre>
3907
3908<p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
3909with David Abrahams. They had a discussion and believe there is
3910no issue of exception safety with the proposed resolution.]</i></p>
3911<hr>
3912<a name="133"><h3>133.&nbsp;map missing get_allocator()</h3></a><p><b>Section:</b>&nbsp;23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3913<p>The title says it all.</p>
3914<p><b>Proposed resolution:</b></p>
3915<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,
3916after operator= in the map declaration:</p>
3917
3918<pre>    allocator_type get_allocator() const;</pre>
3919<hr>
3920<a name="134"><h3>134.&nbsp;vector constructors over specified</h3></a><p><b>Section:</b>&nbsp;23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3921<p>The complexity description says: "It does at most 2N calls to the copy constructor
3922of T and logN reallocations if they are just input iterators ...".</p>
3923
3924<p>This appears to be overly restrictive, dictating the precise memory/performance
3925tradeoff for the implementor.</p>
3926<p><b>Proposed resolution:</b></p>
3927<p>Change 23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>, paragraph 1 to:</p>
3928
3929<p>-1- Complexity: The constructor template &lt;class
3930InputIterator&gt; vector(InputIterator first, InputIterator last)
3931makes only N calls to the copy constructor of T (where N is the
3932distance between first and last) and no reallocations if iterators
3933first and last are of forward, bidirectional, or random access
3934categories. It makes order N calls to the copy constructor of T and
3935order logN reallocations if they are just input iterators.
3936</p>
3937<p><b>Rationale:</b></p>
3938<p>"at most 2N calls" is correct only if the growth factor
3939is greater than or equal to 2.
3940</p>
3941<hr>
3942<a name="136"><h3>136.&nbsp;seekp, seekg setting wrong streams?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3943<p>I may be misunderstanding the intent, but should not seekg set only
3944the input stream and seekp set only the output stream? The description
3945seems to say that each should set both input and output streams. If
3946that's really the intent, I withdraw this proposal.</p>
3947<p><b>Proposed resolution:</b></p>
3948<p>In section 27.6.1.3 change:</p>
3949
3950<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3951Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3952
3953<p>To:</p>
3954
3955<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3956Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
3957
3958<p>In section 27.6.1.3 change:</p>
3959
3960<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3961Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3962
3963<p>To:</p>
3964
3965<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3966Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
3967
3968<p>In section 27.6.2.4, paragraph 2 change:</p>
3969
3970<pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3971
3972<p>To:</p>
3973
3974<pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
3975
3976<p>In section 27.6.2.4, paragraph 4 change:</p>
3977
3978<pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3979
3980<p>To:</p>
3981
3982<pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
3983
3984<p><i>[Dublin: Dietmar K�hl thinks this is probably correct, but would
3985like the opinion of more iostream experts before taking action.]</i></p>
3986
3987<p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
3988incorrect, his implementation already implements the Proposed
3989Resolution.]</i></p>
3990
3991<p><i>[Post-Tokyo: Matt Austern comments:<br>
3992Is it a problem with basic_istream and basic_ostream, or is it a problem
3993with basic_stringbuf?
3994We could resolve the issue either by changing basic_istream and
3995basic_ostream, or by changing basic_stringbuf. I prefer the latter
3996change (or maybe both changes): I don't see any reason for the standard to
3997require that std::stringbuf s(std::string("foo"), std::ios_base::in);
3998s.pubseekoff(0, std::ios_base::beg); must fail.<br>
3999This requirement is a bit weird. There's no similar requirement
4000for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
4001basic_filebuf&lt;&gt;::seekpos.]</i></p>
4002<hr>
4003<a name="137"><h3>137.&nbsp;Do use_facet and has_facet look in the global locale?</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;17 Mar 1999</p>
4004<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>
4005
4006<p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
4007chooses a facet, making available all members of the named type. If
4008Facet is not present in a locale (or, failing that, in the global
4009locale), it throws the standard exception bad_cast. A C++ program can
4010check if a locale implements a particular facet with the template
4011function has_facet&lt;Facet&gt;(). </p>
4012
4013<p>This contradicts the specification given in section
401422.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>:
4015<br><br>
4016template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
4017locale&amp;&nbsp; loc); <br>
4018<br>
4019-1- Get a reference to a facet of a locale. <br>
4020-2- Returns: a reference to the corresponding facet of loc, if present. <br>
4021-3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
4022-4- Notes: The reference returned remains valid at least as long as any copy of loc exists
4023</p>
4024<p><b>Proposed resolution:</b></p>
4025<p>Remove the phrase "(or, failing that, in the global locale)"
4026from section 22.1.1. </p>
4027<p><b>Rationale:</b></p>
4028<p>Needed for consistency with the way locales are handled elsewhere
4029in the standard.</p>
4030<hr>
4031<a name="139"><h3>139.&nbsp;Optional sequence operation table description unclear</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Mar 1999</p>
4032<p>The sentence introducing the Optional sequence operation table
4033(23.1.1 paragraph 12) has two problems:</p>
4034
4035<p>A. It says ``The operations in table 68 are provided only for the containers for which
4036they take constant time.''<br>
4037<br>
4038That could be interpreted in two ways, one of them being ``Even though table 68 shows
4039particular operations as being provided, implementations are free to omit them if they
4040cannot implement them in constant time.''<br>
4041<br>
4042B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
4043<p><b>Proposed resolution:</b></p>
4044<p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
4045with:</p>
4046
4047<blockquote>
4048  <p>Table 68 lists sequence operations that are provided for some types of sequential
4049  containers but not others. An implementation shall provide these operations for all
4050  container types shown in the ``container'' column, and shall implement them so as to take
4051  amortized constant time.</p>
4052</blockquote>
4053<hr>
4054<a name="141"><h3>141.&nbsp;basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Arch Robison&nbsp; <b>Date:</b>&nbsp;28 Apr 1999</p>
4055<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
4056say:<br>
4057<br>
4058&#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
4059
4060<p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
4061
4062<p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
4063proposed resolution.]</i></p>
4064<p><b>Proposed resolution:</b></p>
4065<p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
4066<br>
4067&#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
4068<br>
4069</tt>to:<br>
4070<tt><br>
4071</tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
4072<hr>
4073<a name="142"><h3>142.&nbsp;lexicographical_compare complexity wrong</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Jun 1999</p>
4074<p>The lexicographical_compare complexity is specified as:<br>
4075<br>
4076&nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
4077applications of the corresponding comparison."<br>
4078<br>
4079The best I can do is twice that expensive.</p>
4080
4081<p>Nicolai Josuttis comments in lib-6862: You mean, to check for
4082equality you have to check both &lt; and &gt;? Yes, IMO you are
4083right! (and Matt states this complexity in his book)</p>
4084
4085<p><b>Proposed resolution:</b></p>
4086<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>
4087    <blockquote>
4088    At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
4089    applications of the corresponding comparison.
4090    </blockquote>
4091
4092<p>Change the example at the end of paragraph 3 to read:</p>
4093    <blockquote>
4094    [Example:<br>
4095    <br>
4096    &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
4097    ++first1, ++first2) {<br>
4098    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
4099    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
4100    &nbsp;&nbsp;&nbsp; }<br>
4101    &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
4102    &nbsp;&nbsp;&nbsp;<br>
4103    --end example]
4104    </blockquote>
4105<hr>
4106<a name="144"><h3>144.&nbsp;Deque constructor complexity wrong </h3></a><p><b>Section:</b>&nbsp;23.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array.cons"> [lib.array.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;9 May 1999</p>
4107<p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
4108to have complexity requirements which are incorrect, and which contradict the
4109complexity requirements for insert(). I suspect that the text in question,
4110below, was taken from vector:</p>
4111<blockquote>
4112  <p>Complexity: If the iterators first and last are forward iterators,
4113  bidirectional iterators, or random access iterators the constructor makes only
4114  N calls to the copy constructor, and performs no reallocations, where N is
4115  last - first.</p>
4116</blockquote>
4117<p>The word "reallocations" does not really apply to deque. Further,
4118all of the following appears to be spurious:</p>
4119<blockquote>
4120  <p>It makes at most 2N calls to the copy constructor of T and log N
4121  reallocations if they are input iterators.1)</p>
4122  <p>1) The complexity is greater in the case of input iterators because each
4123  element must be added individually: it is impossible to determine the distance
4124  between first abd last before doing the copying.</p>
4125</blockquote>
4126<p>This makes perfect sense for vector, but not for deque. Why should deque gain
4127an efficiency advantage from knowing in advance the number of elements to
4128insert?</p>
4129<p><b>Proposed resolution:</b></p>
4130<p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
4131footnote, with the following text (which also corrects the "abd"
4132typo):</p>
4133<blockquote>
4134  <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
4135</blockquote>
4136<hr>
4137<a name="146"><h3>146.&nbsp;complex&lt;T&gt; Inserter and Extractor need sentries</h3></a><p><b>Section:</b>&nbsp;26.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;12 May 1999</p>
4138<p>The <u> extractor</u> for complex numbers is specified as:&nbsp;</p>
4139
4140<blockquote>
4141
4142<p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4143     basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
4144     operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
4145&nbsp;<br>
4146Effects: Extracts a complex number x of the form: u, (u), or (u,v),
4147where u is the real part and v is the imaginary part
4148(lib.istream.formatted).&nbsp;<br>
4149Requires: The input values be convertible to T. If bad input is
4150encountered, calls is.setstate(ios::failbit) (which may throw
4151ios::failure (lib.iostate.flags).&nbsp;<br>
4152Returns: is .</p>
4153
4154</blockquote>
4155<p>Is it intended that the extractor for complex numbers does not skip
4156whitespace, unlike all other extractors in the standard library do?
4157Shouldn't a sentry be used?&nbsp;<br>
4158<br>
4159The <u>inserter</u> for complex numbers is specified as:</p>
4160
4161<blockquote>
4162
4163<p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4164     basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4165     operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
4166<br>
4167Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
4168<br>
4169     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4170     basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4171     operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
4172     {&nbsp;<br>
4173             basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
4174             s.flags(o.flags());&nbsp;<br>
4175             s.imbue(o.getloc());&nbsp;<br>
4176             s.precision(o.precision());&nbsp;<br>
4177             s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
4178             return o &lt;&lt; s.str();&nbsp;<br>
4179     }</p>
4180
4181</blockquote>
4182
4183<p>Is it intended that the inserter for complex numbers ignores the
4184field width and does not do any padding? If, with the suggested
4185implementation above, the field width were set in the stream then the
4186opening parentheses would be adjusted, but the rest not, because the
4187field width is reset to zero after each insertion.</p>
4188
4189<p>I think that both operations should use sentries, for sake of
4190consistency with the other inserters and extractors in the
4191library. Regarding the issue of padding in the inserter, I don't know
4192what the intent was.&nbsp;</p>
4193<p><b>Proposed resolution:</b></p>
4194<p>After 26.3.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&gt;&gt;), add a
4195Notes clause:</p>
4196
4197<blockquote>
4198
4199<p>Notes: This extraction is performed as a series of simpler
4200extractions. Therefore, the skipping of whitespace is specified to be the
4201same for each of the simpler extractions.</p>
4202
4203</blockquote>
4204<p><b>Rationale:</b></p>
4205<p>For extractors, the note is added to make it clear that skipping whitespace
4206follows an "all-or-none" rule.</p>
4207
4208<p>For inserters, the LWG believes there is no defect; the standard is correct
4209as written.</p>
4210<hr>
4211<a name="147"><h3>147.&nbsp;Library Intro refers to global functions that aren't global</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
4212<p>The library had many global functions until 17.4.1.1 [lib.contents]
4213paragraph 2 was added: </p>
4214
4215<blockquote>
4216
4217<p>All library entities except macros, operator new and operator
4218delete are defined within the namespace std or namespaces nested
4219within namespace std. </p>
4220
4221</blockquote>
4222
4223<p>It appears "global function" was never updated in the following: </p>
4224
4225<blockquote>
4226
4227<p>17.4.4.3 - Global functions [lib.global.functions]<br>
4228<br>
4229-1- It is unspecified whether any global functions in the C++ Standard
4230Library are defined as inline (dcl.fct.spec).<br>
4231<br>
4232-2- A call to a global function signature described in Clauses
4233lib.language.support through lib.input.output behaves the same as if
4234the implementation declares no additional global function
4235signatures.*<br>
4236<br>
4237    [Footnote: A valid C++ program always calls the expected library
4238    global function. An implementation may also define additional
4239    global functions that would otherwise not be called by a valid C++
4240    program. --- end footnote]<br>
4241<br>
4242-3- A global function cannot be declared by the implementation as
4243taking additional default arguments.&nbsp;<br>
4244<br>
424517.4.4.4 - Member functions [lib.member.functions]<br>
4246<br>
4247-2- An implementation can declare additional non-virtual member
4248function signatures within a class: </p>
4249
4250  <blockquote>
4251
4252<p>-- by adding arguments with default values to a member function
4253signature; The same latitude does not extend to the implementation of
4254virtual or global functions, however. </p>
4255
4256  </blockquote>
4257</blockquote>
4258<p><b>Proposed resolution:</b></p>
4259<p>     Change "global" to "global or non-member" in:</p>
4260<blockquote>
4261  <p>17.4.4.3 [lib.global.functions] section title,<br>
4262  17.4.4.3 [lib.global.functions] para 1,<br>
4263  17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
4264           places in the footnote,<br>
4265  17.4.4.3 [lib.global.functions] para 3,<br>
4266  17.4.4.4 [lib.member.functions] para 2</p>
4267</blockquote>
4268<p><b>Rationale:</b></p>
4269<p>
4270Because operator new and delete are global, the proposed resolution
4271was changed from "non-member" to "global or non-member.
4272</p>
4273<hr>
4274<a name="148"><h3>148.&nbsp;Functions in the example facet BoolNames should be const</h3></a><p><b>Section:</b>&nbsp;22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;3 Jun 1999</p>
4275<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
4276do_falsename() functions in the example facet BoolNames should be
4277const. The functions they are overriding in
4278numpunct_byname&lt;char&gt; are const. </p>
4279<p><b>Proposed resolution:</b></p>
4280<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
4281two places:</p>
4282<blockquote>
4283  <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
4284  string do_falsename() const { return "Mais Non!"; }</tt></p>
4285</blockquote>
4286<hr>
4287<a name="150"><h3>150.&nbsp;Find_first_of says integer instead of iterator </h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt McClure&nbsp; <b>Date:</b>&nbsp;30 Jun 1999</p>
4288<p><b>Proposed resolution:</b></p>
4289<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>
4290
4291<blockquote>
4292<p>Returns: The first iterator i in the range [first1, last1) such
4293that for some <u>integer</u> j in the range [first2, last2) ...</p>
4294</blockquote>
4295
4296<p>to:</p>
4297
4298<blockquote>
4299<p>Returns: The first iterator i in the range [first1, last1) such
4300that for some iterator j in the range [first2, last2) ...</p>
4301</blockquote>
4302<hr>
4303<a name="151"><h3>151.&nbsp;Can't currently clear() empty container</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;21 Jun 1999</p>
4304<p>For both sequences and associative containers, a.clear() has the
4305semantics of erase(a.begin(),a.end()), which is undefined for an empty
4306container since erase(q1,q2) requires that q1 be dereferenceable
4307(23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
4308not dereferenceable.<br>
4309<br>
4310The requirement that q1 be unconditionally dereferenceable causes many
4311operations to be intuitively undefined, of which clearing an empty
4312container is probably the most dire.<br>
4313<br>
4314Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
4315q2) is required to be a valid range, stating that q1 and q2 must be
4316iterators or certain kinds of iterators is unnecessary.
4317</p>
4318<p><b>Proposed resolution:</b></p>
4319<p>In 23.1.1, paragraph 3, change:</p>
4320<blockquote>
4321  <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>
4322</blockquote>
4323<p>to:</p>
4324<blockquote>
4325  <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
4326  in a</u></p>
4327</blockquote>
4328<p>In 23.1.2, paragraph 7, change:</p>
4329<blockquote>
4330  <p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
4331  iterators to a, [q1, q2) is a valid range</p>
4332</blockquote>
4333<p>to</p>
4334<blockquote>
4335  <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
4336  <u>into a</u></p>
4337</blockquote>
4338<hr>
4339<a name="152"><h3>152.&nbsp;Typo in <tt>scan_is()</tt> semantics</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4340<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
4341because there is no function <tt>is()</tt> which only takes a character as
4342argument. Also, in the effects clause (paragraph 3), the semantic is also kept
4343vague.</p>
4344<p><b>Proposed resolution:</b></p>
4345<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
4346clause from:</p>
4347<blockquote>
4348  <p>"... such that <tt>is(*p)</tt>
4349would..."</p>
4350</blockquote>
4351<p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
4352 would...."</p>
4353<hr>
4354<a name="153"><h3>153.&nbsp;Typo in <tt>narrow()</tt> semantics</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4355<p>The description of the array version of <tt>narrow()</tt> (in
4356paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
4357takes only three arguments because in addition to the range a default
4358character is needed.</p>
4359
4360<p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
4361two signatures followed by a <b>Returns</b> clause that only addresses
4362one of them.</p>
4363
4364<p><b>Proposed resolution:</b></p>
4365<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>
4366paragraph 10 from:</p>
4367<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
4368
4369<p>to:</p>
4370<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
4371respectively.</p>
4372
4373<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>
4374<pre>        char        narrow(char c, char /*dfault*/) const;
4375        const char* narrow(const char* low, const char* high,
4376                           char /*dfault*/, char* to) const;</pre>
4377<pre>        Returns: do_narrow(low, high, to).</pre>
4378<p>to:</p>
4379<pre>        char        narrow(char c, char dfault) const;
4380        const char* narrow(const char* low, const char* high,
4381                           char dfault, char* to) const;</pre>
4382<pre>        Returns: do_narrow(c, dfault) or
4383                 do_narrow(low, high, dfault, to), respectively.</pre>
4384
4385<p><i>[Kona: 1) the problem occurs in additional places, 2) a user
4386defined version could be different.]</i></p>
4387
4388<p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
4389the LWG. He could find no other places the problem occurred. He
4390asks for clarification of the Kona "a user defined
4391version..." comment above.  Perhaps it was a circuitous way of
4392saying "dfault" needed to be uncommented?]</i></p>
4393
4394<p><i>[Post-Toronto: the issues list maintainer has merged in the
4395proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
4396same paragraphs.]</i></p>
4397<hr>
4398<a name="154"><h3>154.&nbsp;Missing <tt>double</tt> specifier for <tt>do_get()</tt>
4399</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4400<p>The table in paragraph 7 for the length modifier does not list the length
4401modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
4402standard asks the implementation to do undefined things when using <tt>scanf()</tt>
4403(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
4404is actually a problem I found quite often in production code, too).</p>
4405<p><b>Proposed resolution:</b></p>
4406<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
4407Modifier table to say that for <tt>double</tt> a length modifier
4408<tt>l</tt> is to be used.</p>
4409<p><b>Rationale:</b></p>
4410<p>The standard makes an embarrassing beginner's mistake.</p>
4411<hr>
4412<a name="155"><h3>155.&nbsp;Typo in naming the class defining the class <tt>Init</tt>
4413</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4414<p>There are conflicting statements about where the class
4415<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
4416it 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>
4417<p><b>Proposed resolution:</b></p>
4418<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
4419"<tt>basic_ios::Init"</tt> to
4420"<tt>ios_base::Init"</tt>.</p>
4421<p><b>Rationale:</b></p>
4422<p>Although not strictly wrong, the standard was misleading enough to warrant
4423the change.</p>
4424<hr>
4425<a name="156"><h3>156.&nbsp;Typo in <tt>imbue()</tt> description</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4426<p>There is a small discrepancy between the declarations of
4427<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
4428<tt>locale const&amp;</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
4429is passed as <tt>locale const</tt> (wrong).</p>
4430<p><b>Proposed resolution:</b></p>
4431<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
4432from "<tt>locale const" to "locale
4433const&amp;".</tt></p>
4434<hr>
4435<a name="158"><h3>158.&nbsp;Underspecified semantics for <tt>setbuf()</tt>
4436</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4437<p>The default behavior of <tt>setbuf()</tt> is described only for the
4438situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
4439namely to do nothing.  What has to be done in other situations&nbsp;
4440is not described although there is actually only one reasonable
4441approach, namely to do nothing, too.</p>
4442
4443<p>Since changing the buffer would almost certainly mess up most
4444buffer management of derived classes unless these classes do it
4445themselves, the default behavior of <tt>setbuf()</tt> should always be
4446to do nothing.</p>
4447<p><b>Proposed resolution:</b></p>
4448<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,
4449to: "Default behavior: Does nothing. Returns this."</p>
4450<hr>
4451<a name="159"><h3>159.&nbsp;Strange use of <tt>underflow()</tt>
4452</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4453<p>The description of the meaning of the result of
4454<tt>showmanyc()</tt> seems to be rather strange: It uses calls to
4455<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
4456this function only reads the current character but does not extract
4457it, <tt>uflow()</tt> would extract the current character. This should
4458be fixed to use <tt>sbumpc()</tt> instead.</p>
4459<p><b>Proposed resolution:</b></p>
4460<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,
4461<tt>showmanyc()</tt>returns clause, by replacing the word
4462"supplied" with the words "extracted from the
4463stream".</p>
4464<hr>
4465<a name="160"><h3>160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
4466</h3></a><p><b>Section:</b>&nbsp;27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4467<p>The paragraph 4 refers to the function <tt>exception()</tt> which
4468is not defined. Probably, the referred function is
4469<tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
4470<p><b>Proposed resolution:</b></p>
4471<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,
447227.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>,
4473paragraph 1, change "<tt>exception()" to
4474"exceptions()"</tt>.</p>
4475
4476<p><i>[Note to Editor: "exceptions" with an "s"
4477is the correct spelling.]</i></p>
4478<hr>
4479<a name="161"><h3>161.&nbsp;Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
4480</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4481<p>The note in the second paragraph pretends that the first argument
4482is an object of type <tt>istream_iterator</tt>. This is wrong: It is
4483an object of type <tt>istreambuf_iterator</tt>.</p>
4484<p><b>Proposed resolution:</b></p>
4485<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>
4486<blockquote>
4487  <p>The first argument provides an object of the istream_iterator class...</p>
4488</blockquote>
4489<p>to</p>
4490<blockquote>
4491  <p>The first argument provides an object of the istreambuf_iterator class...</p>
4492</blockquote>
4493<hr>
4494<a name="164"><h3>164.&nbsp;do_put() has apparently unused fill argument</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4495<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
4496as taking a fill character as an argument, but the description of the
4497function does not say whether the character is used at all and, if so,
4498in which way. The same holds for any format control parameters that
4499are accessible through the ios_base&amp; argument, such as the
4500adjustment or the field width. Is strftime() supposed to use the fill
4501character in any way? In any case, the specification of
4502time_put.do_put() looks inconsistent to me.<br> <br> Is the
4503signature of do_put() wrong, or is the effects clause incomplete?</p>
4504<p><b>Proposed resolution:</b></p>
4505<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>
4506paragraph 2:</p>
4507<blockquote>
4508  <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
4509  for this argument. --end Note]</p>
4510</blockquote>
4511<p><b>Rationale:</b></p>
4512<p>The LWG felt that while the normative text was correct,
4513users need some guidance on what to pass for the <tt>fill</tt>
4514argument since the standard doesn't say how it's used.</p>
4515<hr>
4516<a name="165"><h3>165.&nbsp;<tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3></a><p><b>Section:</b>&nbsp;27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4517<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
4518functions falling into one of the groups "formatted output functions"
4519and "unformatted output functions" calls any stream buffer function
4520which might call a virtual function other than <tt>overflow()</tt>. Basically
4521this is fine but this implies that <tt>sputn()</tt> (this function would call
4522the virtual function <tt>xsputn()</tt>) is never called by any of the standard
4523output functions. Is this really intended? At minimum it would be convenient to
4524call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
4525is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
4526with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
4527and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
4528under "unformatted output functions").</p>
4529<p>In addition, I guess that the sentence starting with "They may use other
4530public members of <tt>basic_ostream</tt> ..." probably was intended to
4531start with "They may use other public members of <tt>basic_streamuf</tt>..."
4532although the problem with the virtual members exists in both cases.</p>
4533<p>I see two obvious resolutions:</p>
4534<ol>
4535  <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
4536    called by any ostream member and that this is intended.</li>
4537  <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
4538    Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
4539</ol>
4540<p><b>Proposed resolution:</b></p>
4541<p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
4542<blockquote>
4543  <p>They may use other public members of basic_ostream except that they do not
4544  invoke any virtual members of rdbuf() except overflow().</p>
4545</blockquote>
4546<p>to:</p>
4547<blockquote>
4548  <p>They may use other public members of basic_ostream except that they shall
4549  not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
4550  sync().</p>
4551</blockquote>
4552
4553<p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
4554PJP why the standard is written this way.]</i></p>
4555
4556<p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
4557LWG. He comments: The rules can be made a little bit more specific if
4558necessary be explicitly spelling out what virtuals are allowed to be
4559called from what functions and eg to state specifically that flush()
4560is allowed to call sync() while other functions are not.]</i></p>
4561<hr>
4562<a name="167"><h3>167.&nbsp;Improper use of <tt>traits_type::length()</tt>
4563</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4564<p>Paragraph 4 states that the length is determined using
4565<tt>traits::length(s)</tt>.  Unfortunately, this function is not
4566defined for example if the character type is <tt>wchar_t</tt> and the
4567type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
4568the character type is <tt>char</tt> and the type of <tt>s</tt> is
4569either <tt>signed char const*</tt> or <tt>unsigned char
4570const*</tt>.</p>
4571<p><b>Proposed resolution:</b></p>
4572<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>
4573<blockquote>
4574  <p>Effects: Behaves like an formatted inserter (as described in
4575  lib.ostream.formatted.reqmts) of out. After a sentry object is
4576  constructed it inserts characters. The number of characters starting
4577  at s to be inserted is traits::length(s). Padding is determined as
4578  described in lib.facet.num.put.virtuals. The traits::length(s)
4579  characters starting at s are widened using out.widen
4580  (lib.basic.ios.members). The widened characters and any required
4581  padding are inserted into out. Calls width(0).</p>
4582</blockquote>
4583<p>to:</p>
4584<blockquote>
4585  <p>Effects: Behaves like a formatted inserter (as described in
4586  lib.ostream.formatted.reqmts) of out. After a sentry object is
4587  constructed it inserts <i>n</i> characters starting at <i>s</i>,
4588  where <i>n</i> is the number that would be computed as if by:</p>
4589  <ul>
4590  <li>traits::length(s) for the overload where the first argument is of
4591    type basic_ostream&lt;charT, traits&gt;&amp; and the second is
4592    of type const charT*, and also for the overload where the first
4593    argument is of type basic_ostream&lt;char, traits&gt;&amp; and
4594    the second is of type const char*.</li>
4595  <li>std::char_traits&lt;char&gt;::length(s)
4596    for the overload where the first argument is of type
4597    basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
4598    const char*.</li>
4599  <li>traits::length(reinterpret_cast&lt;const char*&gt;(s))
4600    for the other two overloads.</li>
4601  </ul>
4602  <p>Padding is determined as described in
4603  lib.facet.num.put.virtuals. The <i>n</i> characters starting at
4604  <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
4605  widened characters and any required padding are inserted into
4606  out. Calls width(0).</p>
4607</blockquote>
4608
4609<p><i>[Santa Cruz: Matt supplied new wording]</i></p>
4610
4611<p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
4612  number that would be computed as if by"]</i></p>
4613
4614<p><b>Rationale:</b></p>
4615<p>We have five separate cases.  In two of them we can use the
4616user-supplied traits class without any fuss.  In the other three we
4617try to use something as close to that user-supplied class as possible.
4618In two cases we've got a traits class that's appropriate for
4619char and what we've got is a const signed char* or a const
4620unsigned char*; that's close enough so we can just use a reinterpret
4621cast, and continue to use the user-supplied traits class.  Finally,
4622there's one case where we just have to give up: where we've got a
4623traits class for some arbitrary charT type, and we somehow have to
4624deal with a const char*.  There's nothing better to do but fall back
4625to char_traits&lt;char&gt;</p>
4626<hr>
4627<a name="168"><h3>168.&nbsp;Typo: formatted vs. unformatted</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4628<p>The first paragraph begins with a descriptions what has to be done
4629in <i>formatted</i> output functions. Probably this is a typo and the
4630paragraph really want to describe unformatted output functions...</p>
4631<p><b>Proposed resolution:</b></p>
4632<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
4633sentences, change the word "formatted" to
4634"unformatted":</p>
4635<blockquote>
4636  <p>"Each <b>unformatted </b> output function begins ..."<br>
4637  "... value specified for the <b>unformatted </b>  output
4638  function."</p>
4639</blockquote>
4640<hr>
4641<a name="169"><h3>169.&nbsp;Bad efficiency of <tt>overflow()</tt> mandated</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4642<p>Paragraph 8, Notes, of this section seems to mandate an extremely
4643inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
4644especially in view of the restriction that <tt>basic_ostream</tt>
4645member 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
4646is to be created.</p>
4647<p>Of course, the resolution below requires some handling of
4648simultaneous input and output since it is no longer possible to update
4649<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
4650solution is to handle this in <tt>underflow()</tt>.</p>
4651<p><b>Proposed resolution:</b></p>
4652<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
4653"at least" as in the following:</p>
4654<blockquote>
4655  <p>To make a write position available, the function reallocates (or initially
4656  allocates) an array object with a sufficient number of elements to hold the
4657  current array object (if any), plus <b>at least</b> one additional write
4658  position.</p>
4659</blockquote>
4660<hr>
4661<a name="170"><h3>170.&nbsp;Inconsistent definition of <tt>traits_type</tt>
4662</h3></a><p><b>Section:</b>&nbsp;27.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4663<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>),
4664<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
4665<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
4666in their definition of the type <tt>traits_type</tt>: For
4667<tt>istringstream</tt>, this type is defined, for the other two it is
4668not. This should be consistent.</p>
4669<p><b>Proposed resolution:</b></p>
4670<p><b>Proposed resolution:</b></p> <p>To the declarations of
4671<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
4672<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>
4673<blockquote>
4674<pre>typedef traits traits_type;</pre>
4675</blockquote>
4676<hr>
4677<a name="171"><h3>171.&nbsp;Strange <tt>seekpos()</tt> semantics due to joint position</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4678<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
4679output position is maintained by <tt>basic_filebuf</tt>. Still, the
4680description of <tt>seekpos()</tt> seems to talk about different file
4681positions. In particular, it is unclear (at least to me) what is
4682supposed to happen to the output buffer (if there is one) if only the
4683input position is changed. The standard seems to mandate that the
4684output buffer is kept and processed as if there was no positioning of
4685the output position (by changing the input position). Of course, this
4686can be exactly what you want if the flag <tt>ios_base::ate</tt> is
4687set. However, I think, the standard should say something like
4688this:</p>
4689<ul>
4690  <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
4691    changed and the call fails. Otherwise, the joint read and write position is
4692    altered to correspond to <tt>sp</tt>.</li>
4693  <li>If there is an output buffer, the output sequences is updated and any
4694    unshift sequence is written before the position is altered.</li>
4695  <li>If there is an input buffer, the input sequence is updated after the
4696    position is altered.</li>
4697</ul>
4698<p>Plus the appropriate error handling, that is...</p>
4699<p><b>Proposed resolution:</b></p>
4700<p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
4701paragraph 14 from:</p>
4702<blockquote>
4703  <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4704  ios_base::out);</p>
4705  <p>Alters the file position, if possible, to correspond to the position stored
4706  in sp (as described below).</p>
4707  <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
4708  the input sequence</p>
4709  <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
4710  any unshift sequence, and set the file position to sp.</p>
4711</blockquote>
4712<p>to:</p>
4713<blockquote>
4714  <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4715  ios_base::out);</p>
4716  <p>Alters the file position, if possible, to correspond to the position stored
4717  in sp (as described below). Altering the file position performs as follows:</p>
4718  <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
4719  write any unshift sequence;</p>
4720  <p>2. set the file position to sp;</p>
4721  <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
4722  <p>where om is the open mode passed to the last call to open(). The operation
4723  fails if is_open() returns false.</p>
4724</blockquote>
4725
4726<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
4727<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
4728<hr>
4729<a name="172"><h3>172.&nbsp;Inconsistent types for <tt>basic_istream::ignore()</tt>
4730</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4731<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
4732<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
4733argument. 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>
4734paragraph 23 the first argument is of type <tt>int.</tt></p>
4735
4736<p>As far as I can see this is not really a contradiction because
4737everything is consistent if <tt>streamsize</tt> is typedef to be
4738<tt>int</tt>. However, this is almost certainly not what was
4739intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
4740as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
4741
4742<p>Darin Adler also
4743submitted this issue, commenting: Either 27.6.1.1 should be modified
4744to show a first parameter of type int, or 27.6.1.3 should be modified
4745to show a first parameter of type streamsize and use
4746numeric_limits&lt;streamsize&gt;::max.</p>
4747<p><b>Proposed resolution:</b></p>
4748<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
4749of <tt>int</tt> in the description of <tt>ignore()</tt> to
4750<tt>streamsize</tt>.</p>
4751<hr>
4752<a name="173"><h3>173.&nbsp;Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
4753</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4754
4755<p>
4756In 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
4757object of type <tt>streamsize</tt> as second argument. However, in
475827.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
4759<tt>int</tt>.
4760</p>
4761
4762<p>
4763As far as I can see this is not really a contradiction because
4764everything is consistent if <tt>streamsize</tt> is typedef to be
4765<tt>int</tt>. However, this is almost certainly not what was
4766intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
4767as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
4768</p>
4769
4770<p><b>Proposed resolution:</b></p>
4771<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
4772<tt>int</tt> in the description of <tt>setbuf()</tt> to
4773<tt>streamsize</tt>.</p>
4774<hr>
4775<a name="174"><h3>174.&nbsp;Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
4776</h3></a><p><b>Section:</b>&nbsp;D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4777<p>According to paragraph 1 of this section, <tt>streampos</tt> is the
4778type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
4779paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
4780<p><b>Proposed resolution:</b></p>
4781<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
4782OFF_T streampos;</tt>" to "<tt>typedef POS_T
4783streampos;</tt>"</p>
4784<hr>
4785<a name="175"><h3>175.&nbsp;Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3></a><p><b>Section:</b>&nbsp;D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4786<p>According to paragraph 8 of this section, the methods
4787<tt>basic_streambuf::pubseekpos()</tt>,
4788<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
4789"may" be overloaded by a version of this function taking the
4790type <tt>ios_base::open_mode</tt> as last argument argument instead of
4791<tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
4792in this section to be an alias for one of the integral types). The
4793clause specifies, that the last argument has a default argument in
4794three cases.  However, this generates an ambiguity with the overloaded
4795version because now the arguments are absolutely identical if the last
4796argument is not specified.</p>
4797<p><b>Proposed resolution:</b></p>
4798<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
4799<tt>basic_streambuf::pubseekpos()</tt>,
4800<tt>basic_ifstream::open()</tt>, and
4801<tt>basic_ofstream::open().</tt></p>
4802<hr>
4803<a name="176"><h3>176.&nbsp;<tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3></a><p><b>Section:</b>&nbsp;D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4804<p>The "overload" for the function <tt>exceptions()</tt> in
4805paragraph 8 gives the impression that there is another function of
4806this function defined in class <tt>ios_base</tt>. However, this is not
4807the case. Thus, it is hard to tell how the semantics (paragraph 9) can
4808be implemented: "Call the corresponding member function specified
4809in clause 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>."</p>
4810<p><b>Proposed resolution:</b></p>
4811<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
4812function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
4813<hr>
4814<a name="179"><h3>179.&nbsp;Comparison of const_iterators to iterators doesn't work</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;2 Jul 1998</p>
4815<p>Currently the following will not compile on two well-known standard
4816library implementations:</p>
4817
4818<blockquote>
4819  <pre>#include &lt;set&gt;
4820using namespace std;
4821
4822void f(const set&lt;int&gt; &amp;s)
4823{
4824  set&lt;int&gt;::iterator i;
4825  if (i==s.end()); // s.end() returns a const_iterator
4826}</pre>
4827</blockquote>
4828
4829<p>
4830The reason this doesn't compile is because operator== was implemented
4831as a member function of the nested classes set:iterator and
4832set::const_iterator, and there is no conversion from const_iterator to
4833iterator. Surprisingly, (s.end() == i) does work, though, because of
4834the conversion from iterator to const_iterator.
4835</p>
4836
4837<p>
4838I don't see a requirement anywhere in the standard that this must
4839work. Should there be one?  If so, I think the requirement would need
4840to be added to the tables in section 24.1.1. I'm not sure about the
4841wording.  If this requirement existed in the standard, I would think
4842that implementors would have to make the comparison operators
4843non-member functions.</p>
4844
4845<p>This issues was also raised on comp.std.c++ by Darin
4846Adler.&nbsp; The example given was:</p>
4847
4848<blockquote>
4849  <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
4850std::deque&lt;int&gt;::const_iterator ci)
4851{
4852return i == ci;
4853}</pre>
4854</blockquote>
4855
4856<p>Comment from John Potter:</p>
4857<blockquote>
4858    <p>
4859    In case nobody has noticed, accepting it will break reverse_iterator.
4860    </p>
4861
4862    <p>
4863    The fix is to make the comparison operators templated on two types.
4864    </p>
4865
4866    <pre>    template &lt;class Iterator1, class Iterator2&gt;
4867    bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
4868                     reverse_iterator&lt;Iterator2&gt; const&amp; y);
4869    </pre>
4870
4871    <p>
4872    Obviously:  return x.base() == y.base();
4873    </p>
4874
4875    <p>
4876    Currently, no reverse_iterator to const_reverse_iterator compares are
4877    valid.
4878    </p>
4879
4880    <p>
4881    BTW, I think the issue is in support of bad code.  Compares should be
4882    between two iterators of the same type.  All std::algorithms require
4883    the begin and end iterators to be of the same type.
4884    </p>
4885</blockquote>
4886<p><b>Proposed resolution:</b></p>
4887<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>
4888<blockquote>
4889  <p>In the expressions</p>
4890  <pre>    i == j
4891    i != j
4892    i &lt; j
4893    i &lt;= j
4894    i &gt;= j
4895    i &gt; j
4896    i - j
4897  </pre>
4898  <p>Where i and j denote objects of a container's iterator type,
4899  either or both may be replaced by an object of the container's
4900  const_iterator type referring to the same element with no
4901  change in semantics.</p>
4902</blockquote>
4903
4904<p><i>[post-Toronto: Judy supplied a proposed resolution saying that
4905<tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
4906iterator comparison and difference operations.]</i></p>
4907
4908<p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
4909explicitly listed expressions; there was concern that the previous
4910proposed resolution was too informal.]</i></p>
4911<p><b>Rationale:</b></p>
4912<p>
4913The LWG believes it is clear that the above wording applies only to
4914the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
4915where <tt>X</tt> is a container.  There is no requirement that
4916<tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
4917can be mixed.  If mixing them is considered important, that's a
4918separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
4919</p>
4920<hr>
4921<a name="181"><h3>181.&nbsp;make_pair() unintended behavior</h3></a><p><b>Section:</b>&nbsp;20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;3 Aug 1999</p>
4922<p>The claim has surfaced in Usenet that expressions such as<br>
4923<br>
4924&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
4925<br>
4926are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
4927parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
4928<br>
4929I doubt anyone intended that behavior...
4930</p>
4931<p><b>Proposed resolution:</b></p>
4932<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
4933declaration of make_pair():</p>
4934<blockquote>
4935  <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
4936</blockquote>
4937<p>to:</p>
4938<blockquote>
4939  <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
4940</blockquote>
4941<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>
4942<blockquote>
4943<pre>template &lt;class T1, class T2&gt;
4944pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
4945</blockquote>
4946<p>to:</p>
4947<blockquote>
4948<pre>template &lt;class T1, class T2&gt;
4949pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
4950</blockquote>
4951<p>and add the following footnote to the effects clause:</p>
4952<blockquote>
4953  <p> According to 12.8 [class.copy], an implementation is permitted
4954  to not perform a copy of an argument, thus avoiding unnecessary
4955  copies.</p>
4956</blockquote>
4957<p><b>Rationale:</b></p>
4958<p>Two potential fixes were suggested by Matt Austern and Dietmar
4959K�hl, respectively, 1) overloading with array arguments, and 2) use of
4960a reference_traits class with a specialization for arrays.  Andy
4961Koenig suggested changing to pass by value. In discussion, it appeared
4962that this was a much smaller change to the standard that the other two
4963suggestions, and any efficiency concerns were more than offset by the
4964advantages of the solution. Two implementors reported that the
4965proposed resolution passed their test suites.</p>
4966<hr>
4967<a name="182"><h3>182.&nbsp;Ambiguous references to size_t</h3></a><p><b>Section:</b>&nbsp;17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Al Stevens&nbsp; <b>Date:</b>&nbsp;15 Aug 1999</p>
4968<p>Many references to <tt> size_t</tt> throughout the document
4969omit the <tt> std::</tt> namespace qualification.</p> <p>For
4970example, 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>
4971<blockquote>
4972<pre>&#8212; operator new(size_t)
4973&#8212; operator new(size_t, const std::nothrow_t&amp;)
4974&#8212; operator new[](size_t)
4975&#8212; operator new[](size_t, const std::nothrow_t&amp;)</pre>
4976</blockquote>
4977<p><b>Proposed resolution:</b></p>
4978<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>
4979<blockquote>
4980<p><tt>     - operator new(size_t)<br>
4981     - operator new(size_t, const std::nothrow_t&amp;)<br>
4982     - operator new[](size_t)<br>
4983     - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
4984</blockquote>
4985<p>    by:</p>
4986<blockquote>
4987<pre>- operator new(std::size_t)
4988- operator new(std::size_t, const std::nothrow_t&amp;)
4989- operator new[](std::size_t)
4990- operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
4991</blockquote>
4992<p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
4993<blockquote>
4994  <p>The typedef members pointer, const_pointer, size_type, and difference_type
4995  are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
4996</blockquote>
4997<p>&nbsp;by:</p>
4998<blockquote>
4999  <p>The typedef members pointer, const_pointer, size_type, and difference_type
5000  are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
5001  respectively.</p>
5002</blockquote>
5003<p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
5004<blockquote>
5005  <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
5006  <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
5007  is unspecified when or how often this function is called. The use of hint is
5008  unspecified, but intended as an aid to locality if an implementation so
5009  desires.</p>
5010</blockquote>
5011<p>by:</p>
5012<blockquote>
5013  <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
5014  <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
5015  it is unspecified when or how often this function is called. The use of hint
5016  is unspecified, but intended as an aid to locality if an implementation so
5017  desires.</p>
5018</blockquote>
5019<p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
5020<blockquote>
5021  <p>In Table 37, X denotes a Traits class defining types and functions for the
5022  character container type CharT; c and d denote values of type CharT; p and q
5023  denote values of type const CharT*; s denotes a value of type CharT*; n, i and
5024  j denote values of type size_t; e and f denote values of type X::int_type; pos
5025  denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
5026</blockquote>
5027<p>by:</p>
5028<blockquote>
5029  <p>In Table 37, X denotes a Traits class defining types and functions for the
5030  character container type CharT; c and d denote values of type CharT; p and q
5031  denote values of type const CharT*; s denotes a value of type CharT*; n, i and
5032  j denote values of type std::size_t; e and f denote values of type X::int_type;
5033  pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
5034</blockquote>
5035<p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
5036X::length(p): "size_t" by "std::size_t".</p>
5037<p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
5038&nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
5039    by:<br>
5040&nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
5041<p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
5042declaration of template &lt;class charT&gt; class ctype.<br>
5043<br>
5044   In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
5045<br>
5046&nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
5047&nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
5048&nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
5049<p><b>Rationale:</b></p>
5050<p>The LWG believes correcting names like <tt>size_t</tt> and
5051<tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
5052to be essentially editorial.  There there can't be another size_t or
5053ptrdiff_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>
5054
5055<blockquote>
5056For each type T from the Standard C library, the types ::T and std::T
5057are reserved to the implementation and, when defined, ::T shall be
5058identical to std::T.
5059</blockquote>
5060
5061<p>The issue is treated as a Defect Report to make explicit the Project
5062Editor's authority to make this change.</p>
5063
5064<p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
5065request of the LWG.]</i></p>
5066
5067<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
5068address use of the name <tt>size_t</tt> in contexts outside of
5069namespace std, such as in the description of <tt>::operator new</tt>.
5070The proposed changes should be reviewed to make sure they are
5071correct.]</i></p>
5072
5073<p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
5074them to be correct.]</i></p>
5075
5076<hr>
5077<a name="183"><h3>183.&nbsp;I/O stream manipulators don't work for wide character streams</h3></a><p><b>Section:</b>&nbsp;27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;7 Jul 1999</p>
5078<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
5079exposition):</p>
5080<blockquote>
5081<p>Returns: An object s of unspecified type such that if [1] out is an (instance
5082of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
5083called, and if [2] in is an (instance of) basic_istream then the expression
5084in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
5085f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
5086str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
5087out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
5088has type istream&amp; and value in.</p>
5089</blockquote>
5090<p>Given the definitions [1] and [2] for out and in, surely [3] should read:
5091"The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
5092[4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
5093..."</p>
5094<p>If the wording in the standard is correct, I can see no way of implementing
5095any of the manipulators so that they will work with wide character streams.</p>
5096<p>e.g. wcout &lt;&lt; setbase( 16 );</p>
5097<p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
5098doesn't).</p>
5099<p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
51008. In addition, Para 6 [setfill] has a similar error, but relates only to
5101ostreams.</p>
5102<p>I'd be happier if there was a better way of saying this, to make it clear
5103that the value of the expression is "the same specialization of
5104basic_ostream as out"&amp;</p>
5105<p><b>Proposed resolution:</b></p>
5106<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
5107following:</p>
5108<blockquote>
5109<p>2- The type designated smanip in each of the following function
5110descriptions is implementation-specified and may be different for each
5111function.<br>
5112<br>
5113<tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
5114<br>
5115-3- Returns: An object s of unspecified type such that if out is an
5116instance of basic_ostream&lt;charT,traits&gt; then the expression
5117out&lt;&lt;s behaves
5118as if f(s, mask) were called, or if in is an instance of
5119basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5120behaves as if
5121f(s, mask) were called. The function f can be defined as:*<br>
5122<br>
5123[Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
5124clears ios_base::skipws in the format flags stored in the
5125basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
5126noskipws), and the expression cout &lt;&lt;
5127resetiosflags(ios_base::showbase) clears
5128ios_base::showbase in the format flags stored in the
5129basic_ostream&lt;charT,traits&gt; object cout (the same as cout
5130&lt;&lt;
5131noshowbase). --- end footnote]<br>
5132<br>
5133&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5134&nbsp;&nbsp; {<br>
5135&nbsp;&nbsp; //  reset specified flags<br>
5136&nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
5137&nbsp;&nbsp; return str;<br>
5138&nbsp;&nbsp; }<br>
5139</tt><br>
5140The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5141The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5142<br>
5143&nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
5144<br>
5145-4- Returns: An object s of unspecified type such that if out is an
5146instance of basic_ostream&lt;charT,traits&gt; then the expression
5147out&lt;&lt;s behaves
5148as if f(s, mask) were called, or if in is an instance of
5149basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5150behaves as if f(s,
5151mask) were called. The function f can be defined as:<br>
5152<br>
5153&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5154&nbsp;&nbsp; {<br>
5155&nbsp;&nbsp; //  set specified flags<br>
5156&nbsp;&nbsp; str.setf(mask);<br>
5157&nbsp;&nbsp; return str;<br>
5158&nbsp;&nbsp; }<br>
5159</tt><br>
5160The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5161The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5162<br>
5163<tt>smanip setbase(int base);</tt><br>
5164<br>
5165-5- Returns: An object s of unspecified type such that if out is an
5166instance of basic_ostream&lt;charT,traits&gt; then the expression
5167out&lt;&lt;s behaves
5168as if f(s, base) were called, or if in is an instance of
5169basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5170behaves as if f(s,
5171base) were called. The function f can be defined as:<br>
5172<br>
5173&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
5174&nbsp;&nbsp; {<br>
5175&nbsp;&nbsp; //  set  basefield<br>
5176&nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
5177&nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
5178&nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
5179&nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
5180&nbsp;&nbsp; return str;<br>
5181&nbsp;&nbsp; }<br>
5182</tt><br>
5183The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5184The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5185<br>
5186<tt>smanip setfill(char_type c);<br>
5187</tt><br>
5188-6- Returns: An object s of unspecified type such that if out is (or is
5189derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
5190then the
5191expression out&lt;&lt;s behaves as if f(s, c) were called. The function
5192f can be
5193defined as:<br>
5194<br>
5195&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
5196&nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
5197&nbsp;&nbsp; {<br>
5198&nbsp;&nbsp; //  set fill character<br>
5199&nbsp;&nbsp; str.fill(c);<br>
5200&nbsp;&nbsp; return str;<br>
5201&nbsp;&nbsp; }<br>
5202</tt><br>
5203The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
5204<br>
5205<tt>smanip setprecision(int n);</tt><br>
5206<br>
5207-7- Returns: An object s of unspecified type such that if out is an
5208instance of basic_ostream&lt;charT,traits&gt; then the expression
5209out&lt;&lt;s behaves
5210as if f(s, n) were called, or if in is an instance of
5211basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5212behaves as if f(s, n)
5213were called. The function f can be defined as:<br>
5214<br>
5215&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5216&nbsp;&nbsp; {<br>
5217&nbsp;&nbsp; //  set precision<br>
5218&nbsp;&nbsp; str.precision(n);<br>
5219&nbsp;&nbsp; return str;<br>
5220&nbsp;&nbsp; }<br>
5221</tt><br>
5222The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5223The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
5224.<br>
5225<tt>smanip setw(int n);<br>
5226</tt><br>
5227-8- Returns: An object s of unspecified type such that if out is an
5228instance of basic_ostream&lt;charT,traits&gt; then the expression
5229out&lt;&lt;s behaves
5230as if f(s, n) were called, or if in is an instance of
5231basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5232behaves as if f(s, n)
5233were called. The function f can be defined as:<br>
5234<br>
5235&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5236&nbsp;&nbsp; {<br>
5237&nbsp;&nbsp; //  set width<br>
5238&nbsp;&nbsp; str.width(n);<br>
5239&nbsp;&nbsp; return str;<br>
5240&nbsp;&nbsp; }<br>
5241</tt><br>
5242The expression out&lt;&lt;s has type
5243basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
5244in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
5245in.
5246</p>
5247</blockquote>
5248
5249<p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
5250the proposed resolution.]</i></p>
5251
5252<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
5253the same paragraphs.]</i></p>
5254
5255<p><i>[Post-Tokyo: The issues list maintainer combined the proposed
5256resolution 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
5257intertwined that dealing with them separately appear fraught with
5258error.  The full text was supplied by Bill Plauger; it was cross
5259checked against changes supplied by Andy Sawyer. It should be further
5260checked by the LWG.]</i></p>
5261<hr>
5262<a name="184"><h3>184.&nbsp;numeric_limits&lt;bool&gt; wording problems</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;21 Jul 1999</p>
5263<p>bools are defined by the standard to be of integer types, as per
52643.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"
5265seems to have a special meaning for the author of 18.2. The net effect
5266is an unclear and confusing specification for
5267numeric_limits&lt;bool&gt; as evidenced below.</p>
5268
5269<p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
5270types, the number of non-sign bits in the representation.</p>
5271
5272<p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
5273arithmetical value converts to true.</p>
5274
5275<p>I don't think it makes sense at all to require
5276numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
5277be meaningful.</p>
5278
5279<p>The standard defines what constitutes a signed (resp. unsigned) integer
5280types. It doesn't categorize bool as being signed or unsigned. And the set of
5281values of bool type has only two elements.</p>
5282
5283<p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
5284to be meaningful.</p>
5285
5286<p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
5287<blockquote>
5288  <p>For integer types, specifies the base of the representation.186)</p>
5289</blockquote>
5290
5291<p>This disposition is at best misleading and confusing for the standard
5292requires a "pure binary numeration system" for integer types as per
52933.9.1/7</p>
5294
5295<p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
5296BCD)."&nbsp; This also erroneous as the standard never defines any integer
5297types with base representation other than 2.</p>
5298
5299<p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
5300numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
5301<p><b>Proposed resolution:</b></p>
5302<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>
5303<blockquote>
5304  <p>The specialization for bool shall be provided as follows:</p>
5305  <pre>    namespace std {
5306       template&lt;&gt; class numeric_limits&lt;bool&gt; {
5307       public:
5308         static const bool is_specialized = true;
5309         static bool min() throw() { return false; }
5310         static bool max() throw() { return true; }
5311
5312         static const int  digits = 1;
5313         static const int  digits10 = 0;
5314         static const bool is_signed = false;
5315         static const bool is_integer = true;
5316         static const bool is_exact = true;
5317         static const int  radix = 2;
5318         static bool epsilon() throw() { return 0; }
5319         static bool round_error() throw() { return 0; }
5320
5321         static const int  min_exponent = 0;
5322         static const int  min_exponent10 = 0;
5323         static const int  max_exponent = 0;
5324         static const int  max_exponent10 = 0;
5325
5326         static const bool has_infinity = false;
5327         static const bool has_quiet_NaN = false;
5328         static const bool has_signaling_NaN = false;
5329         static const float_denorm_style has_denorm = denorm_absent;
5330         static const bool has_denorm_loss = false;
5331         static bool infinity() throw() { return 0; }
5332         static bool quiet_NaN() throw() { return 0; }
5333         static bool signaling_NaN() throw() { return 0; }
5334         static bool denorm_min() throw() { return 0; }
5335
5336         static const bool is_iec559 = false;
5337         static const bool is_bounded = true;
5338         static const bool is_modulo = false;
5339
5340         static const bool traps = false;
5341         static const bool tinyness_before = false;
5342         static const float_round_style round_style = round_toward_zero;
5343       };
5344     }</pre>
5345</blockquote>
5346
5347<p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
5348rather than more general wording in the original proposed
5349resolution.]</i></p>
5350
5351<p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
5352Josuttis provided the above wording.]</i></p>
5353<hr>
5354<a name="185"><h3>185.&nbsp;Questionable use of term "inline"</h3></a><p><b>Section:</b>&nbsp;20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;UK Panel&nbsp; <b>Date:</b>&nbsp;26 Jul 1999</p>
5355<p>Paragraph 4 of 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> says:</p>
5356<blockquote>
5357  <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
5358  a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
5359  the addition and the negation. end example]</p>
5360</blockquote>
5361<p>(Note: The "addition" referred to in the above is in para 3) we can
5362find no other wording, except this (non-normative) example which suggests that
5363any "inlining" will take place in this case.</p>
5364<p>Indeed both:</p>
5365<blockquote>
5366  <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
5367  unspecified whether any global functions in the C++ Standard Library
5368  are defined as inline (7.1.2).</p>
5369</blockquote>
5370<p>and</p>
5371<blockquote>
5372  <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
5373  unspecified whether any member functions in the C++ Standard Library
5374  are defined as inline (7.1.2).</p>
5375</blockquote>
5376<p>take care to state that this may indeed NOT be the case.</p>
5377<p>Thus the example "mandates" behavior that is explicitly
5378not required elsewhere.</p>
5379<p><b>Proposed resolution:</b></p>
5380<p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> paragraph 1, remove the sentence:</p>
5381<blockquote>
5382<p>They are important for the effective use of the library.</p>
5383</blockquote>
5384<p>Remove 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> paragraph 2, which reads:</p>
5385<blockquote>
5386  <p> Using function objects together with function templates
5387  increases the expressive power of the library as well as making the
5388  resulting code much more efficient.</p>
5389</blockquote>
5390<p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> paragraph 4, remove the sentence:</p>
5391<blockquote>
5392  <p>The corresponding functions will inline the addition and the
5393  negation.</p>
5394</blockquote>
5395
5396<p><i>[Kona: The LWG agreed there was a defect.]</i></p>
5397<p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
5398<hr>
5399<a name="186"><h3>186.&nbsp;bitset::set() second parameter should be bool</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Darin Adler&nbsp; <b>Date:</b>&nbsp;13 Aug 1999</p>
5400<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
5401bitset::set operation to take a second parameter of type int. The
5402function tests whether this value is non-zero to determine whether to
5403set the bit to true or false. The type of this second parameter should
5404be bool. For one thing, the intent is to specify a Boolean value. For
5405another, the result type from test() is bool. In addition, it's
5406possible to slice an integer that's larger than an int. This can't
5407happen with bool, since conversion to bool has the semantic of
5408translating 0 to false and any non-zero value to true.</p>
5409<p><b>Proposed resolution:</b></p>
5410<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>
5411<blockquote>
5412<pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
5413</blockquote>
5414<p>With:</p>
5415<blockquote>
5416  <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5417</blockquote>
5418<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>
5419<blockquote>
5420  <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
5421</blockquote>
5422<p>With:</p>
5423<blockquote>
5424  <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5425</blockquote>
5426
5427<p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
5428on better P/R wording.]</i></p>
5429<p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
5430<p><b>Rationale:</b></p>
5431<p><tt>bool</tt> is a better choice.  It is believed that binary
5432compatibility is not an issue, because this member function is
5433usually implemented as <tt>inline</tt>, and because it is already
5434the case that users cannot rely on the type of a pointer to a
5435nonvirtual member of a standard library class.</p>
5436<hr>
5437<a name="187"><h3>187.&nbsp;iter_swap underspecified</h3></a><p><b>Section:</b>&nbsp;25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;14 Aug 1999</p>
5438<p>The description of iter_swap in 25.2.2 paragraph 7,says that it
5439``exchanges the values'' of the objects to which two iterators
5440refer.<br> <br> What it doesn't say is whether it does so using swap
5441or using the assignment operator and copy constructor.<br> <br> This
5442question is an important one to answer, because swap is specialized to
5443work efficiently for standard containers.<br> For example:</p>
5444<blockquote>
5445<pre>vector&lt;int&gt; v1, v2;
5446iter_swap(&amp;v1, &amp;v2);</pre>
5447</blockquote>
5448<p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
5449Or is it equivalent to</p>
5450<blockquote>
5451<pre>{
5452vector&lt;int&gt; temp = v1;
5453v1 = v2;
5454v2 = temp;
5455}</pre>
5456</blockquote>
5457<p>The first alternative is O(1); the second is O(n).</p>
5458<p>A LWG member, Dave Abrahams, comments:</p>
5459<blockquote>
5460<p>Not an objection necessarily, but I want to point out the cost of
5461that requirement:</p>
5462  <blockquote>
5463<p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
5464  </blockquote>
5465<p>can currently be specialized to be more efficient than
5466iter_swap(T*,T*) for many T (by using splicing). Your proposal would
5467make that optimization illegal.&nbsp;</p>
5468</blockquote>
5469
5470<p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
5471which are no longer permitted.]</i></p>
5472<p><b>Proposed resolution:</b></p>
5473<p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
5474<blockquote>
5475<p>Exchanges the values pointed to by the two iterators a and b.</p>
5476</blockquote>
5477<p>to</p>
5478<blockquote>
5479<p><tt>swap(*a, *b)</tt>.</p>
5480</blockquote>
5481
5482<p><b>Rationale:</b></p>
5483<p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
5484  some iterators for which we want to specialize <tt>iter_swap</tt>,
5485  but the fully general version should have a general specification.</p>
5486
5487<p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
5488iter_swap should not be specialized as suggested above.  That would do
5489much more than exchanging the two iterators' values: it would change
5490predecessor/successor relationships, possibly moving the iterator from
5491one list to another.  That would surely be inappropriate.</p>
5492<hr>
5493<a name="189"><h3>189.&nbsp;setprecision() not specified correctly</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;25 Aug 1999</p>
5494<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
5495and includes a parenthetical note saying that it is the number of
5496digits after the decimal point.<br>
5497<br>
5498This claim is not strictly correct.  For example, in the default
5499floating-point output format, setprecision sets the number of
5500significant digits printed, not the number of digits after the decimal
5501point.<br>
5502<br>
5503I would like the committee to look at the definition carefully and
5504correct the statement in 27.4.2.2</p>
5505<p><b>Proposed resolution:</b></p>
5506<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
5507"(number of digits after the decimal point)".</p>
5508<hr>
5509<a name="193"><h3>193.&nbsp;Heap operations description incorrect</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;24 Sep 1999</p>
5510<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
5511is<br>
5512<br>
5513&nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
5514<br>
5515I think this is incorrect and should be changed to the wording in the proposed
5516resolution.</p>
5517<p>Actually there are two independent changes:</p>
5518<blockquote>
5519  <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
5520  [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
5521  <p>B-Take
5522'an oldest' from that equivalence class, otherwise the heap functions
5523could not be used for a priority queue as explained in 23.2.3.2.2
5524[lib.priqueue.members] (where I assume that a "priority queue" respects
5525priority AND time).</p>
5526</blockquote>
5527<p><b>Proposed resolution:</b></p>
5528<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>
5529<blockquote>
5530  <p>(1) *a is the largest element</p>
5531</blockquote>
5532<p>to:</p>
5533<blockquote>
5534  <p>(1) There is no element greater than <tt>*a</tt></p>
5535</blockquote>
5536<hr>
5537<a name="195"><h3>195.&nbsp;Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;13 Oct 1999</p>
5538<p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
5539What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
5540reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
5541should set failbit. Should it set eofbit as well?  The standard
5542doesn't seem to answer that question.</p>
5543
5544<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
5545<tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
5546other 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
5547extraction from a <tt>streambuf</tt> "returns
5548<tt>traits::eof()</tt>, then the input function, except as explicitly
5549noted otherwise, completes its actions and does
5550<tt>setstate(eofbit)"</tt>.  So the question comes down to
5551whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
5552input function.</p>
5553
5554<p>Comments from Jerry Schwarz:</p>
5555<blockquote>
5556<p>It was always my intention that eofbit should be set any time that a
5557virtual returned something to indicate eof, no matter what reason
5558iostream code had for calling the virtual.</p>
5559<p>
5560The motivation for this is that I did not want to require streambufs
5561to behave consistently if their virtuals are called after they have
5562signaled eof.</p>
5563<p>
5564The classic case is a streambuf reading from a UNIX file.  EOF isn't
5565really a state for UNIX file descriptors.  The convention is that a
5566read on UNIX returns 0 bytes to indicate "EOF", but the file
5567descriptor isn't shut down in any way and future reads do not
5568necessarily also return 0 bytes.  In particular, you can read from
5569tty's on UNIX even after they have signaled "EOF".  (It
5570isn't always understood that a ^D on UNIX is not an EOF indicator, but
5571an EOL indicator.  By typing a "line" consisting solely of
5572^D you cause a read to return 0 bytes, and by convention this is
5573interpreted as end of file.)</p>
5574</blockquote>
5575<p><b>Proposed resolution:</b></p>
5576<p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
5577<blockquote>
5578<p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
5579returns <tt>traits::eof()</tt>, the function calls
5580<tt>setstate(failbit | eofbit)</tt> (which may throw
5581<tt>ios_base::failure</tt>).
5582</p>
5583</blockquote>
5584<hr>
5585<a name="198"><h3>198.&nbsp;Validity of pointers and references unspecified after iterator destruction</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;3 Nov 1999</p>
5586<p>
5587Is a pointer or reference obtained from an iterator still valid after
5588destruction of the iterator?
5589</p>
5590<p>
5591Is a pointer or reference obtained from an iterator still valid after the value
5592of the iterator changes?
5593</p>
5594<blockquote>
5595<pre>#include &lt;iostream&gt;
5596#include &lt;vector&gt;
5597#include &lt;iterator&gt;
5598
5599int main()
5600{
5601    typedef std::vector&lt;int&gt; vec_t;
5602    vec_t v;
5603    v.push_back( 1 );
5604
5605    // Is a pointer or reference obtained from an iterator still
5606    // valid after destruction of the iterator?
5607    int * p = &amp;*v.begin();
5608    std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5609
5610    // Is a pointer or reference obtained from an iterator still
5611    // valid after the value of the iterator changes?
5612    vec_t::iterator iter( v.begin() );
5613    p = &amp;*iter++;
5614    std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5615
5616    return 0;
5617}
5618</pre>
5619</blockquote>
5620
5621<p>The standard doesn't appear to directly address these
5622questions. The standard needs to be clarified. At least two real-world
5623cases have been reported where library implementors wasted
5624considerable effort because of the lack of clarity in the
5625standard. The question is important because requiring pointers and
5626references to remain valid has the effect for practical purposes of
5627prohibiting iterators from pointing to cached rather than actual
5628elements of containers.</p>
5629
5630<p>The standard itself assumes that pointers and references obtained
5631from an iterator are still valid after iterator destruction or
5632change. 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.conv"> [lib.reverse.iter.conv]</a>, which returns a reference, defines
5633effects:</p>
5634
5635<blockquote>
5636  <pre>Iterator tmp = current;
5637return *--tmp;</pre>
5638</blockquote>
5639<p>The definition of reverse_iterator::operator-&gt;(), 24.4.1.3.4 <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 pointer, defines effects:</p>
5640<blockquote>
5641  <pre>return &amp;(operator*());</pre>
5642</blockquote>
5643
5644<p>Because the standard itself assumes pointers and references remain
5645valid after iterator destruction or change, the standard should say so
5646explicitly. This will also reduce the chance of user code breaking
5647unexpectedly when porting to a different standard library
5648implementation.</p>
5649<p><b>Proposed resolution:</b></p>
5650<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>
5651<blockquote>
5652Destruction of an iterator may invalidate pointers and references
5653previously obtained from that iterator.
5654</blockquote>
5655
5656<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.conv"> [lib.reverse.iter.conv]</a> with:</p>
5657
5658<blockquote>
5659<p><b>Effects:</b></p>
5660<pre>  this-&gt;tmp = current;
5661  --this-&gt;tmp;
5662  return *this-&gt;tmp;
5663</pre>
5664
5665<p>
5666[<i>Note:</i> This operation must use an auxiliary member variable,
5667rather than a temporary variable, to avoid returning a reference that
5668persists beyond the lifetime of its associated iterator.  (See
566924.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
5670exposition only.  <i>--end note</i>]
5671</p>
5672</blockquote>
5673
5674<p><i>[Post-Tokyo: The issue has been reformulated purely
5675in terms of iterators.]</i></p>
5676
5677<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
5678assumption by reverse_iterator. The issue and proposed resolution was
5679reformulated yet again to reflect this reality.]</i></p>
5680
5681<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
5682assumes its underlying iterator has persistent pointers and
5683references.  Andy Koenig pointed out that it is possible to rewrite
5684reverse_iterator so that it no longer makes such an assupmption.
5685However, 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
5686decide it is intentional that <tt>p[n]</tt> may return by value
5687instead of reference when <tt>p</tt> is a Random Access Iterator,
5688other changes in reverse_iterator will be necessary.]</i></p>
5689<p><b>Rationale:</b></p>
5690<p>This issue has been discussed extensively.  Note that it is
5691<i>not</i> an issue about the behavior of predefined iterators.  It is
5692asking whether or not user-defined iterators are permitted to have
5693transient pointers and references.  Several people presented examples
5694of useful user-defined iterators that have such a property; examples
5695include a B-tree iterator, and an "iota iterator" that doesn't point
5696to memory.  Library implementors already seem to be able to cope with
5697such iterators: they take pains to avoid forming references to memory
5698that gets iterated past.  The only place where this is a problem is
5699<tt>reverse_iterator</tt>, so this issue changes
5700<tt>reverse_iterator</tt> to make it work.</p>
5701
5702<p>This resolution does not weaken any guarantees provided by
5703predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
5704Clause 23 should be reviewed to make sure that guarantees for
5705predefined iterators are as strong as users expect.</p>
5706
5707<hr>
5708<a name="199"><h3>199.&nbsp;What does <tt>allocate(0)</tt> return?</h3></a><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
5709<p>
5710Suppose that <tt>A</tt> is a class that conforms to the
5711Allocator requirements of Table 32, and <tt>a</tt> is an
5712object of class <tt>A</tt>  What should be the return
5713value of <tt>a.allocate(0)</tt>?  Three reasonable
5714possibilities: forbid the argument <tt>0</tt>, return
5715a null pointer, or require that the return value be a
5716unique non-null pointer.
5717</p>
5718<p><b>Proposed resolution:</b></p>
5719<p>
5720Add a note to the <tt>allocate</tt> row of Table 32:
5721"[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
5722<p><b>Rationale:</b></p>
5723<p>A key to understanding this issue is that the ultimate use of
5724allocate() is to construct an iterator, and that iterator for zero
5725length sequences must be the container's past-the-end
5726representation.  Since this already implies special case code, it
5727would be over-specification to mandate the return value.
5728</p>
5729<hr>
5730<a name="200"><h3>200.&nbsp;Forward iterator requirements don't allow constant iterators</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
5731<p>
5732In table 74, the return type of the expression <tt>*a</tt> is given
5733as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
5734For constant iterators, however, this is wrong.  ("Value type"
5735is never defined very precisely, but it is clear that the value type
5736of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
5737<tt>int</tt>, not <tt>const int</tt>.)
5738</p>
5739<p><b>Proposed resolution:</b></p>
5740<p>
5741In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
5742return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
5743if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
5744In the <tt>a-&gt;m</tt> row, change the return type from
5745"<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
5746otherwise <tt>const U&amp;</tt>".
5747</p>
5748
5749<p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
5750there are multiple const problems with the STL portion of the library
5751and that these should be addressed as a single package.&nbsp; Note
5752that 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
5753that very reason.]</i></p>
5754
5755<p><i>[Redmond: the LWG thinks this is separable from other constness
5756issues.  This issue is just cleanup; it clarifies language that was
5757written before we had iterator_traits.  Proposed resolution was
5758modified: the original version only discussed *a.  It was pointed out
5759that we also need to worry about *r++ and a-&gt;m.]</i></p>
5760
5761<hr>
5762<a name="202"><h3>202.&nbsp;unique() effects unclear when predicate not an equivalence relation</h3></a><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;13 Jan 2000</p>
5763<p>
5764What should unique() do if you give it a predicate that is not an
5765equivalence relation?  There are at least two plausible answers:
5766</p>
5767
5768<blockquote>
5769
5770<p>
5771   1. You can't, because 25.2.8 says that it it "eliminates all but
5772   the first element from every consecutive group of equal
5773   elements..." and it wouldn't make sense to interpret "equal" as
5774   meaning anything but an equivalence relation.  [It also doesn't
5775   make sense to interpret "equal" as meaning ==, because then there
5776   would never be any sense in giving a predicate as an argument at
5777   all.]
5778</p>
5779
5780<p>
5781   2. The word "equal" should be interpreted to mean whatever the
5782   predicate says, even if it is not an equivalence relation
5783   (and in particular, even if it is not transitive).
5784</p>
5785
5786</blockquote>
5787
5788<p>
5789The example that raised this question is from Usenet:
5790</p>
5791
5792<blockquote>
5793
5794<pre>int f[] = { 1, 3, 7, 1, 2 };
5795int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
5796
5797</blockquote>
5798
5799<p>
5800If one blindly applies the definition using the predicate
5801greater&lt;int&gt;, and ignore the word "equal", you get:
5802</p>
5803
5804<blockquote>
5805
5806<p>
5807    Eliminates all but the first element from every consecutive group
5808    of elements referred to by the iterator i in the range [first, last)
5809    for which *i &gt; *(i - 1).
5810</p>
5811
5812</blockquote>
5813
5814<p>
5815The first surprise is the order of the comparison.  If we wanted to
5816allow for the predicate not being an equivalence relation, then we
5817should surely compare elements the other way: pred(*(i - 1), *i).  If
5818we do that, then the description would seem to say: "Break the
5819sequence into subsequences whose elements are in strictly increasing
5820order, and keep only the first element of each subsequence".  So the
5821result would be 1, 1, 2.  If we take the description at its word, it
5822would seem to call for strictly DEcreasing order, in which case the
5823result should be 1, 3, 7, 2.<br>
5824<br>
5825In fact, the SGI implementation of unique() does neither: It yields 1,
58263, 7.
5827</p>
5828<p><b>Proposed resolution:</b></p>
5829<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>
5830<blockquote>
5831For a nonempty range, eliminates all but the first element from every
5832consecutive group of equivalent elements referred to by the iterator
5833<tt>i</tt> in the range [first+1, last) for which the following
5834conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5835false</tt>.
5836</blockquote>
5837
5838<p>
5839Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
5840comparison function must be an equivalence relation."
5841</p>
5842
5843<p><i>[Redmond: discussed arguments for and against requiring the
5844comparison function to be an equivalence relation.  Straw poll:
584514-2-5.  First number is to require that it be an equivalence
5846relation, second number is to explicitly not require that it be an
5847equivalence relation, third number is people who believe they need
5848more time to consider the issue.  A separate issue: Andy Sawyer
5849pointed out that "i-1" is incorrect, since "i" can refer to the first
5850iterator in the range.  Matt provided wording to address this
5851problem.]</i></p>
5852
5853<p><i>[Cura�ao: The LWG changed "... the range (first,
5854last)..." to "...  the range [first+1, last)..." for
5855clarity. They considered this change close enough to editorial to not
5856require another round of review.]</i></p>
5857
5858<p><b>Rationale:</b></p>
5859<p>The LWG also considered an alternative resolution: change
586025.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>
5861
5862<blockquote>
5863For a nonempty range, eliminates all but the first element from every
5864consecutive group of elements referred to by the iterator
5865<tt>i</tt> in the range (first, last) for which the following
5866conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5867false</tt>.
5868</blockquote>
5869
5870<p>
5871Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
5872comparison function need not be an equivalence relation."
5873</p>
5874
5875
5876<p>Informally: the proposed resolution imposes an explicit requirement
5877that the comparison function be an equivalence relation.  The
5878alternative resolution does not, and it gives enough information so
5879that the behavior of unique() for a non-equivalence relation is
5880specified.  Both resolutions are consistent with the behavior of
5881existing implementations.</p>
5882<hr>
5883<a name="208"><h3>208.&nbsp;Unnecessary restriction on past-the-end iterators</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Stephen Cleary&nbsp; <b>Date:</b>&nbsp;02 Feb 2000</p>
5884<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
5885past-the-end values are always non-singular."</p>
5886<p>This places an unnecessary restriction on past-the-end iterators for
5887containers with forward iterators (for example, a singly-linked list). If the
5888past-the-end value on such a container was a well-known singular value, it would
5889still satisfy all forward iterator requirements.</p>
5890<p>Removing this restriction would allow, for example, a singly-linked list
5891without a "footer" node.</p>
5892<p>This would have an impact on existing code that expects past-the-end
5893iterators obtained from different (generic) containers being not equal.</p>
5894<p><b>Proposed resolution:</b></p>
5895<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>
5896<blockquote>
5897<p>Dereferenceable and past-the-end values are always non-singular.</p>
5898</blockquote>
5899<p>to:</p>
5900<blockquote>
5901<p>Dereferenceable values are always non-singular.&nbsp;</p>
5902</blockquote>
5903<p><b>Rationale:</b></p>
5904<p>For some kinds of containers, including singly linked lists and
5905zero-length vectors, null pointers are perfectly reasonable past-the-end
5906iterators.  Null pointers are singular.
5907</p>
5908<hr>
5909<a name="209"><h3>209.&nbsp;basic_string declarations inconsistent</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Igor Stauder&nbsp; <b>Date:</b>&nbsp;11 Feb 2000</p>
5910<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
5911declarations use a consistent style except for the following functions:</p>
5912<blockquote>
5913  <pre>void push_back(const charT);
5914basic_string&amp; assign(const basic_string&amp;);
5915void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
5916</blockquote>
5917<p>- push_back, assign, swap: missing argument name&nbsp;<br>
5918- push_back: use of const with charT (i.e. POD type passed by value
5919not by reference - should be charT or const charT&amp; )<br>
5920- swap: redundant use of template parameters in argument
5921basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
5922<p><b>Proposed resolution:</b></p>
5923<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
5924function declarations push_back, assign, and swap to:</p>
5925<blockquote>
5926  <pre>void push_back(charT c);
5927
5928basic_string&amp; assign(const basic_string&amp; str);
5929void swap(basic_string&amp; str);</pre>
5930</blockquote>
5931<p><b>Rationale:</b></p>
5932<p>Although the standard is in general not consistent in declaration
5933style, the basic_string declarations are consistent other than the
5934above.  The LWG felt that this was sufficient reason to merit the
5935change.
5936</p>
5937<hr>
5938<a name="210"><h3>210.&nbsp;distance first and last confused</h3></a><p><b>Section:</b>&nbsp;25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;15 Feb 2000</p>
5939<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>
5940<blockquote>
5941  <p>      In the description of the algorithms operators + and - are used
5942           for some of the iterator categories for which they do not have to
5943           be defined. In these cases the semantics of [...] a-b is the same
5944           as of<br>
5945  <br>
5946  &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
5947</blockquote>
5948<p><b>Proposed resolution:</b></p>
5949<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
5950<tt>"a-b"</tt> to <tt>"b-a".</tt></p>
5951<p><b>Rationale:</b></p>
5952<p>There are two ways to fix the defect; change the description to b-a
5953or change the return to distance(b,a).  The LWG preferred the
5954former for consistency.</p>
5955<hr>
5956<a name="211"><h3>211.&nbsp;operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Scott Snyder&nbsp; <b>Date:</b>&nbsp;4 Feb 2000</p>
5957<p>The description of the stream extraction operator for std::string (section
595821.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
5959the case that the operator fails to extract any characters from the input
5960stream.</p>
5961<p>This implies that the typical construction</p>
5962<blockquote>
5963  <pre>std::istream is;
5964std::string str;
5965...
5966while (is &gt;&gt; str) ... ;</pre>
5967</blockquote>
5968<p>(which tests failbit) is not required to terminate at EOF.</p>
5969<p>Furthermore, this is inconsistent with other extraction operators,
5970which 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
5971requirement is present, either explicitly or implicitly, for the
5972extraction operators. It is also present explicitly in the description
5973of getline (istream&amp;, string&amp;, 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>
5974<p><b>Proposed resolution:</b></p>
5975<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>
5976<blockquote>
5977
5978<p>If the function extracts no characters, it calls
5979is.setstate(ios::failbit) which may throw ios_base::failure
5980(27.4.4.3).</p>
5981</blockquote>
5982<hr>
5983<a name="212"><h3>212.&nbsp;Empty range behavior unclear for several algorithms</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;26 Feb 2000</p>
5984<p>The standard doesn't specify what min_element() and max_element() shall
5985return if the range is empty (first equals last). The usual implementations
5986return last. This problem seems also apply to partition(), stable_partition(),
5987next_permutation(), and prev_permutation().</p>
5988<p><b>Proposed resolution:</b></p>
5989<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
59909, append: Returns last if first==last.</p>
5991<p><b>Rationale:</b></p>
5992<p>The LWG looked in some detail at all of the above mentioned
5993algorithms, but believes that except for min_element() and
5994max_element() it is already clear that last is returned if first ==
5995last.</p>
5996<hr>
5997<a name="214"><h3>214.&nbsp;set::find() missing const overload</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;28 Feb 2000</p>
5998<p>The specification for the associative container requirements in
5999Table 69 state that the find member function should "return
6000iterator; const_iterator for constant a". The map and multimap
6001container descriptions have two overloaded versions of find, but set
6002and multiset do not, all they have is:</p>
6003<blockquote>
6004  <pre>iterator find(const key_type &amp; x) const;</pre>
6005</blockquote>
6006<p><b>Proposed resolution:</b></p>
6007<p>Change the prototypes for find(), lower_bound(), upper_bound(), and
6008equal_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>
6009<blockquote>
6010  <pre>iterator find(const key_type &amp; x);
6011const_iterator find(const key_type &amp; x) const;</pre>
6012  <pre>iterator lower_bound(const key_type &amp; x);
6013const_iterator lower_bound(const key_type &amp; x) const;</pre>
6014  <pre>iterator upper_bound(const key_type &amp; x);
6015const_iterator upper_bound(const key_type &amp; x) const;</pre>
6016  <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
6017pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
6018</blockquote>
6019
6020<p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
6021extending the proposed resolution to lower_bound, upper_bound, and
6022equal_range.]</i></p>
6023<hr>
6024<a name="217"><h3>217.&nbsp;Facets example (Classifying Japanese characters) contains errors</h3></a><p><b>Section:</b>&nbsp;22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;29 Feb 2000</p>
6025<p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
6026<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
6027must be const in order for it to be callable on a const object (a reference to
6028which which is what std::use_facet&lt;&gt;() returns).</p>
6029<p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
6030name of the namespace `My'.</p>
6031<p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
6032in main(), the name of the facet is misspelled: it should read `My::JCtype'
6033rather than `My::JCType'.</p>
6034<p><b>Proposed resolution:</b></p>
6035<p>Replace the "Classifying Japanese characters" example in 22.2.8,
6036paragraph 11 with the following:</p>
6037<pre>#include &lt;locale&gt;</pre>
6038<pre>namespace My {
6039    using namespace std;
6040    class JCtype : public locale::facet {
6041    public:
6042        static locale::id id;     //  required for use as a new locale facet
6043        bool is_kanji (wchar_t c) const;
6044        JCtype() {}
6045    protected:
6046        ~JCtype() {}
6047    };
6048}</pre>
6049<pre>//  file:  filt.C
6050#include &lt;iostream&gt;
6051#include &lt;locale&gt;
6052#include "jctype"                 //  above
6053std::locale::id My::JCtype::id;   //  the static  JCtype  member
6054declared above.</pre>
6055<pre>int main()
6056{
6057    using namespace std;
6058    typedef ctype&lt;wchar_t&gt; wctype;
6059    locale loc(locale(""),              //  the user's preferred locale...
6060               new My::JCtype);         //  and a new feature ...
6061    wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
6062    if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
6063        cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
6064    return 0;
6065}</pre>
6066<hr>
6067<a name="220"><h3>220.&nbsp;~ios_base() usage valid?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jonathan Schilling, Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2000</p>
6068<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
6069paragraph 2:</p>
6070<blockquote>
6071  <p>Effects: Destroys an object of class ios_base. Calls each registered
6072  callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
6073  time that any ios_base member function called from within fn has well defined
6074  results.</p>
6075</blockquote>
6076<p>But what is not clear is: If no callback functions were ever registered, does
6077it matter whether the ios_base members were ever initialized?</p>
6078<p>For instance, does this program have defined behavior:</p>
6079<blockquote>
6080  <pre>#include &lt;ios&gt;</pre>
6081  <pre>class D : public std::ios_base { };</pre>
6082  <pre>int main() { D d; }</pre>
6083</blockquote>
6084<p>It seems that registration of a callback function would surely affect the
6085state of an ios_base. That is, when you register a callback function with an
6086ios_base, the ios_base must record that fact somehow.</p>
6087<p>But if after construction the ios_base is in an indeterminate state, and that
6088state is not made determinate before the destructor is called, then how would
6089the destructor know if any callbacks had indeed been registered? And if the
6090number of callbacks that had been registered is indeterminate, then is not the
6091behavior of the destructor undefined?</p>
6092<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
6093it explicit that destruction before initialization results in undefined
6094behavior.</p>
6095<p><b>Proposed resolution:</b></p>
6096<p>Modify 27.4.2.7 paragraph 1 from</p>
6097<blockquote>
6098  <p>Effects: Each ios_base member has an indeterminate value after
6099  construction.</p>
6100</blockquote>
6101<p>to</p>
6102<blockquote>
6103  <p>Effects: Each ios_base member has an indeterminate
6104value after construction. These members must be initialized by calling
6105basic_ios::init. If an ios_base object is destroyed before these
6106initializations have taken place, the behavior is undefined.</p>
6107</blockquote>
6108<hr>
6109<a name="221"><h3>221.&nbsp;num_get&lt;&gt;::do_get stage 2 processing broken</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;14 Mar 2000</p>
6110<p>Stage 2 processing of numeric conversion is broken.</p>
6111
6112<p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
6113conversion specifier is %i. A %i specifier determines a number's base
6114by its prefix (0 for octal, 0x for hex), so the intention is clearly
6115that a 0x prefix is allowed.  Paragraph 8 in the same section,
6116however, describes very precisely how characters are processed. (It
6117must be done "as if" by a specified code fragment.) That
6118description does not allow a 0x prefix to be recognized.</p>
6119
6120<p>Very roughly, stage 2 processing reads a char_type ct. It converts
6121ct to a char, not by using narrow but by looking it up in a
6122translation table that was created by widening the string literal
6123"0123456789abcdefABCDEF+-". The character "x" is
6124not found in that table, so it can't be recognized by stage 2
6125processing.</p>
6126<p><b>Proposed resolution:</b></p>
6127<p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
6128<blockquote>
6129  <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
6130</blockquote>
6131<p>with the line:</p>
6132<blockquote>
6133  <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
6134</blockquote>
6135<p><b>Rationale:</b></p>
6136<p>If we're using the technique of widening a string literal, the
6137string literal must contain every character we wish to recognize.
6138This technique has the consequence that alternate representations
6139of digits will not be recognized.  This design decision was made
6140deliberately, with full knowledge of that limitation.</p>
6141<hr>
6142<a name="222"><h3>222.&nbsp;Are throw clauses necessary if a throw is already implied by the effects clause?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;17 Mar 2000</p>
6143<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
6144<blockquote>
6145  <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
6146
6147int compare(size_type pos1, size_type n1,
6148                const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
6149                size_type  pos2 , size_type  n2 ) const;
6150
6151-4- Returns:
6152
6153    basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
6154                 basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
6155</blockquote>
6156<p>and the constructor that's implicitly called by the above is
6157defined to throw an out-of-range exception if pos &gt; str.size(). See
6158section 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>
6159
6160<p>On the other hand, the compare function descriptions themselves don't have
6161"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
6162that do not apply to a function are omitted.</p>
6163<p>So it seems there is an inconsistency in the standard -- are the
6164"Effects" clauses correct, or are the "Throws" clauses
6165missing?</p>
6166<p><b>Proposed resolution:</b></p>
6167<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
6168the sentence "Descriptions of function semantics contain the
6169following elements (as appropriate):", insert the word
6170"further" so that the foot note reads:</p>
6171<blockquote>
6172  <p>To save space, items that do not apply to a function are
6173  omitted. For example, if a function does not specify any further
6174  preconditions, there will be no "Requires" paragraph.</p>
6175</blockquote>
6176<p><b>Rationale:</b></p>
6177<p>The standard is somewhat inconsistent, but a failure to note a
6178throw condition in a throws clause does not grant permission not to
6179throw.  The inconsistent wording is in a footnote, and thus
6180non-normative. The proposed resolution from the LWG clarifies the
6181footnote.</p>
6182<hr>
6183<a name="223"><h3>223.&nbsp;reverse algorithm should use iter_swap rather than swap</h3></a><p><b>Section:</b>&nbsp;25.2.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;21 Mar 2000</p>
6184<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
6185<p><b>Proposed resolution:</b></p>
6186<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>
6187  <blockquote>
6188  Effects: For each non-negative integer i &lt;= (last - first)/2,
6189  applies swap to all pairs of iterators first + i, (last - i) - 1.
6190  </blockquote>
6191<p>with:</p>
6192  <blockquote>
6193  Effects: For each non-negative integer i &lt;= (last - first)/2,
6194  applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
6195  </blockquote>
6196<hr>
6197<a name="224"></a><h3><a name="224">224.&nbsp;clear() complexity for associative containers refers to undefined N</a></h3><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;23 Mar 2000</p>
6198<p>In the associative container requirements table in 23.1.2 paragraph 7,
6199a.clear() has complexity "log(size()) + N". However, the meaning of N
6200is not defined.</p>
6201<p><b>Proposed resolution:</b></p>
6202<p>In the associative container requirements table in 23.1.2 paragraph
62037, the complexity of a.clear(), change "log(size()) + N" to
6204"linear in <tt>size()</tt>".</p>
6205<p><b>Rationale:</b></p>
6206<p>It's the "log(size())", not the "N", that is in
6207error: there's no difference between <i>O(N)</i> and <i>O(N +
6208log(N))</i>.  The text in the standard is probably an incorrect
6209cut-and-paste from the range version of <tt>erase</tt>.</p>
6210<hr>
6211<a name="225"><h3>225.&nbsp;std:: algorithms use of other unqualified algorithms</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
6212<p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
6213user namespaces might be found through Koenig lookup?</p>
6214<p>For example, a popular standard library implementation includes this
6215implementation of std::unique:</p>
6216<blockquote>
6217<pre>namespace std {
6218    template &lt;class _ForwardIter&gt;
6219    _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
6220      __first = adjacent_find(__first, __last);
6221      return unique_copy(__first, __last, __first);
6222    }
6223    }</pre>
6224</blockquote>
6225<p>Imagine two users on opposite sides of town, each using unique on his own
6226sequences bounded by my_iterators . User1 looks at his standard library
6227implementation and says, "I know how to implement a more efficient
6228unique_copy for my_iterators", and writes:</p>
6229<blockquote>
6230<pre>namespace user1 {
6231    class my_iterator;
6232    // faster version for my_iterator
6233    my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
6234    }</pre>
6235</blockquote>
6236<p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
6237<p>User2 has other needs, and writes:</p>
6238<blockquote>
6239<pre>namespace user2 {
6240    class my_iterator;
6241    // Returns true iff *c is a unique copy of *a and *b.
6242    bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
6243    }</pre>
6244</blockquote>
6245<p>User2 is shocked to find later that his fully-qualified use of
6246std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
6247compile (if he's lucky). Looking in the standard, he sees the following Effects
6248clause for unique():</p>
6249<blockquote>
6250  <p>Effects: Eliminates all but the first element from every consecutive group
6251  of equal elements referred to by the iterator i in the range [first, last) for
6252  which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
6253  *(i - 1)) != false</p>
6254</blockquote>
6255<p>The standard gives user2 absolutely no reason to think he can interfere with
6256std::unique by defining names in namespace user2. His standard library has been
6257built with the template export feature, so he is unable to inspect the
6258implementation. User1 eventually compiles his code with another compiler, and
6259his version of unique_copy silently stops being called. Eventually, he realizes
6260that he was depending on an implementation detail of his library and had no
6261right to expect his unique_copy() to be called portably.</p>
6262<p>On the face of it, and given above scenario, it may seem obvious that the
6263implementation of unique() shown is non-conforming because it uses unique_copy()
6264rather than ::std::unique_copy(). Most standard library implementations,
6265however, seem to disagree with this notion.</p>
6266<p> <i>[Tokyo:&nbsp; Steve Adamczyk from
6267the core working group indicates that "std::" is sufficient;&nbsp;
6268leading "::" qualification is not required because any namespace
6269qualification is sufficient to suppress Koenig lookup.]</i></p>
6270<p><b>Proposed resolution:</b></p>
6271<p>Add a paragraph and a note at the end of
627217.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>
6273<blockquote>
6274
6275<p>Unless otherwise specified, no global or non-member function in the
6276standard library shall use a function from another namespace which is
6277found 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>
6278
6279<p>[Note: the phrase "unless otherwise specified" is intended to
6280allow Koenig lookup in cases like that of ostream_iterators:<br>
6281
6282<br>
6283  Effects:</p>
6284  <blockquote>
6285<p>*out_stream &lt;&lt; value;<br>
6286      if(delim != 0) *out_stream &lt;&lt; delim;<br>
6287      return (*this);</p>
6288    <p>--end note]</p>
6289  </blockquote>
6290</blockquote>
6291
6292<p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
6293is as yet unsure if the proposed resolution is the best
6294solution. Furthermore, the LWG believes that the same problem of
6295unqualified library names applies to wording in the standard itself,
6296and has opened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> accordingly. Any resolution of
6297issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be coordinated with the resolution of
6298issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
6299
6300<p><i>[Toronto: The LWG is not sure if this is a defect in the
6301standard.  Most LWG members believe that an implementation of
6302<tt>std::unique</tt> like the one quoted in this issue is already
6303illegal, since, under certain circumstances, its semantics are not
6304those specified in the standard.  The standard's description of
6305<tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
6306should have any effect.]</i></p>
6307
6308<p><i>[Cura�ao: An LWG-subgroup spent an afternoon working on issues
6309225, 226, and 229.  Their conclusion was that the issues should be
6310separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6311EWG portion (Dave will write a proposal). The LWG and EWG had
6312(separate) discussions of this plan the next day.  The proposed
6313resolution for this issue is in accordance with Howard's paper.]</i></p>
6314
6315<p><b>Rationale:</b></p>
6316<p>It could be argued that this proposed isn't strictly necessary,
6317  that the Standard doesn't grant implementors license to write a
6318  standard function that behaves differently than specified in the
6319  Standard just because of an unrelated user-defined name in some
6320  other namespace.  However, this is at worst a clarification.  It is
6321  surely right that algorithsm shouldn't pick up random names, that
6322  user-defined names should have no effect unless otherwise specified.
6323  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
6324  appropriate for the standard to explicitly specify otherwise.</p>
6325<hr>
6326<a name="226"><h3>226.&nbsp;User supplied specializations or overloads of namespace std function templates</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
6327<p>The issues are:&nbsp;</p>
6328<p>1. How can a 3rd party library implementor (lib1) write a version of a standard
6329algorithm which is specialized to work with his own class template?&nbsp;</p>
6330<p>2. How can another library implementor (lib2) write a generic algorithm which
6331will take advantage of the specialized algorithm in lib1?</p>
6332<p>This appears to be the only viable answer under current language rules:</p>
6333<blockquote>
6334  <pre>namespace lib1
6335{
6336    // arbitrary-precision numbers using T as a basic unit
6337    template &lt;class T&gt;
6338    class big_num { //...
6339    };
6340    </pre>
6341  <pre>    // defining this in namespace std is illegal (it would be an
6342    // overload), so we hope users will rely on Koenig lookup
6343    template &lt;class T&gt;
6344    void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
6345}</pre>
6346  <pre>#include &lt;algorithm&gt;
6347namespace lib2
6348{
6349    template &lt;class T&gt;
6350    void generic_sort(T* start, T* end)
6351    {
6352            ...
6353        // using-declaration required so we can work on built-in types
6354        using std::swap;
6355        // use Koenig lookup to find specialized algorithm if available
6356        swap(*x, *y);
6357    }
6358}</pre>
6359</blockquote>
6360<p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
6361and somewhat slippery. The implementor needs to remember to write the
6362using-declaration, or generic_sort will fail to compile when T is a built-in
6363type. The second drawback is that the use of this style in lib2 effectively
6364"reserves" names in any namespace which defines types which may
6365eventually be used with lib2. This may seem innocuous at first when applied to
6366names like swap, but consider more ambiguous names like unique_copy() instead.
6367It is easy to imagine the user wanting to define these names differently in his
6368own namespace. A definition with semantics incompatible with the standard
6369library could cause serious problems (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>).</p>
6370<p>Why, you may ask, can't we just partially specialize std::swap()? It's
6371because the language doesn't allow for partial specialization of function
6372templates. If you write:</p>
6373<blockquote>
6374  <pre>namespace std
6375{
6376    template &lt;class T&gt;
6377    void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
6378}</pre>
6379</blockquote>
6380<p>You have just overloaded std::swap, which is illegal under the current
6381language rules. On the other hand, the following full specialization is legal:</p>
6382<blockquote>
6383  <pre>namespace std
6384{
6385    template &lt;&gt;
6386    void swap(lib1::other_type&amp;, lib1::other_type&amp;);
6387}</pre>
6388</blockquote>
6389
6390<p>This issue reflects concerns raised by the "Namespace issue
6391with specialized swap" thread on comp.lang.c++.moderated. A
6392similar set of concerns was earlier raised on the boost.org mailing
6393list and the ACCU-general mailing list.  Also see library reflector
6394message c++std-lib-7354.</p>
6395
6396<p>
6397J. C. van Winkel points out (in c++std-lib-9565) another unexpected
6398fact: it's impossible to output a container of std::pair's using copy
6399and an ostream_iterator, as long as both pair-members are built-in or
6400std:: types.  That's because a user-defined operator&lt;&lt; for (for
6401example) std::pair&lt;const std::string, int&gt; will not be found:
6402lookup for operator&lt;&lt; will be performed only in namespace std.
6403Opinions differed on whether or not this was a defect, and, if so,
6404whether the defect is that something is wrong with user-defined
6405functionality and std, or whether it's that the standard library does
6406not provide an operator&lt;&lt; for std::pair&lt;&gt;.
6407</p>
6408
6409<p><b>Proposed resolution:</b></p>
6410
6411<p>Adopt the wording proposed in Howard Hinnant's paper
6412  N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
6413
6414
6415<p><i>[Tokyo: Summary, "There is no conforming way to extend
6416std::swap for user defined templates."&nbsp; The LWG agrees that
6417there is a problem.  Would like more information before
6418proceeding. This may be a core issue.  Core issue 229 has been opened
6419to discuss the core aspects of this problem. It was also noted that
6420submissions regarding this issue have been received from several
6421sources, but too late to be integrated into the issues list.
6422]</i></p>
6423
6424<p><i>[Post-Tokyo: A paper with several proposed resolutions,
6425J16/00-0029==WG21/N1252, "Shades of namespace std functions
6426" by Alan Griffiths, is in the Post-Tokyo mailing. It
6427should be considered a part of this issue.]</i></p>
6428
6429<p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
6430resolution that involves core changes: it would add partial
6431specialization of function template.  The Core Working Group is
6432reluctant to add partial specialization of function templates.  It is
6433viewed as a large change, CWG believes that proposal presented leaves
6434some syntactic issues unanswered; if the CWG does add partial
6435specialization of function templates, it wishes to develop its own
6436proposal.  The LWG continues to believe that there is a serious
6437problem: there is no good way for users to force the library to use
6438user specializations of generic standard library functions, and in
6439certain cases (e.g. transcendental functions called by
6440<tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
6441lookup isn't adequate, since names within the library must be
6442qualified with <tt>std</tt> (see issue 225), specialization doesn't
6443work (we don't have partial specialization of function templates), and
6444users aren't permitted to add overloads within namespace std.
6445]</i></p>
6446
6447<p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
6448papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
6449focused on four options. (1) Relax restrictions on overloads within
6450namespace std. (2) Mandate that the standard library use unqualified
6451calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
6452helper class templates for <tt>swap</tt> and possibly other functions.
6453(4) Introduce partial specialization of function templates.  Every
6454option had both support and opposition.  Straw poll (first number is
6455support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
6456(4) 4, 4.]</i></p>
6457
6458<p><i>[Redmond: Discussed, again no consensus.  Herb presented an
6459argument that a user who is defining a type <tt>T</tt> with an
6460associated <tt>swap</tt> should not be expected to put that
6461<tt>swap</tt> in namespace std, either by overloading or by partial
6462specialization.  The argument is that <tt>swap</tt> is part of
6463<tt>T</tt>'s interface, and thus should to in the same namespace as
6464<tt>T</tt> and only in that namespace.  If we accept this argument,
6465the consequence is that standard library functions should use
6466unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
6467A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
6468try to put together a proposal before the next meeting.]</i></p>
6469
6470<p><i>[Cura�ao: An LWG-subgroup spent an afternoon working on issues
6471225, 226, and 229.  Their conclusion was that the issues should be
6472separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6473EWG portion (Dave will write a proposal). The LWG and EWG had
6474(separate) discussions of this plan the next day.  The proposed
6475resolution is the one proposed by Howard.]</i></p>
6476
6477<p><i>[Santa Cruz: the LWG agreed with the general direction of
6478  Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
6479  we say otherwise; this issue is about when we do say otherwise.)
6480  However, there were concerns about wording.  Howard will provide new
6481  wording.  Bill and Jeremy will review it.]</i></p>
6482
6483<p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
6484  proposed resolution.]</i></p>
6485
6486<p><b>Rationale:</b></p>
6487<p>Informally: introduce a Swappable concept, and specify that the
6488  value types of the iterators passed to certain standard algorithms
6489  (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
6490  to that concept.  The Swappable concept will make it clear that
6491  these algorithms use unqualified lookup for the calls
6492  to <tt>swap</tt>.  Also, in <font color="red">26.3.3.3</font> paragraph 1,
6493  state that the valarray transcendentals use unqualified lookup.</p>
6494<hr>
6495<a name="227"><h3>227.&nbsp;std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p><b>Section:</b>&nbsp;25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;09 Apr 2000</p>
6496<p>25.2.2 reads:</p>
6497<blockquote>
6498  <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
6499  <br>
6500  Requires:    Type T is Assignable (_lib.container.requirements_).<br>
6501  Effects:    Exchanges values stored in two locations.</p>
6502</blockquote>
6503<p>The only reasonable** generic implementation of swap requires construction of a
6504   new temporary copy of one of its arguments:</p>
6505<blockquote>
6506<pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6507  {
6508      T tmp(a);
6509      a = b;
6510      b = tmp;
6511  }</pre>
6512</blockquote>
6513<p>But a type which is only Assignable cannot be swapped by this implementation.</p>
6514<p>**Yes, there's also an unreasonable implementation which would require T to be
6515   DefaultConstructible instead of CopyConstructible. I don't think this is worthy
6516   of consideration:</p>
6517<blockquote>
6518<pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6519{
6520    T tmp;
6521    tmp = a;
6522    a = b;
6523    b = tmp;
6524}</pre>
6525</blockquote>
6526<p><b>Proposed resolution:</b></p>
6527<p>Change 25.2.2 paragraph 1 from:</p>
6528<blockquote>
6529<p>  Requires: Type T is Assignable (23.1).</p>
6530</blockquote>
6531<p>to:</p>
6532<blockquote>
6533<p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
6534</blockquote>
6535<hr>
6536<a name="228"><h3>228.&nbsp;Incorrect specification of "..._byname" facets</h3></a><p><b>Section:</b>&nbsp;22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;20 Apr 2000</p>
6537<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.codecvt"> [lib.locale.codecvt]</a>,
6538<font color="red">22.2.1.6</font>, 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
6539definitions of the "..._byname" classes by listing a bunch
6540of virtual functions. At the same time, no semantics of these
6541functions are defined. Real implementations do not define these
6542functions because the functional part of the facets is actually
6543implemented in the corresponding base classes and the constructor of
6544the "..._byname" version just provides suitable date used by
6545these implementations. For example, the 'numpunct' methods just return
6546values from a struct. The base class uses a statically initialized
6547struct while the derived version reads the contents of this struct
6548from a table.  However, no virtual function is defined in
6549'numpunct_byname'.</p>
6550
6551<p>For most classes this does not impose a problem but specifically
6552for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
6553is required because otherwise the semantics would change due to the
6554virtual functions defined in the general version for 'ctype_byname':
6555In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
6556made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
6557Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
6558this class is specialized or not under the current specification:
6559Without the specialization, 'do_is()' is virtual while with
6560specialization it is not virtual.</p>
6561<p><b>Proposed resolution:</b></p>
6562<p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
6563<pre>     namespace std {
6564       template &lt;class charT&gt;
6565       class ctype_byname : public ctype&lt;charT&gt; {
6566       public:
6567         typedef ctype&lt;charT&gt;::mask mask;
6568         explicit ctype_byname(const char*, size_t refs = 0);
6569       protected:
6570        ~ctype_byname();             //  virtual
6571       };
6572     }</pre>
6573<p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
6574<pre>    namespace std {
6575      template &lt;class internT, class externT, class stateT&gt;
6576      class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
6577      public:
6578       explicit codecvt_byname(const char*, size_t refs = 0);
6579      protected:
6580      ~codecvt_byname();             //  virtual
6581       };
6582     }
6583</pre>
6584<p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
6585<pre>     namespace std {
6586       template &lt;class charT&gt;
6587       class numpunct_byname : public numpunct&lt;charT&gt; {
6588     //  this class is specialized for  char  and  wchar_t.
6589       public:
6590         typedef charT                char_type;
6591         typedef basic_string&lt;charT&gt;  string_type;
6592         explicit numpunct_byname(const char*, size_t refs = 0);
6593       protected:
6594        ~numpunct_byname();          //  virtual
6595       };
6596     }</pre>
6597<p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
6598<pre>     namespace std {
6599       template &lt;class charT&gt;
6600       class collate_byname : public collate&lt;charT&gt; {
6601       public:
6602         typedef basic_string&lt;charT&gt; string_type;
6603         explicit collate_byname(const char*, size_t refs = 0);
6604       protected:
6605        ~collate_byname();           //  virtual
6606       };
6607     }</pre>
6608<p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
6609<pre>     namespace std {
6610       template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
6611       class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
6612       public:
6613         typedef time_base::dateorder dateorder;
6614         typedef InputIterator        iter_type</pre>
6615<pre>         explicit time_get_byname(const char*, size_t refs = 0);
6616       protected:
6617        ~time_get_byname();          //  virtual
6618       };
6619     }</pre>
6620<p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
6621<pre>     namespace std {
6622       template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
6623       class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
6624       {
6625       public:
6626         typedef charT          char_type;
6627         typedef OutputIterator iter_type;</pre>
6628<pre>         explicit time_put_byname(const char*, size_t refs = 0);
6629       protected:
6630        ~time_put_byname();          //  virtual
6631       };
6632     }"</pre>
6633<p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
6634<pre>     namespace std {
6635       template &lt;class charT, bool Intl = false&gt;
6636       class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
6637       public:
6638         typedef money_base::pattern pattern;
6639         typedef basic_string&lt;charT&gt; string_type;</pre>
6640<pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
6641       protected:
6642        ~moneypunct_byname();        //  virtual
6643       };
6644     }</pre>
6645<p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
6646<pre>     namespace std {
6647       template &lt;class charT&gt;
6648       class messages_byname : public messages&lt;charT&gt; {
6649       public:
6650         typedef messages_base::catalog catalog;
6651         typedef basic_string&lt;charT&gt;    string_type;</pre>
6652<pre>         explicit messages_byname(const char*, size_t refs = 0);
6653       protected:
6654        ~messages_byname();          //  virtual
6655       };
6656     }</pre>
6657<p>Remove section 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> completely (because in
6658this case only those members are defined to be virtual which are
6659defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
6660
6661<p><i>[Post-Tokyo: Dietmar K�hl submitted this issue at the request of
6662the 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>
6663
6664<p><i>[Copenhagen: proposed resolution was revised slightly, to remove
6665three last virtual functions from <tt>messages_byname</tt>.]</i></p>
6666
6667<hr>
6668<a name="229"><h3>229.&nbsp;Unqualified references of other library entities</h3></a><p><b>Section:</b>&nbsp;17.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;19 Apr 2000</p>
6669<p>Throughout the library chapters, the descriptions of library entities refer
6670to other library entities without necessarily qualifying the names.</p>
6671
6672<p>For example, section 25.2.2 "Swap" describes the effect of
6673swap_ranges in terms of the unqualified name "swap". This section
6674could reasonably be interpreted to mean that the library must be implemented so
6675as to do a lookup of the unqualified name "swap", allowing users to
6676override any ::std::swap function when Koenig lookup applies.</p>
6677
6678<p>Although it would have been best to use explicit qualification with
6679"::std::" throughout, too many lines in the standard would have to be
6680adjusted to make that change in a Technical Corrigendum.</p>
6681
6682<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
6683<tt>size_t</tt>, is a special case of this.
6684</p>
6685<p><b>Proposed resolution:</b></p>
6686<p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
6687<blockquote>
6688  <p>Whenever a name x defined in the standard library is mentioned, the name x
6689  is assumed to be fully qualified as ::std::x, unless explicitly described
6690  otherwise. For example, if the Effects section for library function F is
6691  described as calling library function G, the function ::std::G is meant.</p>
6692</blockquote>
6693
6694<p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
6695the LWG to solve a problem in the standard itself similar to the
6696problem 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
6697coordinated with the resolution of this issue.]</i></p>
6698
6699<p><i>[post-Toronto: Howard is undecided about whether it is
6700appropriate for all standard library function names referred to in
6701other standard library functions to be explicitly qualified by
6702<tt>std</tt>: it is common advice that users should define global
6703functions that operate on their class in the same namespace as the
6704class, and this requires argument-dependent lookup if those functions
6705are intended to be called by library code.  Several LWG members are
6706concerned that valarray appears to require argument-dependent lookup,
6707but that the wording may not be clear enough to fall under
6708"unless explicitly described otherwise".]</i></p>
6709
6710<p><i>[Cura�ao: An LWG-subgroup spent an afternoon working on issues
6711225, 226, and 229.  Their conclusion was that the issues should be
6712separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6713EWG portion (Dave will write a proposal). The LWG and EWG had
6714(separate) discussions of this plan the next day.  This paper resolves
6715issues 225 and 226.  In light of that resolution, the proposed
6716resolution for the current issue makes sense.]</i></p>
6717
6718<hr>
6719<a name="230"><h3>230.&nbsp;Assignable specified without also specifying CopyConstructible</h3></a><p><b>Section:</b>&nbsp;17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;26 Apr 2000</p>
6720<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
6721Assignable was specified without also specifying
6722CopyConstructible. The LWG asked that the standard be searched to
6723determine if the same defect existed elsewhere.</p>
6724
6725<p>There are a number of places (see proposed resolution below) where
6726Assignable is specified without also specifying
6727CopyConstructible. There are also several cases where both are
6728specified. For example, 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.req"> [lib.rand.req]</a>.</p>
6729<p><b>Proposed resolution:</b></p>
6730<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:
6731change "T is Assignable" to "T is CopyConstructible and
6732Assignable"
6733</p>
6734
6735<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
6736"Key is Assignable" to "Key is
6737CopyConstructible and Assignable"<br>
6738</p>
6739
6740<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:
6741</p>
6742<blockquote>
6743<p> A class or a built-in type X satisfies the requirements of an
6744output iterator if X is an Assignable type (23.1) and also the
6745following expressions are valid, as shown in Table 73:
6746</p>
6747</blockquote>
6748<p>to:
6749</p>
6750<blockquote>
6751<p> A class or a built-in type X satisfies the requirements of an
6752output iterator if X is a CopyConstructible (20.1.3) and Assignable
6753type (23.1) and also the following expressions are valid, as shown in
6754Table 73:
6755</p>
6756</blockquote>
6757
6758<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
6759the 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
6760CopyConstructible is really a requirement and may be
6761overspecification.]</i></p>
6762
6763<p><i>[Portions of the resolution for issue 230 have been superceded by
6764the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
6765
6766<p><b>Rationale:</b></p>
6767<p>The original proposed resolution also included changes to input
6768iterator, fill, and replace.  The LWG believes that those changes are
6769not necessary.  The LWG considered some blanket statement, where an
6770Assignable type was also required to be Copy Constructible, but
6771decided against this because fill and replace really don't require the
6772Copy Constructible property.</p>
6773<hr>
6774<a name="231"><h3>231.&nbsp;Precision in iostream?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
6775<p>What is the following program supposed to output?</p>
6776<pre>#include &lt;iostream&gt;
6777
6778    int
6779    main()
6780    {
6781        std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
6782        std::cout.precision( 0 ) ;
6783        std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
6784        return 0 ;
6785    }</pre>
6786<p>From my C experience, I would expect "1e+00"; this is what
6787<tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
6788"1.000000e+00".</p>
6789
6790<p>The only indication I can find in the standard is 22.2.2.2.2/11,
6791where it says "For conversion from a floating-point type, if
6792(flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
6793str.precision() is specified in the conversion specification."
6794This is an obvious error, however, fixed is not a mask for a field,
6795but a value that a multi-bit field may take -- the results of and'ing
6796fmtflags with ios::fixed are not defined, at least not if
6797ios::scientific has been set. G++'s behavior corresponds to what might
6798happen if you do use (flags &amp; fixed) != 0 with a typical
6799implementation (floatfield == 3 &lt;&lt; something, fixed == 1
6800&lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
6801
6802<p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
6803(flags &amp; floatfield) == fixed; the first gives something more or
6804less like the effect of precision in a printf floating point
6805conversion. Only more or less, of course. In order to implement printf
6806formatting correctly, you must know whether the precision was
6807explicitly set or not. Say by initializing it to -1, instead of 6, and
6808stating that for floating point conversions, if precision &lt; -1, 6
6809will be used, for fixed point, if precision &lt; -1, 1 will be used,
6810etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
68110, 1 should be = used. But it probably isn't necessary to emulate all
6812of the anomalies of printf:-).</p>
6813<p><b>Proposed resolution:</b></p>
6814<p>
6815Replace 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
6816sentence:
6817</p>
6818<blockquote>
6819For conversion from a floating-point type,
6820<tt><i>str</i>.precision()</tt> is specified in the conversion
6821specification.
6822</blockquote>
6823<p><b>Rationale:</b></p>
6824<p>The floatfield determines whether numbers are formatted as if
6825with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
6826if <tt>scientific</tt> it's %e, and if both bits are set, or
6827neither, it's %g.</p>
6828<p>Turning to the C standard, a precision of 0 is meaningful
6829for %f and %e.  For %g, precision 0 is taken to be the same as
6830precision 1.</p>
6831<p>The proposed resolution has the effect that if neither
6832<tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
6833specifying a precision of 0, which will be internally
6834turned into 1.  There's no need to call it out as a special
6835case.</p>
6836<p>The output of the above program will be "1e+00".</p>
6837
6838<p><i>[Post-Cura�ao: Howard provided improved wording covering the case
6839where precision is 0 and mode is %g.]</i></p>
6840
6841<hr>
6842<a name="232"><h3>232.&nbsp;"depends" poorly defined in 17.4.3.1</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;18 Apr 2000</p>
6843<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
6844specializations of standard templates to those that "depend on a
6845user-defined name of external linkage."</p>
6846<p>This term, however, is not adequately defined, making it possible to
6847construct a specialization that is, I believe, technically legal according to
684817.4.3.1/1, but that specializes a standard template for a built-in type such as
6849'int'.</p>
6850<p>The following code demonstrates the problem:</p>
6851<blockquote>
6852  <pre>#include &lt;algorithm&gt;</pre>
6853  <pre>template&lt;class T&gt; struct X
6854{
6855 typedef T type;
6856};</pre>
6857  <pre>namespace std
6858{
6859 template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
6860}</pre>
6861</blockquote>
6862<p><b>Proposed resolution:</b></p>
6863<p>Change "user-defined name" to "user-defined
6864type".</p>
6865<p><b>Rationale:</b></p>
6866<p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
6867Programming Language</i>.  It disallows the example in the issue,
6868since the underlying type itself is not user-defined.  The only
6869possible problem I can see is for non-type templates, but there's no
6870possible way for a user to come up with a specialization for bitset,
6871for example, that might not have already been specialized by the
6872implementor?</p>
6873
6874<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>
6875
6876<p><i>[post-Toronto: Judy provided the above proposed resolution and
6877rationale.]</i></p>
6878<hr>
6879<a name="234"><h3>234.&nbsp;Typos in allocator definition</h3></a><p><b>Section:</b>&nbsp;20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6880<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
6881<tt>destruct()</tt> are described as returns but the functions actually
6882return <tt>void</tt>.</p>
6883<p><b>Proposed resolution:</b></p>
6884<p>Substitute "Returns" by "Effect".</p>
6885<hr>
6886<a name="235"><h3>235.&nbsp;No specification of default ctor for reverse_iterator</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6887<p>The declaration of <tt>reverse_iterator</tt> lists a default
6888constructor.  However, no specification is given what this constructor
6889should do.</p>
6890<p><b>Proposed resolution:</b></p>
6891  <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
6892  paragraph:</p>
6893      <blockquote>
6894      <p><tt>reverse_iterator()</tt></p>
6895
6896      <p>Default initializes <tt>current</tt>. Iterator operations
6897      applied to the resulting iterator have defined behavior if and
6898      only if the corresponding operations are defined on a default
6899      constructed iterator of type <tt>Iterator</tt>.</p>
6900      </blockquote>
6901  <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
6902  resolution.]</i></p>
6903<hr>
6904<a name="237"><h3>237.&nbsp;Undefined expression in complexity specification</h3></a><p><b>Section:</b>&nbsp;23.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6905<p>The complexity specification in paragraph 6 says that the complexity
6906is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
6907defined on iterators this term is in general undefined because it
6908would have to be <tt>last - first</tt>.</p>
6909<p><b>Proposed resolution:</b></p>
6910  <p>Change paragraph 6 from</p>
6911     <blockquote>Linear in <i>first - last</i>.</blockquote>
6912  <p>to become</p>
6913     <blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
6914<hr>
6915<a name="238"><h3>238.&nbsp;Contradictory results of stringbuf initialization.</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar K�hl&nbsp; <b>Date:</b>&nbsp;11 May 2000</p>
6916<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
6917'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
6918that far but consider this code:</p>
6919
6920<pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
6921  std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
6922</pre>
6923
6924<p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
6925the output sequence nor the input sequence is initialized and
6926paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
6927returns the input or the output sequence. None of them is initialized,
6928ie. both are empty, in which case the return from <tt>str()</tt> is
6929defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
6930
6931<p>However, probably only test cases in some testsuites will detect this
6932"problem"...</p>
6933<p><b>Proposed resolution:</b></p>
6934<p>Remove 27.7.1.1 paragraph 4.</p>
6935<p><b>Rationale:</b></p>
6936<p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
6937we fixed it, it would say just the same thing as text that's already
6938in the standard.</p>
6939<hr>
6940<a name="239"><h3>239.&nbsp;Complexity of unique() and/or unique_copy incorrect</h3></a><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6941<p>The complexity of unique and unique_copy are inconsistent with each
6942other and inconsistent with the implementations.&nbsp; The standard
6943specifies:</p>
6944
6945<p>for unique():</p>
6946
6947<blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
6948(last - first) - 1 applications of the corresponding predicate, otherwise
6949no applications of the predicate.</blockquote>
6950
6951<p>for unique_copy():</p>
6952
6953<blockquote>-7- Complexity: Exactly last - first applications of the corresponding
6954predicate.</blockquote>
6955
6956<p>
6957The implementations do it the other way round: unique() applies the
6958predicate last-first times and unique_copy() applies it last-first-1
6959times.</p>
6960
6961<p>As both algorithms use the predicate for pair-wise comparison of
6962sequence elements I don't see a justification for unique_copy()
6963applying the predicate last-first times, especially since it is not
6964specified to which pair in the sequence the predicate is applied
6965twice.</p>
6966<p><b>Proposed resolution:</b></p>
6967<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>
6968
6969<blockquote>Complexity: For nonempty ranges, exactly last - first - 1
6970applications of the corresponding predicate.</blockquote>
6971
6972<hr>
6973<a name="240"><h3>240.&nbsp;Complexity of adjacent_find() is meaningless</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6974<p>The complexity section of adjacent_find is defective:</p>
6975
6976<blockquote>
6977<pre>template &lt;class ForwardIterator&gt;
6978ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
6979                              BinaryPredicate pred);
6980</pre>
6981
6982<p>-1- Returns: The first iterator i such that both i and i + 1 are in
6983the range [first, last) for which the following corresponding
6984conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
6985last if no such iterator is found.</p>
6986
6987<p>-2- Complexity: Exactly find(first, last, value) - first applications
6988of the corresponding predicate.
6989</p>
6990</blockquote>
6991
6992<p>In the Complexity section, it is not defined what "value"
6993is supposed to mean. My best guess is that "value" means an
6994object for which one of the conditions pred(*i,value) or
6995pred(value,*i) is true, where i is the iterator defined in the Returns
6996section. However, the value type of the input sequence need not be
6997equality-comparable and for this reason the term find(first, last,
6998value) - first is meaningless.</p>
6999
7000<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
7001find_if(first, last, bind1st(pred,*i)) - first might come closer to
7002the intended specification.  Binders can only be applied to function
7003objects that have the function call operator declared const, which is
7004not required of predicates because they can have non-const data
7005members. For this reason, a specification using a binder could only be
7006an "as-if" specification.</p>
7007<p><b>Proposed resolution:</b></p>
7008<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>
7009<blockquote>
7010For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
7011(<i>last</i> - <i>first</i>) - 1)</tt> applications of the
7012corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
7013return value.
7014</blockquote>
7015
7016<p><i>[Copenhagen: the original resolution specified an upper
7017bound.  The LWG preferred an exact count.]</i></p>
7018
7019<hr>
7020<a name="241"><h3>241.&nbsp;Does unique_copy() require CopyConstructible and Assignable?</h3></a><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
7021
7022<p>Some popular implementations of unique_copy() create temporary
7023copies of values in the input sequence, at least if the input iterator
7024is a pointer.  Such an implementation is built on the assumption that
7025the value type is CopyConstructible and Assignable.</p>
7026
7027<p>It is common practice in the standard that algorithms explicitly
7028specify any additional requirements that they impose on any of the
7029types used by the algorithm. An example of an algorithm that creates
7030temporary copies and correctly specifies the additional requirements
7031is accumulate(), 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.req"> [lib.rand.req]</a>.</p>
7032
7033<p>Since the specifications of unique() and unique_copy() do not
7034require CopyConstructible and Assignable of the InputIterator's value
7035type the above mentioned implementations are not standard-compliant. I
7036cannot judge whether this is a defect in the standard or a defect in
7037the implementations.</p>
7038<p><b>Proposed resolution:</b></p>
7039<p>In 25.2.8 change:</p>
7040
7041<blockquote>
7042-4- Requires: The ranges [first, last) and [result, result+(last-first))
7043shall not overlap.
7044</blockquote>
7045
7046<p>to:</p>
7047
7048<blockquote>
7049  <p>-4- Requires: The ranges [first, last) and [result,
7050  result+(last-first)) shall not overlap. The expression *result =
7051  *first must be valid. If neither InputIterator nor OutputIterator
7052  meets the requirements of forward iterator then the value type of
7053  InputIterator must be copy constructible. Otherwise copy
7054  constructible is not required. </p>
7055</blockquote>
7056
7057<p><i>[Redmond: the original proposed resolution didn't impose an
7058explicit requirement that the iterator's value type must be copy
7059constructible, on the grounds that an input iterator's value type must
7060always be copy constructible.  Not everyone in the LWG thought that
7061this requirement was clear from table 72.  It has been suggested that
7062it might be possible to implement <tt>unique_copy</tt> without
7063requiring assignability, although current implementations do impose
7064that requirement.  Howard provided new wording.]</i></p>
7065
7066<p><i>[
7067Cura�ao: The LWG changed the PR editorially to specify
7068"neither...nor...meet..." as clearer than
7069"both...and...do not meet...". Change believed to be so
7070minor as not to require re-review.
7071]</i></p>
7072
7073<hr>
7074<a name="242"><h3>242.&nbsp;Side effects of function objects</h3></a><p><b>Section:</b>&nbsp;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.rand"> [lib.rand]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
7075<p>The algorithms transform(), accumulate(), inner_product(),
7076partial_sum(), and adjacent_difference() require that the function
7077object supplied to them shall not have any side effects.</p>
7078
7079<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>
7080<blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
7081modifying an object, calling a library I/O function, or calling a function
7082that does any of those operations are all side effects, which are changes
7083in the state of the execution environment.</blockquote>
7084
7085<p>As a consequence, the function call operator of a function object supplied
7086to any of the algorithms listed above cannot modify data members, cannot
7087invoke any function that has a side effect, and cannot even create and
7088modify temporary objects.&nbsp; It is difficult to imagine a function object
7089that is still useful under these severe limitations. For instance, any
7090non-trivial transformator supplied to transform() might involve creation
7091and modification of temporaries, which is prohibited according to the current
7092wording of the standard.</p>
7093
7094<p>On the other hand, popular implementations of these algorithms exhibit
7095uniform and predictable behavior when invoked with a side-effect-producing
7096function objects. It looks like the strong requirement is not needed for
7097efficient implementation of these algorithms.</p>
7098
7099<p>The requirement of&nbsp; side-effect-free function objects could be
7100replaced by a more relaxed basic requirement (which would hold for all
7101function objects supplied to any algorithm in the standard library):</p>
7102<blockquote>A function objects supplied to an algorithm shall not invalidate
7103any iterator or sequence that is used by the algorithm. Invalidation of
7104the sequence includes destruction of the sorting order if the algorithm
7105relies on the sorting order (see section 25.3 - Sorting and related operations
7106[lib.alg.sorting]).</blockquote>
7107
7108<p>I can't judge whether it is intended that the function objects supplied
7109to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
7110shall not modify sequence elements through dereferenced iterators.</p>
7111
7112<p>It is debatable whether this issue is a defect or a change request.
7113Since the consequences for user-supplied function objects are drastic and
7114limit the usefulness of the algorithms significantly I would consider it
7115a defect.</p>
7116<p><b>Proposed resolution:</b></p>
7117
7118<p><i>Things to notice about these changes:</i></p>
7119
7120<ol>
7121<li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
7122     are intentional. we want to prevent side-effects from
7123     invalidating the end iterators.</i>
7124</li>
7125
7126<li> <i>That has the unintentional side-effect of prohibiting
7127     modification of the end element as a side-effect. This could
7128     conceivably be significant in some cases.</i>
7129</li>
7130
7131<li> <i>The wording also prevents side-effects from modifying elements
7132     of the output sequence. I can't imagine why anyone would want
7133     to do this, but it is arguably a restriction that implementors
7134     don't need to place on users.</i>
7135</li>
7136
7137<li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
7138     and simple, but would require more verbiage.</i>
7139</li>
7140</ol>
7141
7142<p>Change 25.2.3/2 from:</p>
7143
7144<blockquote>
7145   -2- Requires: op and binary_op shall not have any side effects.
7146</blockquote>
7147
7148<p>to:</p>
7149
7150<blockquote>
7151  -2- Requires: in the ranges [first1, last1], [first2, first2 +
7152  (last1 - first1)] and [result, result + (last1- first1)], op and
7153  binary_op shall neither modify elements nor invalidate iterators or
7154  subranges.
7155  [Footnote: The use of fully closed ranges is intentional --end footnote]
7156</blockquote>
7157
7158
7159<p>Change 25.2.3/2 from:</p>
7160
7161<blockquote>
7162   -2- Requires: op and binary_op shall not have any side effects.
7163</blockquote>
7164
7165<p>to:</p>
7166
7167<blockquote>
7168  -2- Requires: op and binary_op shall not invalidate iterators or
7169   subranges, or modify elements in the ranges [first1, last1],
7170   [first2, first2 + (last1 - first1)], and [result, result + (last1
7171   - first1)].
7172  [Footnote: The use of fully closed ranges is intentional --end footnote]
7173</blockquote>
7174
7175
7176<p>Change 26.4.1/2 from:</p>
7177
7178<blockquote>
7179  -2- Requires: T must meet the requirements of CopyConstructible
7180   (lib.copyconstructible) and Assignable (lib.container.requirements)
7181   types. binary_op shall not cause side effects.
7182</blockquote>
7183
7184<p>to:</p>
7185
7186<blockquote>
7187  -2- Requires: T must meet the requirements of CopyConstructible
7188   (lib.copyconstructible) and Assignable
7189   (lib.container.requirements) types. In the range [first, last],
7190   binary_op shall neither modify elements nor invalidate iterators
7191   or subranges.
7192  [Footnote: The use of a fully closed range is intentional --end footnote]
7193</blockquote>
7194
7195<p>Change 26.4.2/2 from:</p>
7196
7197<blockquote>
7198  -2- Requires: T must meet the requirements of CopyConstructible
7199   (lib.copyconstructible) and Assignable (lib.container.requirements)
7200   types. binary_op1 and binary_op2 shall not cause side effects.
7201</blockquote>
7202
7203<p>to:</p>
7204
7205<blockquote>
7206  -2- Requires: T must meet the requirements of CopyConstructible
7207   (lib.copyconstructible) and Assignable (lib.container.requirements)
7208   types. In the ranges [first, last] and [first2, first2 + (last -
7209   first)], binary_op1 and binary_op2 shall neither modify elements
7210   nor invalidate iterators or subranges.
7211  [Footnote: The use of fully closed ranges is intentional --end footnote]
7212</blockquote>
7213
7214
7215<p>Change 26.4.3/4 from:</p>
7216
7217<blockquote>
7218  -4- Requires: binary_op is expected not to have any side effects.
7219</blockquote>
7220
7221<p>to:</p>
7222
7223<blockquote>
7224  -4- Requires: In the ranges [first, last] and [result, result +
7225   (last - first)], binary_op shall neither modify elements nor
7226   invalidate iterators or subranges.
7227  [Footnote: The use of fully closed ranges is intentional --end footnote]
7228</blockquote>
7229
7230<p>Change 26.4.4/2 from:</p>
7231
7232<blockquote>
7233  -2- Requires: binary_op shall not have any side effects.
7234</blockquote>
7235
7236<p>to:</p>
7237
7238<blockquote>
7239  -2- Requires: In the ranges [first, last] and [result, result +
7240   (last - first)], binary_op shall neither modify elements nor
7241   invalidate iterators or subranges.
7242  [Footnote: The use of fully closed ranges is intentional --end footnote]
7243</blockquote>
7244
7245<p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
7246
7247<p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
7248added footnotes pointing out that the use of closed ranges was
7249intentional.]</i></p>
7250
7251<hr>
7252<a name="243"><h3>243.&nbsp;<tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
7253<p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
7254are unclear with respect to the behavior and side-effects of the named
7255functions in case of an error.</p>
7256
7257<p>27.6.1.3, p1 states that "... If the sentry object returns
7258true, when converted to a value of type bool, the function endeavors
7259to obtain the requested input..." It is not clear from this (or
7260the rest of the paragraph) what precisely the behavior should be when
7261the sentry ctor exits by throwing an exception or when the sentry
7262object returns false.  In particular, what is the number of characters
7263extracted that gcount() returns supposed to be?</p>
7264
7265<p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
7266"...  In any case, it then stores a null character (using
7267charT()) into the next successive location of the array." Is not
7268clear whether this sentence applies if either of the conditions above
7269holds (i.e., when sentry fails).</p>
7270<p><b>Proposed resolution:</b></p>
7271<p>Add to 27.6.1.3, p1 after the sentence</p>
7272
7273<blockquote>
7274"... If the sentry object returns true, when converted to a value of
7275type bool, the function endeavors to obtain the requested input."
7276</blockquote>
7277
7278<p>the following</p>
7279
7280
7281<blockquote>
7282"Otherwise, if the sentry constructor exits by throwing an exception or
7283if the sentry object returns false, when converted to a value of type
7284bool, the function returns without attempting to obtain any input. In
7285either case the number of extracted characters is set to 0; unformatted
7286input functions taking a character array of non-zero size as an argument
7287shall also store a null character (using charT()) in the first location
7288of the array."
7289</blockquote>
7290<p><b>Rationale:</b></p>
7291<p>Although the general philosophy of the input functions is that the
7292argument should not be modified upon failure, <tt>getline</tt>
7293historically added a terminating null unconditionally.  Most
7294implementations still do that.  Earlier versions of the draft standard
7295had language that made this an unambiguous requirement; those words
7296were moved to a place where their context made them less clear.  See
7297Jerry Schwarz's message c++std-lib-7618.</p>
7298<hr>
7299<a name="247"><h3>247.&nbsp;<tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
7300<p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity
7301of <tt>vector::insert</tt>:</p>
7302
7303   <blockquote>
7304   Complexity: If first and last are forward iterators, bidirectional
7305   iterators, or random access iterators, the complexity is linear in
7306   the number of elements in the range [first, last) plus the distance
7307   to the end of the vector. If they are input iterators, the complexity
7308   is proportional to the number of elements in the range [first, last)
7309   times the distance to the end of the vector.
7310   </blockquote>
7311
7312<p>First, this fails to address the non-iterator forms of
7313<tt>insert</tt>.</p>
7314
7315<p>Second, the complexity for input iterators misses an edge case --
7316it requires that an arbitrary number of elements can be added at
7317the end of a <tt>vector</tt> in constant time.</p>
7318
7319<p>I looked to see if <tt>deque</tt> had a similar problem, and was
7320surprised to find that <tt>deque</tt> places no requirement on the
7321complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array.size"> [lib.array.size]</a>,
7322paragraph 3):</p>
7323
7324   <blockquote>
7325   Complexity: In the worst case, inserting a single element into a
7326   deque takes time linear in the minimum of the distance from the
7327   insertion point to the beginning of the deque and the distance
7328   from the insertion point to the end of the deque. Inserting a
7329   single element either at the beginning or end of a deque always
7330   takes constant time and causes a single call to the copy constructor
7331   of T.
7332   </blockquote>
7333<p><b>Proposed resolution:</b></p>
7334
7335<p>Change Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] to</p>
7336   <blockquote>
7337   Complexity: The complexity is linear in the number of elements
7338   inserted plus the distance to the end of the vector.
7339   </blockquote>
7340
7341   <p><i>[For input iterators, one may achieve this complexity by first
7342   inserting at the end of the <tt>vector</tt>, and then using
7343   <tt>rotate</tt>.]</i></p>
7344
7345<p>Change 23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array.size"> [lib.array.size]</a>, paragraph 3, to:</p>
7346
7347   <blockquote>
7348   Complexity: The complexity is linear in the number of elements
7349   inserted plus the shorter of the distances to the beginning and
7350   end of the deque.  Inserting a single element at either the
7351   beginning or the end of a deque causes a single call to the copy
7352   constructor of T.
7353   </blockquote>
7354
7355<p><b>Rationale:</b></p>
7356<p>This is a real defect, and proposed resolution fixes it: some
7357  complexities aren't specified that should be.  This proposed
7358  resolution does constrain deque implementations (it rules out the
7359  most naive possible implementations), but the LWG doesn't see a
7360  reason to permit that implementation.</p>
7361<hr>
7362<a name="248"><h3>248.&nbsp;time_get fails to set eofbit</h3></a><p><b>Section:</b>&nbsp;22.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.time"> [lib.category.time]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;22 June 2000</p>
7363<p>There is no requirement that any of time_get member functions set
7364ios::eofbit when they reach the end iterator while parsing their input.
7365Since members of both the num_get and money_get facets are required to
7366do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
7367should follow the same requirement for consistency.</p>
7368<p><b>Proposed resolution:</b></p>
7369<p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
7370
7371<blockquote>
7372If the end iterator is reached during parsing by any of the get()
7373member functions, the member sets ios_base::eofbit in err.
7374</blockquote>
7375<p><b>Rationale:</b></p>
7376<p>Two alternative resolutions were proposed.  The LWG chose this one
7377because it was more consistent with the way eof is described for other
7378input facets.</p>
7379<hr>
7380<a name="250"><h3>250.&nbsp;splicing invalidates iterators</h3></a><p><b>Section:</b>&nbsp;23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Brian Parker &nbsp; <b>Date:</b>&nbsp;14 Jul 2000</p>
7381<p>
7382Section 23.2.2.4 [lib.list.ops] states that
7383</p>
7384<pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
7385</pre>
7386<p>
7387<i>invalidates</i> all iterators and references to list <tt>x</tt>.
7388</p>
7389
7390<p>
7391This is unnecessary and defeats an important feature of splice. In
7392fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
7393after <tt>splice</tt>.
7394</p>
7395<p><b>Proposed resolution:</b></p>
7396
7397<p>Add a footnote to 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, paragraph 1:</p>
7398<blockquote>
7399[<i>Footnote:</i> As specified in 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a>, paragraphs
74004-5, the semantics described in this clause applies only to the case
7401where allocators compare equal.  --end footnote]
7402</blockquote>
7403
7404<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, replace paragraph 4 with:</p>
7405<blockquote>
7406Effects: Inserts the contents of x before position and x becomes
7407empty.  Pointers and references to the moved elements of x now refer to
7408those same elements but as members of *this.  Iterators referring to the
7409moved elements will continue to refer to their elements, but they now
7410behave as iterators into *this, not into x.
7411</blockquote>
7412
7413<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, replace paragraph 7 with:</p>
7414<blockquote>
7415Effects: Inserts an element pointed to by i from list x before
7416position and removes the element from x. The result is unchanged if
7417position == i or position == ++i.  Pointers and references to *i continue
7418to refer to this same element but as a member of *this.  Iterators to *i
7419(including i itself) continue to refer to the same element, but now
7420behave as iterators into *this, not into x.
7421</blockquote>
7422
7423<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, replace paragraph 12 with:</p>
7424<blockquote>
7425Requires: [first, last) is a valid range in x. The result is
7426undefined if position is an iterator in the range [first, last).
7427Pointers and references to the moved elements of x now refer to those
7428same elements but as members of *this.  Iterators referring to the moved
7429elements will continue to refer to their elements, but they now behave as
7430iterators into *this, not into x.
7431</blockquote>
7432
7433<p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
7434<p><b>Rationale:</b></p>
7435<p>The original proposed resolution said that iterators and references
7436would remain "valid".  The new proposed resolution clarifies what that
7437means.  Note that this only applies to the case of equal allocators.
7438From 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> paragraph 4, the behavior of list when
7439allocators compare nonequal is outside the scope of the standard.</p>
7440<hr>
7441<a name="251"><h3>251.&nbsp;basic_stringbuf missing allocator_type</h3></a><p><b>Section:</b>&nbsp;27.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jul 2000</p>
7442<p>The synopsis for the template class <tt>basic_stringbuf</tt>
7443doesn't list a typedef for the template parameter
7444<tt>Allocator</tt>. This makes it impossible to determine the type of
7445the allocator at compile time. It's also inconsistent with all other
7446template classes in the library that do provide a typedef for the
7447<tt>Allocator</tt> parameter.</p>
7448<p><b>Proposed resolution:</b></p>
7449<p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
7450basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
7451basic_stringstream (27.7.4) the typedef:</p>
7452<pre>  typedef Allocator allocator_type;
7453</pre>
7454<hr>
7455<a name="252"><h3>252.&nbsp;missing casts/C-style casts used in iostreams</h3></a><p><b>Section:</b>&nbsp;27.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jul 2000</p>
7456<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
7457const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
7458The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
7459D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
7460the cast altogether.</p>
7461
7462<p>C-style casts have not been deprecated, so the first part of this
7463issue is stylistic rather than a matter of correctness.</p>
7464<p><b>Proposed resolution:</b></p>
7465<p>In 27.7.2.2, p1 replace </p>
7466<pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7467
7468<p>with</p>
7469<pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7470
7471
7472<p>In 27.7.3.2, p1 replace</p>
7473<pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7474
7475<p>with</p>
7476<pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7477
7478<p>In 27.7.6, p1, replace</p>
7479<pre>  -1- Returns: &amp;sb</pre>
7480
7481<p>with</p>
7482<pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7483
7484<p>In D.7.2.2, p1 replace</p>
7485<pre>  -2- Returns: &amp;sb. </pre>
7486
7487<p>with</p>
7488<pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
7489<hr>
7490<a name="253"><h3>253.&nbsp;valarray helper functions are almost entirely useless</h3></a><p><b>Section:</b>&nbsp;26.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.5.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;31 Jul 2000</p>
7491<p>This discussion is adapted from message c++std-lib-7056 posted
7492November 11, 1999.  I don't think that anyone can reasonably claim
7493that the problem described below is NAD.</p>
7494
7495<p>These valarray constructors can never be called:</p>
7496
7497<pre>   template &lt;class T&gt;
7498         valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7499   template &lt;class T&gt;
7500         valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
7501   template &lt;class T&gt;
7502         valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
7503   template &lt;class T&gt;
7504         valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
7505</pre>
7506
7507<p>Similarly, these valarray assignment operators cannot be
7508called:</p>
7509
7510<pre>     template &lt;class T&gt;
7511     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
7512     template &lt;class T&gt;
7513     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
7514     template &lt;class T&gt;
7515     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
7516     template &lt;class T&gt;
7517     valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
7518</pre>
7519
7520<p>Please consider the following example:</p>
7521
7522<pre>   #include &lt;valarray&gt;
7523   using namespace std;
7524
7525   int main()
7526   {
7527       valarray&lt;double&gt; va1(12);
7528       valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
7529   }
7530</pre>
7531
7532
7533<p>Since the valarray va1 is non-const, the result of the sub-expression
7534va1[slice(1,4,3)] at line 1 is an rvalue of type const
7535std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
7536construct va2.  The constructor that is used to construct va2 is
7537declared like this:</p>
7538
7539<pre>     template &lt;class T&gt;
7540     valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7541</pre>
7542
7543<p>Notice the constructor's const reference parameter.  When the
7544constructor is called, a slice_array must be bound to this reference.
7545The rules for binding an rvalue to a const reference are in 8.5.3,
7546paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
7547indicates that a second slice_array rvalue is constructed (in this
7548case copy-constructed) from the first one; it is this second rvalue
7549that is bound to the reference parameter.  Paragraph 5 also requires
7550that the constructor that is used for this purpose be callable,
7551regardless of whether the second rvalue is elided.  The
7552copy-constructor in this case is not callable, however, because it is
7553private.  Therefore, the compiler should report an error.</p>
7554
7555<p>Since slice_arrays are always rvalues, the valarray constructor that has a
7556parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
7557same reasoning applies to the three other constructors and the four
7558assignment operators that are listed at the beginning of this post.
7559Furthermore, since these functions cannot be called, the valarray helper
7560classes are almost entirely useless.</p>
7561<p><b>Proposed resolution:</b></p>
7562<p>slice_array:</p>
7563<ul>
7564<li> Make the copy constructor and copy-assignment operator declarations
7565     public in the slice_array class template definition in 26.5.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>
7566<li> remove paragraph 3 of 26.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
7567</li>
7568<li> remove the copy constructor declaration from 26.5.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>
7569</li>
7570<li> change paragraph 1 of 26.5.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
7571    to be private.  This constructor need not be defined."</li>
7572<li> remove the first sentence of paragraph 1 of 26.5.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>
7573</li>
7574<li> Change the first three words of the second sentence of paragraph 1 of
7575    26.5.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>
7576</ul>
7577
7578<p>gslice_array:</p>
7579<ul>
7580<li> Make the copy constructor and copy-assignment operator declarations
7581    public in the gslice_array class template definition in 26.5.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>
7582<li> remove the note in paragraph 3 of 26.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
7583</li>
7584<li> remove the copy constructor declaration from 26.5.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>
7585</li>
7586<li> change paragraph 1 of 26.5.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
7587    to be private.  This constructor need not be defined."</li>
7588<li> remove the first sentence of paragraph 1 of 26.5.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>
7589</li>
7590<li> Change the first three words of the second sentence of paragraph 1 of
7591    26.5.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>
7592</ul>
7593
7594<p>mask_array:</p>
7595<ul>
7596<li> Make the copy constructor and copy-assignment operator declarations
7597    public in the mask_array class template definition in 26.5.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>
7598<li> remove the note in paragraph 2 of 26.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
7599</li>
7600<li> remove the copy constructor declaration from 26.5.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>
7601</li>
7602<li> change paragraph 1 of 26.5.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
7603    to be private.  This constructor need not be defined."</li>
7604<li> remove the first sentence of paragraph 1 of 26.5.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>
7605</li>
7606<li> Change the first three words of the second sentence of paragraph 1 of
7607    26.5.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>
7608</ul>
7609
7610<p>indirect_array:</p>
7611<ul>
7612<li>Make the copy constructor and copy-assignment operator declarations
7613    public in the indirect_array class definition in 26.5.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
7614</li>
7615<li> remove the note in paragraph 2 of 26.5.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
7616</li>
7617<li> remove the copy constructor declaration from 26.5.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>
7618</li>
7619<li> change the descriptive text in 26.5.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
7620    declared to be private.  This constructor need not be defined."</li>
7621<li> remove the first sentence of paragraph 1 of 26.5.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>
7622</li>
7623<li> Change the first three words of the second sentence of paragraph 1 of
7624    26.5.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>
7625</ul>
7626<p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
7627copy constructor and copy assignment operators public, instead of
7628removing them.]</i></p>
7629<p><b>Rationale:</b></p>
7630<p>Keeping the valarray constructors private is untenable.  Merely
7631making valarray a friend of the helper classes isn't good enough,
7632because access to the copy constructor is checked in the user's
7633environment.</p>
7634
7635<p>Making the assignment operator public is not strictly necessary to
7636solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
7637believed we should make the assignment operators public, in addition
7638to the copy constructors, for reasons of symmetry and user
7639expectation.</p>
7640<hr>
7641<a name="256"><h3>256.&nbsp;typo in 27.4.4.2, p17: copy_event does not exist</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;21 Aug 2000</p>
7642<p>
764327.4.4.2, p17 says
7644</p>
7645
7646<blockquote>
7647-17- Before copying any parts of rhs, calls each registered callback
7648pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
7649exceptions() have been replaced, calls each callback pair that was
7650copied from rhs as (*fn)(copy_event,*this,index).
7651</blockquote>
7652
7653<p>
7654The name copy_event isn't defined anywhere. The intended name was
7655copyfmt_event.
7656</p>
7657<p><b>Proposed resolution:</b></p>
7658<p>Replace copy_event with copyfmt_event in the named paragraph.</p>
7659<hr>
7660<a name="259"><h3>259.&nbsp;<tt>basic_string::operator[]</tt> and const correctness</h3></a><p><b>Section:</b>&nbsp;21.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.access"> [lib.string.access]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Chris Newton &nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
7661<p>
7662<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
7663</p>
7664
7665<p>
7666The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
7667seems to violate const correctness.
7668</p>
7669
7670<p>
7671The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
7672returns <tt>data()[pos]</tt>." The types don't work.  The
7673return value of <tt>data()</tt> is <tt>const charT*</tt>, but
7674<tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
7675</p>
7676<p><b>Proposed resolution:</b></p>
7677<p>
7678In section 21.3.4, paragraph 1, change
7679"<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
7680<i>pos</i>)</tt>".
7681</p>
7682<hr>
7683<a name="260"><h3>260.&nbsp;Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
7684</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
7685<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
7686it as returning the iterator by value. 24.5.1.2, p5 shows the same
7687operator as returning the iterator by reference. That's incorrect
7688given the Effects clause below (since a temporary is returned). The
7689`&amp;' is probably just a typo.</p>
7690<p><b>Proposed resolution:</b></p>
7691<p>Change the declaration in 24.5.1.2, p5 from</p>
7692 <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
7693 </pre>
7694<p>to</p>
7695 <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
7696 </pre>
7697<p>(that is, remove the `&amp;').</p>
7698<hr>
7699<a name="261"><h3>261.&nbsp;Missing description of <tt>istream_iterator::operator!=</tt>
7700</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
7701<p>
770224.5.1, p3 lists the synopsis for
7703</p>
7704
7705<pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7706        bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7707                        const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7708</pre>
7709
7710<p>
7711but there is no description of what the operator does (i.e., no Effects
7712or Returns clause) in 24.5.1.2.
7713</p>
7714<p><b>Proposed resolution:</b></p>
7715<p>
7716Add paragraph 7 to the end of section 24.5.1.2 with the following text:
7717</p>
7718
7719<pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7720        bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7721                        const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7722</pre>
7723
7724<p>-7- Returns: !(x == y).</p>
7725<hr>
7726<a name="262"><h3>262.&nbsp;Bitmask operator ~ specified incorrectly</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;03 Sep 2000</p>
7727<p>
7728The ~ operation should be applied after the cast to int_type.
7729</p>
7730<p><b>Proposed resolution:</b></p>
7731<p>
7732Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
7733</p>
7734
7735<pre>   bitmask operator~ ( bitmask X )
7736     { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
7737</pre>
7738
7739<p>
7740to:
7741</p>
7742
7743<pre>   bitmask operator~ ( bitmask X )
7744     { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
7745</pre>
7746<hr>
7747<a name="263"><h3>263.&nbsp;Severe restriction on <tt>basic_string</tt> reference counting</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Kevlin Henney&nbsp; <b>Date:</b>&nbsp;04 Sep 2000</p>
7748<p>
7749The note in paragraph 6 suggests that the invalidation rules for
7750references, pointers, and iterators in paragraph 5 permit a reference-
7751counted implementation (actually, according to paragraph 6, they permit
7752a "reference counted implementation", but this is a minor editorial fix).
7753</p>
7754
7755<p>
7756However, the last sub-bullet is so worded as to make a reference-counted
7757implementation unviable. In the following example none of the
7758conditions for iterator invalidation are satisfied:
7759</p>
7760
7761<pre>    // first example: "*******************" should be printed twice
7762    string original = "some arbitrary text", copy = original;
7763    const string &amp; alias = original;
7764
7765    string::const_iterator i = alias.begin(), e = alias.end();
7766    for(string::iterator j = original.begin(); j != original.end(); ++j)
7767        *j = '*';
7768    while(i != e)
7769        cout &lt;&lt; *i++;
7770    cout &lt;&lt; endl;
7771    cout &lt;&lt; original &lt;&lt; endl;
7772</pre>
7773
7774<p>
7775Similarly, in the following example:
7776</p>
7777
7778<pre>    // second example: "some arbitrary text" should be printed out
7779    string original = "some arbitrary text", copy = original;
7780    const string &amp; alias = original;
7781
7782    string::const_iterator i = alias.begin();
7783    original.begin();
7784    while(i != alias.end())
7785        cout &lt;&lt; *i++;
7786</pre>
7787
7788<p>
7789I have tested this on three string implementations, two of which were
7790reference counted. The reference-counted implementations gave
7791"surprising behavior" because they invalidated iterators on
7792the first call to non-const begin since construction. The current
7793wording does not permit such invalidation because it does not take
7794into account the first call since construction, only the first call
7795since various member and non-member function calls.
7796</p>
7797<p><b>Proposed resolution:</b></p>
7798<p>
7799Change the following sentence in 21.3 paragraph 5 from
7800</p>
7801
7802<blockquote>
7803    Subsequent to any of the above uses except the forms of insert() and
7804    erase() which return iterators, the first call to non-const member
7805    functions operator[](), at(), begin(), rbegin(), end(), or rend().
7806</blockquote>
7807
7808<p>to</p>
7809
7810<blockquote>
7811    Following construction or any of the above uses, except the forms of
7812    insert() and erase() that return iterators, the first call to non-
7813    const member functions operator[](), at(), begin(), rbegin(), end(),
7814    or rend().
7815</blockquote>
7816<hr>
7817<a name="264"><h3>264.&nbsp;Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;07 Sep 2000</p>
7818<p>
7819Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
7820Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
7821integers in the same range.
7822</p>
7823
7824<p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
7825<p><b>Proposed resolution:</b></p>
7826<p>
7827In Table 69, in section 23.1.2, change the complexity clause for
7828insertion of a range from "N log(size() + N) (N is the distance
7829from i to j) in general; linear if [i, j) is sorted according to
7830value_comp()" to "N log(size() + N), where N is the distance
7831from i to j".
7832</p>
7833
7834<p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
7835parens in the revised wording.]</i></p>
7836
7837<p><b>Rationale:</b></p>
7838<p>
7839Testing for valid insertions could be less efficient than simply
7840inserting the elements when the range is not both sorted and between
7841two adjacent existing elements; this could be a QOI issue.
7842</p>
7843
7844<p>
7845The LWG considered two other options: (a) specifying that the
7846complexity was linear if [i, j) is sorted according to value_comp()
7847and between two adjacent existing elements; or (b) changing to
7848Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
7849number of elements which do not insert immediately after the previous
7850element from [i, j) including the first).  The LWG felt that, since
7851we can't guarantee linear time complexity whenever the range to be
7852inserted is sorted, it's more trouble than it's worth to say that it's
7853linear in some special cases.
7854</p>
7855<hr>
7856<a name="265"><h3>265.&nbsp;std::pair::pair() effects overly restrictive</h3></a><p><b>Section:</b>&nbsp;20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;11 Sep 2000</p>
7857<p>
7858I don't see any requirements on the types of the elements of the
7859std::pair container in 20.2.2. From the descriptions of the member
7860functions it appears that they must at least satisfy the requirements of
786120.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
7862the case of the [in]equality operators also the requirements of 20.1.1
7863[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
7864</p>
7865
7866<p>
7867I believe that the the CopyConstructible requirement is unnecessary in
7868the case of 20.2.2, p2.
7869</p>
7870<p><b>Proposed resolution:</b></p>
7871<p>Change the Effects clause in 20.2.2, p2 from</p>
7872
7873<blockquote>
7874-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7875first(T1()), second(T2()) {} </tt>
7876</blockquote>
7877
7878<p>to</p>
7879
7880<blockquote>
7881-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7882first(), second() {} </tt>
7883</blockquote>
7884<p><b>Rationale:</b></p>
7885<p>The existing specification of pair's constructor appears to be a
7886historical artifact: there was concern that pair's members be properly
7887zero-initialized when they are built-in types.  At one time there was
7888uncertainty about whether they would be zero-initialized if the
7889default constructor was written the obvious way.  This has been
7890clarified by core issue 178, and there is no longer any doubt that
7891the straightforward implementation is correct.</p>
7892<hr>
7893<a name="266"><h3>266.&nbsp;bad_exception::~bad_exception() missing Effects clause</h3></a><p><b>Section:</b>&nbsp;18.7.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;24 Sep 2000</p>
7894<p>
7895The synopsis for std::bad_exception lists the function ~bad_exception()
7896but there is no description of what the function does (the Effects
7897clause is missing).
7898</p>
7899<p><b>Proposed resolution:</b></p>
7900<p>
7901Remove the destructor from the class synopses of
7902<tt>bad_alloc</tt> (<font color="red">18.4.2.1</font>),
7903<tt>bad_cast</tt> (18.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.alloc.errors"> [lib.alloc.errors]</a>),
7904<tt>bad_typeid</tt> (<font color="red">18.5.3</font>),
7905and <tt>bad_exception</tt> (18.7.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>).
7906</p>
7907<p><b>Rationale:</b></p>
7908<p>
7909This is a general problem with the exception classes in clause 18.
7910The proposed resolution is to remove the destructors from the class
7911synopses, rather than to document the destructors' behavior, because
7912removing them is more consistent with how exception classes are
7913described in clause 19.
7914</p>
7915<hr>
7916<a name="268"><h3>268.&nbsp;Typo in locale synopsis</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Oct 2000</p>
7917<p>The synopsis of the class std::locale in 22.1.1 contains two typos:
7918the semicolons after the declarations of the default ctor
7919locale::locale() and the copy ctor locale::locale(const locale&amp;)
7920are missing.</p>
7921<p><b>Proposed resolution:</b></p>
7922<p>Add the missing semicolons, i.e., change</p>
7923
7924<pre>    //  construct/copy/destroy:
7925        locale() throw()
7926        locale(const locale&amp; other) throw()
7927</pre>
7928
7929<p>in the synopsis in 22.1.1 to</p>
7930
7931<pre>    //  construct/copy/destroy:
7932        locale() throw();
7933        locale(const locale&amp; other) throw();
7934</pre>
7935<hr>
7936<a name="270"><h3>270.&nbsp;Binary search requirements overly strict</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Oct 2000</p>
7937<p>
7938Each of the four binary search algorithms (lower_bound, upper_bound,
7939equal_range, binary_search) has a form that allows the user to pass a
7940comparison function object.  According to 25.3, paragraph 2, that
7941comparison function object has to be a strict weak ordering.
7942</p>
7943
7944<p>
7945This requirement is slightly too strict.  Suppose we are searching
7946through a sequence containing objects of type X, where X is some
7947large record with an integer key.  We might reasonably want to look
7948up a record by key, in which case we would want to write something
7949like this:
7950</p>
7951<pre>    struct key_comp {
7952      bool operator()(const X&amp; x, int n) const {
7953        return x.key() &lt; n;
7954      }
7955    }
7956
7957    std::lower_bound(first, last, 47, key_comp());
7958</pre>
7959
7960<p>
7961key_comp is not a strict weak ordering, but there is no reason to
7962prohibit its use in lower_bound.
7963</p>
7964
7965<p>
7966There's no difficulty in implementing lower_bound so that it allows
7967the use of something like key_comp.  (It will probably work unless an
7968implementor takes special pains to forbid it.)  What's difficult is
7969formulating language in the standard to specify what kind of
7970comparison function is acceptable.  We need a notion that's slightly
7971more general than that of a strict weak ordering, one that can encompass
7972a comparison function that involves different types.  Expressing that
7973notion may be complicated.
7974</p>
7975
7976<p><i>Additional questions raised at the Toronto meeting:</i></p>
7977<ul>
7978<li> Do we really want to specify what ordering the implementor must
7979     use when calling the function object?  The standard gives
7980     specific expressions when describing these algorithms, but it also
7981     says that other expressions (with different argument order) are
7982     equivalent.</li>
7983<li> If we are specifying ordering, note that the standard uses both
7984     orderings when describing <tt>equal_range</tt>.</li>
7985<li> Are we talking about requiring these algorithms to work properly
7986     when passed a binary function object whose two argument types
7987     are not the same, or are we talking about requirements when
7988     they are passed a binary function object with several overloaded
7989     versions of <tt>operator()</tt>?</li>
7990<li> The definition of a strict weak ordering does not appear to give
7991     any guidance on issues of overloading; it only discusses expressions,
7992     and all of the values in these expressions are of the same type.
7993     Some clarification would seem to be in order.</li>
7994</ul>
7995
7996<p><i>Additional discussion from Copenhagen:</i></p>
7997<ul>
7998<li>It was generally agreed that there is a real defect here: if
7999the predicate is merely required to be a Strict Weak Ordering, then
8000it's possible to pass in a function object with an overloaded
8001operator(), where the version that's actually called does something
8002completely inappropriate.  (Such as returning a random value.)</li>
8003
8004<li>An alternative formulation was presented in a paper distributed by
8005David Abrahams at the meeting, "Binary Search with Heterogeneous
8006Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
8007predicate as a Strict Weak Ordering acting on a sorted sequence, view
8008the predicate/value pair as something that partitions a sequence.
8009This is almost equivalent to saying that we should view binary search
8010as if we are given a unary predicate and a sequence, such that f(*p)
8011is true for all p below a specific point and false for all p above it.
8012The proposed resolution is based on that alternative formulation.</li>
8013</ul>
8014<p><b>Proposed resolution:</b></p>
8015
8016<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
8017
8018<blockquote>
8019  3 For all algorithms that take Compare, there is a version that uses
8020  operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
8021  *j != false. For the algorithms to work correctly, comp has to
8022  induce a strict weak ordering on the values.
8023</blockquote>
8024
8025<p>to:</p>
8026
8027<blockquote>
8028  3 For all algorithms that take Compare, there is a version that uses
8029  operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
8030  &lt; *j != false. For algorithms other than those described in
8031  lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
8032  a strict weak ordering on the values.
8033</blockquote>
8034
8035<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
8036
8037<blockquote>
8038  -6- A sequence [start, finish) is partitioned with respect to an
8039  expression f(e) if there exists an integer n such that
8040  for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
8041  and only if i &lt; n.
8042</blockquote>
8043
8044<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
8045
8046<blockquote>
8047  -1- All of the algorithms in this section are versions of binary
8048   search and assume that the sequence being searched is in order
8049   according to the implied or explicit comparison function. They work
8050   on non-random access iterators minimizing the number of
8051   comparisons, which will be logarithmic for all types of
8052   iterators. They are especially appropriate for random access
8053   iterators, because these algorithms do a logarithmic number of
8054   steps through the data structure. For non-random access iterators
8055   they execute a linear number of steps.
8056</blockquote>
8057
8058<p>to:</p>
8059
8060<blockquote>
8061   -1- All of the algorithms in this section are versions of binary
8062    search and assume that the sequence being searched is partitioned
8063    with respect to an expression formed by binding the search key to
8064    an argument of the implied or explicit comparison function. They
8065    work on non-random access iterators minimizing the number of
8066    comparisons, which will be logarithmic for all types of
8067    iterators. They are especially appropriate for random access
8068    iterators, because these algorithms do a logarithmic number of
8069    steps through the data structure. For non-random access iterators
8070    they execute a linear number of steps.
8071</blockquote>
8072
8073<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
8074
8075<blockquote>
8076   -1- Requires: Type T is LessThanComparable
8077    (lib.lessthancomparable).
8078</blockquote>
8079
8080<p>to:</p>
8081
8082<blockquote>
8083   -1- Requires: The elements e of [first, last) are partitioned with
8084   respect to the expression e &lt; value or comp(e, value)
8085</blockquote>
8086
8087
8088<p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
8089
8090<blockquote>
8091   -2- Effects: Finds the first position into which value can be
8092    inserted without violating the ordering.
8093</blockquote>
8094
8095<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
8096
8097<blockquote>
8098  -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
8099</blockquote>
8100
8101<p>to:</p>
8102
8103<blockquote>
8104   -1- Requires: The elements e of [first, last) are partitioned with
8105   respect to the expression !(value &lt; e) or !comp(value, e)
8106</blockquote>
8107
8108<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
8109
8110<blockquote>
8111   -2- Effects: Finds the furthermost position into which value can be
8112    inserted without violating the ordering.
8113</blockquote>
8114
8115<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
8116
8117<blockquote>
8118   -1- Requires: Type T is LessThanComparable
8119    (lib.lessthancomparable).
8120</blockquote>
8121
8122<p>to:</p>
8123
8124<blockquote>
8125   -1- Requires: The elements e of [first, last) are partitioned with
8126   respect to the expressions e &lt; value and !(value &lt; e) or
8127   comp(e, value) and !comp(value, e).  Also, for all elements e of
8128   [first, last), e &lt; value implies !(value &lt; e) or comp(e,
8129   value) implies !comp(value, e)
8130</blockquote>
8131
8132<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
8133
8134<blockquote>
8135   -2- Effects: Finds the largest subrange [i, j) such that the value
8136    can be inserted at any iterator k in it without violating the
8137    ordering. k satisfies the corresponding conditions: !(*k &lt; value)
8138    &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
8139    false.
8140</blockquote>
8141
8142<p>to:</p>
8143
8144<pre>   -2- Returns:
8145         make_pair(lower_bound(first, last, value),
8146                   upper_bound(first, last, value))
8147       or
8148         make_pair(lower_bound(first, last, value, comp),
8149                   upper_bound(first, last, value, comp))
8150</pre>
8151
8152<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
8153
8154<blockquote>
8155   -1- Requires: Type T is LessThanComparable
8156    (lib.lessthancomparable).
8157</blockquote>
8158
8159<p>to:</p>
8160
8161<blockquote>
8162   -1- Requires: The elements e of [first, last) are partitioned with
8163   respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
8164   value) and !comp(value, e). Also, for all elements e of [first,
8165   last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
8166   !comp(value, e)
8167</blockquote>
8168
8169<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
8170
8171<p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
8172changed the "other than those described in" wording.) Also, the LWG
8173decided to accept the "optional" part.]</i></p>
8174
8175<p><b>Rationale:</b></p>
8176<p>The proposed resolution reinterprets binary search. Instead of
8177thinking about searching for a value in a sorted range, we view that
8178as an important special case of a more general algorithm: searching
8179for the partition point in a partitioned range.</p>
8180
8181<p>We also add a guarantee that the old wording did not: we ensure
8182that the upper bound is no earlier than the lower bound, that
8183the pair returned by equal_range is a valid range, and that the first
8184part of that pair is the lower bound.</p>
8185<hr>
8186<a name="271"><h3>271.&nbsp;basic_iostream missing typedefs</h3></a><p><b>Section:</b>&nbsp;27.6.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8187<p>
8188Class template basic_iostream has no typedefs.  The typedefs it
8189inherits from its base classes can't be used, since (for example)
8190basic_iostream&lt;T&gt;::traits_type is ambiguous.
8191</p>
8192<p><b>Proposed resolution:</b></p>
8193
8194<p>Add the following to basic_iostream's class synopsis in
819527.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>
8196
8197<pre>  // types:
8198  typedef charT                     char_type;
8199  typedef typename traits::int_type int_type;
8200  typedef typename traits::pos_type pos_type;
8201  typedef typename traits::off_type off_type;
8202  typedef traits                    traits_type;
8203</pre>
8204<hr>
8205<a name="272"><h3>272.&nbsp;Missing parentheses around subexpression</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8206<p>
820727.4.4.3, p4 says about the postcondition of the function: If
8208rdbuf()!=0 then state == rdstate(); otherwise
8209rdstate()==state|ios_base::badbit.
8210</p>
8211
8212<p>
8213The expression on the right-hand-side of the operator==() needs to be
8214parenthesized in order for the whole expression to ever evaluate to
8215anything but non-zero.
8216</p>
8217<p><b>Proposed resolution:</b></p>
8218<p>
8219Add parentheses like so: rdstate()==(state|ios_base::badbit).
8220</p>
8221<hr>
8222<a name="273"><h3>273.&nbsp;Missing ios_base qualification on members of a dependent class</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8223<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
822427.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
8225That's incorrect since the names are members of a dependent base
8226class (14.6.2 [temp.dep]) and thus not visible.</p>
8227<p><b>Proposed resolution:</b></p>
8228<p>Qualify the names with the name of the class of which they are
8229members, i.e., ios_base.</p>
8230<hr>
8231<a name="274"><h3>274.&nbsp;a missing/impossible allocator requirement</h3></a><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8232<p>
8233I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
8234any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
8235be overloaded on reference and const_reference, which is ill-formed for
8236all T = const U. In other words, this won't work:
8237</p>
8238
8239<p>
8240template class std::allocator&lt;const int&gt;;
8241</p>
8242
8243<p>
8244The obvious solution is to disallow specializations of allocators on
8245const types. However, while containers' elements are required to be
8246assignable (which rules out specializations on const T's), I think that
8247allocators might perhaps be potentially useful for const values in other
8248contexts. So if allocators are to allow const types a partial
8249specialization of std::allocator&lt;const T&gt; would probably have to be
8250provided.
8251</p>
8252<p><b>Proposed resolution:</b></p>
8253<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
8254
8255    <blockquote>
8256    any type
8257    </blockquote>
8258
8259<p>to</p>
8260    <blockquote>
8261    any non-const, non-reference type
8262    </blockquote>
8263
8264<p><i>[Redmond: previous proposed resolution was "any non-const,
8265non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
8266
8267<p><b>Rationale:</b></p>
8268<p>
8269Two resolutions were originally proposed: one that partially
8270specialized std::allocator for const types, and one that said an
8271allocator's value type may not be const.  The LWG chose the second.
8272The first wouldn't be appropriate, because allocators are intended for
8273use by containers, and const value types don't work in containers.
8274Encouraging the use of allocators with const value types would only
8275lead to unsafe code.
8276</p>
8277<p>
8278The original text for proposed resolution 2 was modified so that it
8279also forbids volatile types and reference types.
8280</p>
8281
8282<p><i>[Cura�ao: LWG double checked and believes volatile is correctly
8283excluded from the PR.]</i></p>
8284
8285<hr>
8286<a name="275"><h3>275.&nbsp;Wrong type in num_get::get() overloads</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8287<p>
8288In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
8289There are eight overloads, all of which are identical except for the
8290last parameter.  The overloads are:
8291</p>
8292<ul>
8293<li> long&amp; </li>
8294<li> unsigned short&amp; </li>
8295<li> unsigned int&amp; </li>
8296<li> unsigned long&amp; </li>
8297<li> short&amp; </li>
8298<li> double&amp; </li>
8299<li> long double&amp; </li>
8300<li> void*&amp; </li>
8301</ul>
8302
8303<p>
8304There is a similar list, in 22.2.2.1.2, of overloads for
8305num_get&lt;&gt;::do_get().  In this list, the last parameter has
8306the types:
8307</p>
8308<ul>
8309<li> long&amp; </li>
8310<li> unsigned short&amp; </li>
8311<li> unsigned int&amp; </li>
8312<li> unsigned long&amp; </li>
8313<li> float&amp; </li>
8314<li> double&amp; </li>
8315<li> long double&amp; </li>
8316<li> void*&amp; </li>
8317</ul>
8318
8319<p>
8320These two lists are not identical.  They should be, since
8321<tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
8322the arguments it was given.
8323</p>
8324<p><b>Proposed resolution:</b></p>
8325<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>
8326<pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8327                ios_base::iostate&amp; err, short&amp; val) const;
8328</pre>
8329<p>to</p>
8330<pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8331                ios_base::iostate&amp; err, float&amp; val) const;
8332</pre>
8333<hr>
8334<a name="276"></a><h3><a name="276">276.&nbsp;Assignable requirement for container value type overly strict</a></h3><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;07 Nov 2000</p>
8335<p>
833623.1/3 states that the objects stored in a container must be
8337Assignable.  23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
8338states that map satisfies all requirements for a container, while in
8339the same time defining value_type as pair&lt;const Key, T&gt; - a type
8340that is not Assignable.
8341</p>
8342
8343<p>
8344It should be noted that there exists a valid and non-contradictory
8345interpretation of the current text. The wording in 23.1/3 avoids
8346mentioning value_type, referring instead to "objects stored in a
8347container." One might argue that map does not store objects of
8348type map::value_type, but of map::mapped_type instead, and that the
8349Assignable requirement applies to map::mapped_type, not
8350map::value_type.
8351</p>
8352
8353<p>
8354However, this makes map a special case (other containers store objects of
8355type value_type) and the Assignable requirement is needlessly restrictive in
8356general.
8357</p>
8358
8359<p>
8360For example, the proposed resolution of active library issue
8361<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
8362means that no set operations can exploit the fact that the stored
8363objects are Assignable.
8364</p>
8365
8366<p>
8367This is related to, but slightly broader than, closed issue
8368<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
8369</p>
8370<p><b>Proposed resolution:</b></p>
8371<p>23.1/3: Strike the trailing part of the sentence:</p>
8372    <blockquote>
8373    , and the additional requirements of Assignable types from 23.1/3
8374    </blockquote>
8375<p>so that it reads:</p>
8376    <blockquote>
8377    -3- The type of objects stored in these components must meet the
8378    requirements of CopyConstructible types (lib.copyconstructible).
8379    </blockquote>
8380
8381<p>23.1/4: Modify to make clear that this requirement is not for all
8382containers.  Change to:</p>
8383
8384<blockquote>
8385-4- Table 64 defines the Assignable requirement.  Some containers
8386require this property of the types to be stored in the container.  T is
8387the type used to instantiate the container. t is a value of T, and u is
8388a value of (possibly const) T.
8389</blockquote>
8390
8391<p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
8392CopyConstructible".</p>
8393
8394<p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
8395
8396<blockquote>
8397-2- A deque satisfies all of the requirements of a container and of a
8398reversible container (given in tables in lib.container.requirements) and
8399of a sequence, including the optional sequence requirements
8400(lib.sequence.reqmts).  In addition to the requirements on the stored
8401object described in 23.1[lib.container.requirements], the stored object
8402must also meet the requirements of Assignable.  Descriptions are
8403provided here only for operations on deque that are not described in one
8404of these tables or for operations where there is additional semantic
8405information.
8406</blockquote>
8407
8408<p>23.2.2/2:  Add Assignable requirement to specific methods of list.
8409Change to:</p>
8410
8411<blockquote>
8412<p>-2- A list satisfies all of the requirements of a container and of a
8413reversible container (given in two tables in lib.container.requirements)
8414and of a sequence, including most of the the optional sequence
8415requirements (lib.sequence.reqmts). The exceptions are the operator[]
8416and at member functions, which are not provided.
8417
8418[Footnote: These member functions are only provided by containers whose
8419iterators are random access iterators. --- end foonote]
8420</p>
8421
8422<p>list does not require the stored type T to be Assignable unless the
8423following methods are instantiated:
8424
8425[Footnote: Implementors are permitted but not required to take advantage
8426of T's Assignable properties for these methods. -- end foonote]
8427</p>
8428<pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
8429     template &lt;class InputIterator&gt;
8430       void assign(InputIterator first, InputIterator last);
8431     void assign(size_type n, const T&amp; t);
8432</pre>
8433
8434
8435<p>Descriptions are provided here only for operations on list that are not
8436described in one of these tables or for operations where there is
8437additional semantic information.</p>
8438</blockquote>
8439
8440<p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
8441
8442<blockquote>
8443-2- A vector satisfies all of the requirements of a container and of a
8444reversible container (given in two tables in lib.container.requirements)
8445and of a sequence, including most of the optional sequence requirements
8446(lib.sequence.reqmts). The exceptions are the push_front and pop_front
8447member functions, which are not provided.  In addition to the
8448requirements on the stored object described in
844923.1[lib.container.requirements], the stored object must also meet the
8450requirements of Assignable.  Descriptions are provided here only for
8451operations on vector that are not described in one of these tables or
8452for operations where there is additional semantic information.
8453</blockquote>
8454<p><b>Rationale:</b></p>
8455<p>list, set, multiset, map, multimap are able to store non-Assignables.
8456However, there is some concern about <tt>list&lt;T&gt;</tt>:
8457although in general there's no reason for T to be Assignable, some
8458implementations of the member functions <tt>operator=</tt> and
8459<tt>assign</tt> do rely on that requirement.  The LWG does not want
8460to forbid such implementations.</p>
8461
8462<p>Note that the type stored in a standard container must still satisfy
8463the requirements of the container's allocator; this rules out, for
8464example, such types as "const int".  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>
8465for more details.
8466</p>
8467
8468<p>In principle we could also relax the "Assignable" requirement for
8469individual <tt>vector</tt> member functions, such as
8470<tt>push_back</tt>.  However, the LWG did not see great value in such
8471selective relaxation.  Doing so would remove implementors' freedom to
8472implement <tt>vector::push_back</tt> in terms of
8473<tt>vector::insert</tt>.</p>
8474
8475<hr>
8476<a name="278"><h3>278.&nbsp;What does iterator validity mean?</h3></a><p><b>Section:</b>&nbsp;23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
8477<p>
8478Section 23.2.2.4 [lib.list.ops] states that
8479</p>
8480<pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
8481</pre>
8482<p>
8483<i>invalidates</i> all iterators and references to list <tt>x</tt>.
8484</p>
8485
8486<p>
8487But what does the C++ Standard mean by "invalidate"?  You
8488can still dereference the iterator to a spliced list element, but
8489you'd better not use it to delimit a range within the original
8490list. For the latter operation, it has definitely lost some of its
8491validity.
8492</p>
8493
8494<p>
8495If we accept the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>,
8496then we'd better clarify that a "valid" iterator need no
8497longer designate an element within the same container as it once did.
8498We then have to clarify what we mean by invalidating a past-the-end
8499iterator, as when a vector or string grows by reallocation. Clearly,
8500such an iterator has a different kind of validity. Perhaps we should
8501introduce separate terms for the two kinds of "validity."
8502</p>
8503<p><b>Proposed resolution:</b></p>
8504<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>,
8505after paragraph 5:</p>
8506<blockquote>
8507An <i>invalid</i> iterator is an iterator that may be
8508singular. [Footnote: This definition applies to pointers, since
8509pointers are iterators. The effect of dereferencing an iterator that
8510has been invalidated is undefined.]
8511</blockquote>
8512
8513<p><i>[post-Copenhagen: Matt provided wording.]</i></p>
8514
8515<p><i>[Redmond: General agreement with the intent, some objections to
8516the wording.  Dave provided new wording.]</i></p>
8517<p><b>Rationale:</b></p>
8518<p>This resolution simply defines a term that the Standard uses but
8519  never defines, "invalid", in terms of a term that is defined,
8520  "singular".</p>
8521
8522<p>Why do we say "may be singular", instead of "is singular"?  That's
8523  becuase a valid iterator is one that is known to be nonsingular.
8524  Invalidating an iterator means changing it in such a way that it's
8525  no longer known to be nonsingular.  An example: inserting an
8526  element into the middle of a vector is correctly said to invalidate
8527  all iterators pointing into the vector.  That doesn't necessarily
8528  mean they all become singular.</p>
8529<hr>
8530<a name="280"><h3>280.&nbsp;Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b>&nbsp;24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Cleary&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
8531<p>
8532This came from an email from Steve Cleary to Fergus in reference to
8533issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
8534this in Toronto and believed it should be a separate issue.  There was
8535also some reservations about whether this was a worthwhile problem to
8536fix.
8537</p>
8538
8539<p>
8540Steve said: "Fixing reverse_iterator. std::reverse_iterator can
8541(and should) be changed to preserve these additional
8542requirements." He also said in email that it can be done without
8543breaking user's code: "If you take a look at my suggested
8544solution, reverse_iterator doesn't have to take two parameters; there
8545is no danger of breaking existing code, except someone taking the
8546address of one of the reverse_iterator global operator functions, and
8547I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
8548case they have, you can leave the old global functions in as well --
8549they won't interfere with the two-template-argument functions.  With
8550that, I don't see how <i>any</i> user code could break."
8551</p>
8552<p><b>Proposed resolution:</b></p>
8553<p>
8554<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>
8555add/change the following declarations:</p>
8556<pre>  A) Add a templated assignment operator, after the same manner
8557        as the templated copy constructor, i.e.:
8558
8559  template &lt; class U &gt;
8560  reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
8561
8562  B) Make all global functions (except the operator+) have
8563  two template parameters instead of one, that is, for
8564  operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
8565
8566       template &lt; class Iterator &gt;
8567       typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
8568                 const reverse_iterator&lt; Iterator &gt;&amp; x,
8569                 const reverse_iterator&lt; Iterator &gt;&amp; y);
8570
8571  with:
8572
8573      template &lt; class Iterator1, class Iterator2 &gt;
8574      typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
8575                 const reverse_iterator &lt; Iterator1 &gt; &amp; x,
8576                 const reverse_iterator &lt; Iterator2 &gt; &amp; y);
8577</pre>
8578<p>
8579Also make the addition/changes for these signatures in
858024.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>.
8581</p>
8582
8583<p><i>[
8584Copenhagen: The LWG is concerned that the proposed resolution
8585introduces new overloads.  Experience shows that introducing
8586overloads is always risky, and that it would be inappropriate to
8587make this change without implementation experience.  It may be
8588desirable to provide this feature in a different way.
8589]</i></p>
8590
8591<p><i>[
8592Lillehammer: We now have implementation experience, and agree that
8593this solution is safe and correct.
8594]</i></p>
8595
8596<hr>
8597<a name="281"><h3>281.&nbsp;std::min() and max() requirements overly restrictive</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Dec 2000</p>
8598<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
8599requirements 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>)
8600and <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>).
8601Since the functions take and return their arguments and result by
8602const reference, I believe the <tt>CopyConstructible</tt> requirement
8603is unnecessary.
8604</p>
8605<p><b>Proposed resolution:</b></p>
8606<p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
860725.3.7, p1 with</p>
8608<p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
8609(20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8610</p>
8611<p>and replace 25.3.7, p4 with</p>
8612<p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
8613(20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8614</p>
8615<hr>
8616<a name="282"><h3>282.&nbsp;What types does numpunct grouping refer to?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
8617<p>
8618Paragraph 16 mistakenly singles out integral types for inserting
8619thousands_sep() characters.  This conflicts with the syntax for floating
8620point numbers described under 22.2.3.1/2.
8621</p>
8622<p><b>Proposed resolution:</b></p>
8623<p>Change paragraph 16 from:</p>
8624
8625<blockquote>
8626For integral types, punct.thousands_sep() characters are inserted into
8627the sequence as determined by the value returned by punct.do_grouping()
8628using 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>.
8629</blockquote>
8630
8631<p>To:</p>
8632
8633<blockquote>
8634For arithmetic types, punct.thousands_sep() characters are inserted into
8635the sequence as determined by the value returned by punct.do_grouping()
8636using 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>.
8637</blockquote>
8638
8639<p><i>[
8640Copenhagen: Opinions were divided about whether this is actually an
8641inconsistency, but at best it seems to have been unintentional.  This
8642is only an issue for floating-point output: The standard is
8643unambiguous that implementations must parse thousands_sep characters
8644when performing floating-point.  The standard is also unambiguous that
8645this requirement does not apply to the "C" locale.
8646]</i></p>
8647
8648<p><i>[
8649A survey of existing practice is needed; it is believed that some
8650implementations do insert thousands_sep characters for floating-point
8651output and others fail to insert thousands_sep characters for
8652floating-point input even though this is unambiguously required by the
8653standard.
8654]</i></p>
8655
8656<p><i>[Post-Cura�ao: the above proposed resolution is the consensus of
8657Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
8658
8659<hr>
8660<a name="283"><h3>283.&nbsp;std::replace() requirement incorrect/insufficient</h3></a><p><b>Section:</b>&nbsp;25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Dec 2000</p>
8661<p>
8662(revision of the further discussion)
8663There are a number of problems with the requires clauses for the
8664algorithms in 25.1 and 25.2. The requires clause of each algorithm
8665should describe the necessary and sufficient requirements on the inputs
8666to the algorithm such that the algorithm compiles and runs properly.
8667Many of the requires clauses fail to do this. Here is a summary of the kinds
8668of mistakes:
8669</p>
8670
8671<ol>
8672<li>
8673Use of EqualityComparable, which only puts requirements on a single
8674type, when in fact an equality operator is required between two
8675different types, typically either T and the iterator's value type
8676or between the value types of two different iterators.
8677</li>
8678<li>
8679Use of Assignable for T when in fact what was needed is Assignable
8680for the value_type of the iterator, and convertability from T to the
8681value_type of the iterator. Or for output iterators, the requirement
8682should be that T is writable to the iterator (output iterators do
8683not have value types).
8684</li>
8685</ol>
8686
8687<p>
8688Here is the list of algorithms that contain mistakes:
8689</p>
8690
8691<ul>
8692<li>25.1.2 std::find</li>
8693<li>25.1.6 std::count</li>
8694<li>25.1.8 std::equal</li>
8695<li>25.1.9 std::search, std::search_n</li>
8696<li>25.2.4 std::replace, std::replace_copy</li>
8697<li>25.2.5 std::fill</li>
8698<li>25.2.7 std::remove, std::remove_copy</li>
8699</ul>
8700
8701<p>
8702Also, in the requirements for EqualityComparable, the requirement that
8703the operator be defined for const objects is lacking.
8704</p>
8705
8706<p><b>Proposed resolution:</b></p>
8707
8708<p>20.1.1 Change p1 from</p>
8709
8710<p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8711instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8712values of type <tt>T</tt>.
8713</p>
8714
8715<p>to</p>
8716
8717<p>
8718In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8719instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8720values of type <tt>const T</tt>.
8721</p>
8722
8723<p>25 Between p8 and p9</p>
8724
8725<p>Add the following sentence:</p>
8726
8727<p>When the description of an algorithm gives an expression such as
8728<tt>*first == value</tt> for a condition, it is required that the expression
8729evaluate to either true or false in boolean contexts.</p>
8730
8731<p>25.1.2 Change p1 by deleting the requires clause.</p>
8732
8733<p>25.1.6 Change p1 by deleting the requires clause.</p>
8734
8735<p>25.1.9</p>
8736
8737<p>Change p4 from</p>
8738
8739<p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
8740(20.1.1), type Size is convertible to integral type (4.7.12.3).
8741</p>
8742
8743<p>to</p>
8744
8745<p>-4- Requires: The type <tt>Size</tt> is convertible to integral
8746type (4.7.12.3).</p>
8747
8748<p>25.2.4 Change p1 from</p>
8749
8750<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>
8751
8752<p>to</p>
8753
8754<p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
8755
8756<p>and change p4 from</p>
8757
8758<p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
8759for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
8760(20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
8761(last - first))</tt> shall not overlap.</p>
8762
8763<p>to</p>
8764
8765<p>-4- Requires: The results of the expressions <tt>*first</tt> and
8766<tt>new_value</tt> must be writable to the result output iterator. The
8767ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
8768first))</tt> shall not overlap.</p>
8769
8770
8771<p>25.2.5 Change p1 from</p>
8772
8773<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
8774type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
8775
8776<p>to</p>
8777
8778<p>-1- Requires: The expression <tt>value</tt> must be is writable to
8779the output iterator. The type <tt>Size</tt> is convertible to an
8780integral type (4.7.12.3).</p>
8781
8782<p>25.2.7 Change p1 from</p>
8783
8784<p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
8785
8786<p>to</p>
8787
8788<p>
8789-1- Requires: The value type of the iterator must be
8790<tt>Assignable</tt> (23.1).
8791</p>
8792
8793<p><b>Rationale:</b></p>
8794<p>
8795The general idea of the proposed solution is to remove the faulty
8796requires clauses and let the returns and effects clauses speak for
8797themselves. That is, the returns clauses contain expressions that must
8798be valid, and therefore already imply the correct requirements. In
8799addition, a sentence is added at the beginning of chapter 25 saying
8800that expressions given as conditions must evaluate to true or false in
8801a boolean context. An alternative would be to say that the type of
8802these condition expressions must be literally bool, but that would be
8803imposing a greater restriction that what the standard currently says
8804(which is convertible to bool).
8805</p>
8806<hr>
8807<a name="284"><h3>284.&nbsp;unportable example in 20.3.7, p6</h3></a><p><b>Section:</b>&nbsp;20.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;26 Dec 2000</p>
8808<p>The example in 20.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a>, p6 shows how to use the C
8809library function <tt>strcmp()</tt> with the function pointer adapter
8810<tt>ptr_fun()</tt>. But since it's unspecified whether the C library
8811functions have <tt>extern "C"</tt> or <tt>extern
8812"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
8813function pointers with different the language linkage specifications
8814(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
8815well-formed is unspecified.
8816</p>
8817<p><b>Proposed resolution:</b></p>
8818<p>Change 20.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a> paragraph 6 from:</p>
8819<blockquote>
8820  <p>[<i>Example:</i></p>
8821  <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
8822  </pre>
8823  <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
8824</blockquote>
8825
8826
8827<p>to:</p>
8828<blockquote>
8829  <p>[<i>Example:</i></p>
8830  <pre>    int compare(const char*, const char*);
8831    replace_if(v.begin(), v.end(),
8832               not1(bind2nd(ptr_fun(compare), "abc")), "def");
8833  </pre>
8834  <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
8835</blockquote>
8836
8837<p>Also, remove footnote 215 in that same paragraph.</p>
8838
8839<p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
8840issue deals in part with C and C++ linkage, it was believed to be too
8841confusing for the strings in the example to be "C" and "C++".
8842]</i></p>
8843
8844<p><i>[Redmond: More minor changes.  Got rid of the footnote (which
8845seems to make a sweeping normative requirement, even though footnotes
8846aren't normative), and changed the sentence after the footnote so that
8847it corresponds to the new code fragment.]</i></p>
8848
8849<hr>
8850<a name="285"><h3>285.&nbsp;minor editorial errors in fstream ctors</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;31 Dec 2000</p>
8851<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
885227.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:
8853</p>
8854
8855<p>... If that function returns a null pointer, calls
8856<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
8857</p>
8858
8859<p>The parenthetical note doesn't apply since the ctors cannot throw an
8860exception 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
8861that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
8862</p>
8863<p><b>Proposed resolution:</b></p>
8864<p>
8865Strike the parenthetical note from the Effects clause in each of the
8866paragraphs mentioned above.
8867</p>
8868<hr>
8869<a name="286"><h3>286.&nbsp;&lt;cstdlib&gt; requirements missing size_t typedef</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;30 Dec 2000</p>
8870<p>
8871The &lt;cstdlib&gt; header file contains prototypes for bsearch and
8872qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
8873prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
8874require the typedef size_t. Yet size_t is not listed in the
8875&lt;cstdlib&gt; synopsis table 78 in section 25.4.
8876</p>
8877<p><b>Proposed resolution:</b></p>
8878<p>
8879Add the type size_t to Table 78 (section 25.4) and add
8880the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
8881</p>
8882<p><b>Rationale:</b></p>
8883<p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
8884<hr>
8885<a name="288"><h3>288.&nbsp;&lt;cerrno&gt; requirements missing macro EILSEQ</h3></a><p><b>Section:</b>&nbsp;19.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;30 Dec 2000</p>
8886<p>
8887ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
8888of macros defined in &lt;errno.h&gt; is adjusted to include a new
8889macro, EILSEQ"
8890</p>
8891
8892<p>
8893ISO/IEC 14882:1998(E) section 19.3 does not refer
8894to the above amendment.
8895</p>
8896
8897<p><b>Proposed resolution:</b></p>
8898<p>
8899Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
8900and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
8901</p>
8902<hr>
8903<a name="291"><h3>291.&nbsp;Underspecification of set algorithms</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
8904<p>
8905The standard library contains four algorithms that compute set
8906operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
8907<tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
8908of these algorithms takes two sorted ranges as inputs, and writes the
8909output of the appropriate set operation to an output range.  The elements
8910in the output range are sorted.
8911</p>
8912
8913<p>
8914The ordinary mathematical definitions are generalized so that they
8915apply to ranges containing multiple copies of a given element.  Two
8916elements are considered to be "the same" if, according to an
8917ordering relation provided by the user, neither one is less than the
8918other.  So, for example, if one input range contains five copies of an
8919element and another contains three, the output range of <tt>set_union</tt>
8920will contain five copies, the output range of
8921<tt>set_intersection</tt> will contain three, the output range of
8922<tt>set_difference</tt> will contain two, and the output range of
8923<tt>set_symmetric_difference</tt> will contain two.
8924</p>
8925
8926<p>
8927Because two elements can be "the same" for the purposes
8928of these set algorithms, without being identical in other respects
8929(consider, for example, strings under case-insensitive comparison),
8930this raises a number of unanswered questions:
8931</p>
8932
8933<ul>
8934<li>If we're copying an element that's present in both of the
8935input ranges, which one do we copy it from?</li>
8936<li>If there are <i>n</i> copies of an element in the relevant
8937input range, and the output range will contain fewer copies (say
8938<i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
8939<i>m</i>, or something else?</li>
8940<li>Are these operations stable?  That is, does a run of equivalent
8941elements appear in the output range in the same order as as it
8942appeared in the input range(s)?</li>
8943</ul>
8944
8945<p>
8946The standard should either answer these questions, or explicitly
8947say that the answers are unspecified.  I prefer the former option,
8948since, as far as I know, all existing implementations behave the
8949same way.
8950</p>
8951
8952<p><b>Proposed resolution:</b></p>
8953
8954<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>
8955<blockquote>
8956If [first1, last1) contains <i>m</i> elements that are equivalent to
8957each other and [first2, last2) contains <i>n</i> elements that are
8958equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
8959will be copied to the output range: all <i>m</i> of these elements
8960from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
8961[first2, last2), in that order.
8962</blockquote>
8963
8964<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>
8965<blockquote>
8966If [first1, last1) contains <i>m</i> elements that are equivalent to each
8967other and [first2, last2) contains <i>n</i> elements that are
8968equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
8969elements from [first1, last1) are copied to the output range.
8970</blockquote>
8971
8972<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>
8973paragraph 4:</p>
8974<blockquote>
8975If [first1, last1) contains <i>m</i> elements that are equivalent to each
8976other and [first2, last2) contains <i>n</i> elements that are
8977equivalent to them, the last max(<i>m-n</i>, 0) elements from
8978[first1, last1) are copied to the output range.
8979</blockquote>
8980
8981<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>
8982paragraph 4:</p>
8983<blockquote>
8984If [first1, last1) contains <i>m</i> elements that are equivalent to
8985each other and [first2, last2) contains <i>n</i> elements that are
8986equivalent to them, then |<i>m - n</i>| of those elements will be
8987copied to the output range: the last <i>m - n</i> of these elements
8988from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
8989m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
8990</blockquote>
8991
8992<p><i>[Santa Cruz: it's believed that this language is clearer than
8993  what's in the Standard.  However, it's also believed that the
8994  Standard may already make these guarantees (although not quite in
8995  these words).  Bill and Howard will check and see whether they think
8996  that some or all of these changes may be redundant.  If so, we may
8997  close this issue as NAD.]</i></p>
8998
8999<p><b>Rationale:</b></p>
9000<p>For simple cases, these descriptions are equivalent to what's
9001  already in the Standard.  For more complicated cases, they describe
9002  the behavior of existing implementations.</p>
9003<hr>
9004<a name="292"><h3>292.&nbsp;effects of a.copyfmt (a)</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;05 Jan 2001</p>
9005<p>The Effects clause of the member function <tt>copyfmt()</tt> in
900627.4.4.2, p15 doesn't consider the case where the left-hand side
9007argument is identical to the argument on the right-hand side, that is
9008<tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
9009is no need to copy any of the data members or call any callbacks
9010registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
9011points out in message c++std-lib-8149 it appears to be incorrect to
9012allow the object to fire <tt>erase_event</tt> followed by
9013<tt>copyfmt_event</tt> since the callback handling the latter event
9014may inadvertently attempt to access memory freed by the former.
9015</p>
9016<p><b>Proposed resolution:</b></p>
9017<p>Change the Effects clause in 27.4.4.2, p15 from</p>
9018
9019<blockquote>
9020<b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
9021the corresponding member objects of <tt>rhs</tt>, except that...
9022</blockquote>
9023
9024<p>to</p>
9025
9026<blockquote>
9027<b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
9028assigns to the member objects of <tt>*this</tt> the corresponding member
9029objects of <tt>rhs</tt>, except that...
9030</blockquote>
9031<hr>
9032<a name="294"><h3>294.&nbsp;User defined macros and standard headers</h3></a><p><b>Section:</b>&nbsp;17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
9033<p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A
9034translation unit that includes a header shall not contain any macros
9035that define names declared in that header." As I read this, it
9036would mean that the following program is legal:</p>
9037
9038<pre>  #define npos 3.14
9039  #include &lt;sstream&gt;
9040</pre>
9041
9042<p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
9043in &lt;string&gt;, and it is hard to imagine an implementation in
9044which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
9045
9046<p>I think that this phrase was probably formulated before it was
9047decided that a standard header may freely include other standard
9048headers.  The phrase would be perfectly appropriate for C, for
9049example.  In light of 17.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
9050it isn't stringent enough.</p>
9051<p><b>Proposed resolution:</b></p>
9052<p>For 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, replace the current wording, which reads:</p>
9053<blockquote>
9054     <p>Each name defined as a macro in a header is reserved to the
9055     implementation for any use if the translation unit includes
9056     the header.168)</p>
9057
9058     <p>A translation unit that includes a header shall not contain any
9059     macros that define names declared or defined in that header. Nor shall
9060     such a translation unit define macros for names lexically
9061     identical to keywords.</p>
9062
9063     <p>168) It is not permissible to remove a library macro definition by
9064     using the #undef directive.</p>
9065</blockquote>
9066
9067<p>with the wording:</p>
9068
9069<blockquote>
9070     <p>A translation unit that includes a standard library header shall not
9071     #define or #undef names declared in any standard library header.</p>
9072
9073     <p>A translation unit shall not #define or #undef names lexically
9074     identical to keywords.</p>
9075</blockquote>
9076
9077<p><i>[Lillehammer: Beman provided new wording]</i></p>
9078
9079<hr>
9080<a name="295"><h3>295.&nbsp;Is abs defined in &lt;cmath&gt;?</h3></a><p><b>Section:</b>&nbsp;26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jens Maurer&nbsp; <b>Date:</b>&nbsp;12 Jan 2001</p>
9081<p>
9082Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
9083list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added
9084signatures present in &lt;cmath&gt;, does say that several overloads
9085of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
9086</p>
9087<p><b>Proposed resolution:</b></p>
9088<p>
9089Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
9090of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a>,
9091paragraph 1.
9092</p>
9093
9094<p><i>[Copenhagen: Modified proposed resolution so that it also gets
9095rid of that vestigial list of functions in paragraph 1.]</i></p>
9096
9097<p><b>Rationale:</b></p>
9098<p>All this DR does is fix a typo; it's uncontroversial.  A
9099separate question is whether we're doing the right thing in
9100putting some overloads in &lt;cmath&gt; that we aren't also
9101putting in &lt;cstdlib&gt;.  That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p>
9102<hr>
9103<a name="297"><h3>297.&nbsp;const_mem_fun_t&lt;&gt;::argument_type should be const T*</h3></a><p><b>Section:</b>&nbsp;20.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.logical.operations"> [lib.logical.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Jan 2001</p>
9104<p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and
9105<tt>const_mem_fun1_t</tt>
9106in 20.5.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
9107<tt>binary_function&lt;T*,
9108A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
9109<tt>first_argument_type</tt>
9110members, respectively, are both defined to be <tt>T*</tt> (non-const).
9111However, their function call member operator takes a <tt>const T*</tt>
9112argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
9113T*</tt> instead, so that one can easily refer to it in generic code. The
9114example below derived from existing code fails to compile due to the
9115discrepancy:
9116</p>
9117
9118<p><tt>template &lt;class T&gt;</tt>
9119<br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
9120<br><tt>{</tt>
9121<br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
9122T::argument_type)
9123const =&nbsp;&nbsp; // #2</tt>
9124<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
9125<br><tt>}</tt>
9126</p>
9127
9128<p><tt>struct X { /* ... */ };</tt></p>
9129
9130<p><tt>int main ()</tt>
9131<br><tt>{</tt>
9132<br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
9133<br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
9134&gt;(&amp;x);&nbsp;&nbsp;
9135// #3</tt>
9136<br><tt>}</tt>
9137</p>
9138
9139<p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
9140<br>#2 the type of the pointer is incompatible with the type of the member
9141function
9142<br>#3 the address of a constant being passed to a function taking a non-const
9143<tt>X*</tt>
9144</p>
9145<p><b>Proposed resolution:</b></p>
9146<p>Replace the top portion of the definition of the class template
9147const_mem_fun_t in 20.5.8, p8
9148</p>
9149<p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
9150<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9151unary_function&lt;T*, S&gt; {</tt>
9152</p>
9153<p>with</p>
9154<p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
9155<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9156unary_function&lt;<b>const</b> T*, S&gt; {</tt>
9157</p>
9158<p>Also replace the top portion of the definition of the class template
9159const_mem_fun1_t in 20.5.8, p9</p>
9160<p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
9161<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9162binary_function&lt;T*, A, S&gt; {</tt>
9163</p>
9164<p>with</p>
9165<p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
9166<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9167binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
9168</p>
9169<p><b>Rationale:</b></p>
9170<p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
9171and the argument type itself, are not the same.</p>
9172<hr>
9173<a name="298"><h3>298.&nbsp;::operator delete[] requirement incorrect/insufficient</h3></a><p><b>Section:</b>&nbsp;18.5.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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John A. Pedretti&nbsp; <b>Date:</b>&nbsp;10 Jan 2001</p>
9174<p>
9175The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 -
9176namely that for non-null value of <i>ptr</i>, the operator reclaims storage
9177allocated by the earlier call to the default <tt>operator new[]</tt> - is not
9178correct in all cases. Since the specified <tt>operator new[]</tt> default
9179behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be
9180replaced, along with <tt>operator delete</tt>, by the user, to implement their
9181own memory management, the specified default behavior of<tt> operator
9182delete[]</tt> must be to call <tt>operator delete</tt>.
9183</p>
9184<p><b>Proposed resolution:</b></p>
9185<p>Change 18.5.1.2, p12 from</p>
9186<blockquote>
9187<b>-12-</b> <b>Default behavior:</b>
9188<ul>
9189<li>
9190For a null value of <i><tt>ptr</tt></i> , does nothing.
9191</li>
9192<li>
9193Any other value of <i><tt>ptr</tt></i> shall be a value returned
9194earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
9195[Footnote: The value must not have been invalidated by an intervening
9196call 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>).
9197--- end footnote]
9198For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
9199allocated by the earlier call to the default <tt>operator new[]</tt>.
9200</li>
9201</ul>
9202</blockquote>
9203
9204<p>to</p>
9205
9206<blockquote>
9207<b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
9208delete(</tt><i>ptr</i>)
9209or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
9210</blockquote>
9211<p>and expunge paragraph 13.</p>
9212<hr>
9213<a name="300"><h3>300.&nbsp;list::merge() specification incomplete</h3></a><p><b>Section:</b>&nbsp;23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Pedretti&nbsp; <b>Date:</b>&nbsp;23 Jan 2001</p>
9214<p>
9215The "Effects" clause for list::merge() (23.2.2.4, p23)
9216appears to be incomplete: it doesn't cover the case where the argument
9217list is identical to *this (i.e., this == &amp;x). The requirement in the
9218note in p24 (below) is that x be empty after the merge which is surely
9219unintended in this case.
9220</p>
9221<p><b>Proposed resolution:</b></p>
9222<p>In 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, replace paragraps 23-25 with:</p>
9223<blockquote>
9224<p>
922523 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
9226sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
9227is a range in which the elements will be sorted in non-decreasing
9228order according to the ordering defined by comp; that is, for every
9229iterator i in the range other than the first, the condition comp(*i,
9230*(i - 1)) will be false.
9231</p>
9232
9233<p>
923424 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
9235two original ranges, the elements from the original range [begin(),
9236end()) always precede the elements from the original range [x.begin(),
9237x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
9238after the merge.
9239</p>
9240
9241<p>
924225 Complexity: At most size() + x.size() - 1 applications of comp if
9243(&amp;x !  = this); otherwise, no applications of comp are performed.  If
9244an exception is thrown other than by a comparison there are no
9245effects.
9246</p>
9247
9248</blockquote>
9249
9250<p><i>[Copenhagen: The original proposed resolution did not fix all of
9251the problems in 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, p22-25.  Three different
9252paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
9253Changing p23, without changing the other two, appears to introduce
9254contradictions.  Additionally, "merges the argument list into the
9255list" is excessively vague.]</i></p>
9256
9257<p><i>[Post-Cura�ao: Robert Klarer provided new wording.]</i></p>
9258
9259<hr>
9260<a name="301"><h3>301.&nbsp;basic_string template ctor effects clause omits allocator argument</h3></a><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Jan 2001</p>
9261<p>
9262The effects clause for the basic_string template ctor in 21.3.1, p15
9263leaves out the third argument of type Allocator. I believe this to be
9264a mistake.
9265</p>
9266<p><b>Proposed resolution:</b></p>
9267<p>Replace</p>
9268
9269<blockquote>
9270    <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
9271    type, equivalent to</p>
9272
9273    <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
9274    static_cast&lt;value_type&gt;(end))</tt></blockquote>
9275</blockquote>
9276
9277<p>with</p>
9278
9279<blockquote>
9280    <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
9281    type, equivalent to</p>
9282
9283    <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
9284    static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></blockquote>
9285</blockquote>
9286<hr>
9287<a name="303"><h3>303.&nbsp;Bitset input operator underspecified</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;5 Feb 2001</p>
9288<p>
9289In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
9290"Extracts up to <i>N</i> (single-byte) characters from
9291<i>is</i>.", where <i>is</i> is a stream of type
9292<tt>basic_istream&lt;charT, traits&gt;</tt>.
9293</p>
9294
9295<p>
9296The standard does not say what it means to extract single byte
9297characters from a stream whose character type, <tt>charT</tt>, is in
9298general not a single-byte character type.  Existing implementations
9299differ.
9300</p>
9301
9302<p>
9303A reasonable solution will probably involve <tt>widen()</tt> and/or
9304<tt>narrow()</tt>, since they are the supplied mechanism for
9305converting a single character between <tt>char</tt> and
9306arbitrary <tt>charT</tt>.
9307</p>
9308
9309<p>Narrowing the input characters is not the same as widening the
9310literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
9311locales in which more than one wide character maps to the narrow
9312character <tt>'0'</tt>.  Narrowing means that alternate
9313representations may be used for bitset input, widening means that
9314they may not be.</p>
9315
9316<p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
9317(22.2.2.1.2/8) compares input characters to widened version of narrow
9318character literals.</p>
9319
9320<p>From Pete Becker, in c++std-lib-8224:</p>
9321<blockquote>
9322<p>
9323Different writing systems can have different representations for the
9324digits that represent 0 and 1. For example, in the Unicode representation
9325of the Devanagari script (used in many of the Indic languages) the digit 0
9326is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
9327into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
93280x0031 for for the Latin representations of '0' and '1', as well as code
9329points for the same numeric values in several other scripts (Tamil has no
9330character for 0, but does have the digits 1-9), and any of these values
9331would also be narrowed to '0' and '1'.
9332</p>
9333
9334<p>...</p>
9335
9336<p>
9337It's fairly common to intermix both native and Latin
9338representations of numbers in a document. So I think the rule has to be
9339that if a wide character represents a digit whose value is 0 then the bit
9340should be cleared; if it represents a digit whose value is 1 then the bit
9341should be set; otherwise throw an exception. So in a Devanagari locale,
9342both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
9343would set it. Widen can't do that. It would pick one of those two values,
9344and exclude the other one.
9345</p>
9346
9347</blockquote>
9348
9349<p>From Jens Maurer, in c++std-lib-8233:</p>
9350
9351<blockquote>
9352<p>
9353Whatever we decide, I would find it most surprising if
9354bitset conversion worked differently from int conversion
9355with regard to alternate local representations of
9356numbers.
9357</p>
9358
9359<p>Thus, I think the options are:</p>
9360<ul>
9361 <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
9362require the use of narrow().</li>
9363
9364 <li> Have a defect issue for bitset() which describes clearly
9365that widen() is to be used.</li>
9366</ul>
9367</blockquote>
9368<p><b>Proposed resolution:</b></p>
9369
9370    <p>Replace the first two sentences of paragraph 5 with:</p>
9371
9372    <blockquote>
9373    Extracts up to <i>N</i> characters from <i>is</i>. Stores these
9374    characters in a temporary object <i>str</i> of type
9375    <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
9376    expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
9377    </blockquote>
9378
9379    <p>Replace the third bullet item in paragraph 5 with:</p>
9380    <ul><li>
9381    the next input character is neither <tt><i>is</i>.widen(0)</tt>
9382    nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
9383    is not extracted).
9384    </li></ul>
9385
9386<p><b>Rationale:</b></p>
9387<p>Input for <tt>bitset</tt> should work the same way as numeric
9388input.  Using <tt>widen</tt> does mean that alternative digit
9389representations will not be recognized, but this was a known
9390consequence of the design choice.</p>
9391<hr>
9392<a name="305"><h3>305.&nbsp;Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;24 Jan 2001</p>
9393<p>22.2.1.5/3 introduces codecvt in part with:</p>
9394
9395<blockquote>
9396  codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
9397  character sets for tiny and wide characters. Instantiations on
9398  mbstate_t perform conversion between encodings known to the library
9399  implementor.
9400</blockquote>
9401
9402<p>But 22.2.1.5.2/10 describes do_length in part with:</p>
9403
9404<blockquote>
9405  ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
9406  (from_end-from).
9407</blockquote>
9408
9409<p>
9410The semantics of do_in and do_length are linked.  What one does must
9411be consistent with what the other does.  22.2.1.5/3 leads me to
9412believe that the vendor is allowed to choose the algorithm that
9413codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
9414his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
9415says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
9416return.  And thus indirectly specifies the algorithm that
9417codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
9418that this is not what was intended and is a defect.
9419</p>
9420
9421<p>Discussion from the -lib reflector:
9422
9423<br>This proposal would have the effect of making the semantics of
9424all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
9425mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
9426do we want to mandate specific behavior for the base class virtuals
9427and leave the implementation specified behavior for the codecvt_byname
9428derived class?  The tradeoff is that former allows implementors to
9429write a base class that actually does something useful, while the
9430latter gives users a way to get known and specified---albeit
9431useless---behavior, and is consistent with the way the standard
9432handles other facets.  It is not clear what the original intention
9433was.</p>
9434
9435<p>
9436Nathan has suggest a compromise: a character that is a widened version
9437of the characters in the basic execution character set must be
9438converted to a one-byte sequence, but there is no such requirement
9439for characters that are not part of the basic execution character set.
9440</p>
9441<p><b>Proposed resolution:</b></p>
9442<p>
9443Change 22.2.1.5.2/5 from:
9444</p>
9445<p>
9446The instantiations required in Table 51 (lib.locale.category), namely
9447codecvt&lt;wchar_t,char,mbstate_t&gt; and
9448codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
9449than (to_limit-to) destination elements. It always leaves the to_next
9450pointer pointing one beyond the last element successfully stored.
9451</p>
9452<p>
9453to:
9454</p>
9455<p>
9456Stores no more than (to_limit-to) destination elements, and leaves the
9457to_next pointer pointing one beyond the last element successfully
9458stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
9459</p>
9460
9461<p>Change 22.2.1.5.2/10 from:</p>
9462
9463<blockquote>
9464-10- Returns: (from_next-from) where from_next is the largest value in
9465the range [from,from_end] such that the sequence of values in the
9466range [from,from_next) represents max or fewer valid complete
9467characters of type internT. The instantiations required in Table 51
9468(21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
9469codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
9470(from_end-from).
9471</blockquote>
9472
9473<p>to:</p>
9474
9475<blockquote>
9476-10- Returns: (from_next-from) where from_next is the largest value in
9477the range [from,from_end] such that the sequence of values in the range
9478[from,from_next) represents max or fewer valid complete characters of
9479type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
9480the lesser of max and (from_end-from).
9481</blockquote>
9482
9483<p><i>[Redmond: Nathan suggested an alternative resolution: same as
9484above, but require that, in the default encoding, a character from the
9485basic execution character set would map to a single external
9486character.  The straw poll was 8-1 in favor of the proposed
9487resolution.]</i></p>
9488
9489<p><b>Rationale:</b></p>
9490<p>The default encoding should be whatever users of a given platform
9491would expect to be the most natural.  This varies from platform to
9492platform.  In many cases there is a preexisting C library, and users
9493would expect the default encoding to be whatever C uses in the default
9494"C" locale.  We could impose a guarantee like the one Nathan suggested
9495(a character from the basic execution character set must map to a
9496single external character), but this would rule out important
9497encodings that are in common use: it would rule out JIS, for
9498example, and it would rule out a fixed-width encoding of UCS-4.</p>
9499
9500<p><i>[Cura�ao: fixed rationale typo at the request of Ichiro Koshida;
9501"shift-JIS" changed to "JIS".]</i></p>
9502
9503<hr>
9504<a name="306"><h3>306.&nbsp;offsetof macro and non-POD types</h3></a><p><b>Section:</b>&nbsp;18.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Feb 2001</p>
9505<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
9506
9507<p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
9508accepts a restricted set of <i>type</i> arguments in this
9509International Standard. <i>type</i> shall be a POD structure or a POD
9510union (clause 9). The result of applying the offsetof macro to a field
9511that is a static data member or a function member is
9512undefined."</p>
9513
9514<p>For the POD requirement, it doesn't say "no diagnostic
9515required" 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.
9516It's not clear whether this requirement was intended.  While it's
9517possible to provide such a diagnostic, the extra complication doesn't
9518seem to add any value.
9519</p>
9520<p><b>Proposed resolution:</b></p>
9521<p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
9522structure or a POD union the results are undefined."</p>
9523
9524<p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
9525agreed that requiring a diagnostic was inadvertent, but some LWG
9526members thought that diagnostics should be required whenever
9527possible.]</i></p>
9528
9529<hr>
9530<a name="307"><h3>307.&nbsp;Lack of reference typedefs in container adaptors</h3></a><p><b>Section:</b>&nbsp;23.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list"> [lib.list]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2001</p>
9531
9532<p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
9533
9534<p>
9535The standard is currently inconsistent in 23.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a>
9536paragraph 1 and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.modifiers]</a> paragraph 1.
953723.2.3.3/1, for example, says:
9538</p>
9539
9540<blockquote>
9541-1- Any sequence supporting operations back(), push_back() and pop_back()
9542can be used to instantiate stack. In particular, vector (lib.vector), list
9543(lib.list) and deque (lib.deque) can be used.
9544</blockquote>
9545
9546<p>But this is false: vector&lt;bool&gt; can not be used, because the
9547container adaptors return a T&amp; rather than using the underlying
9548container's reference type.</p>
9549
9550<p>This is a contradiction that can be fixed by:</p>
9551
9552<ol>
9553<li>Modifying these paragraphs to say that vector&lt;bool&gt;
9554    is an exception.</li>
9555<li>Removing the vector&lt;bool&gt; specialization.</li>
9556<li>Changing the return types of stack and priority_queue to use
9557    reference typedef's.</li>
9558</ol>
9559
9560<p>
9561I propose 3.  This does not preclude option 2 if we choose to do it
9562later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>); the issues are independent.  Option
95633 offers a small step towards support for proxied containers.  This
9564small step fixes a current contradiction, is easy for vendors to
9565implement, is already implemented in at least one popular lib, and
9566does not break any code.
9567</p>
9568
9569<p><b>Proposed resolution:</b></p>
9570<p>Summary: Add reference and const_reference typedefs to queue,
9571priority_queue and stack.  Change return types of "value_type&amp;" to
9572"reference".  Change return types of "const value_type&amp;" to
9573"const_reference".  Details:</p>
9574
9575<p>Change 23.2.3.1/1 from:</p>
9576
9577<pre>  namespace std {
9578    template &lt;class T, class Container = deque&lt;T&gt; &gt;
9579    class queue {
9580    public:
9581      typedef typename Container::value_type            value_type;
9582      typedef typename Container::size_type             size_type;
9583      typedef          Container                        container_type;
9584    protected:
9585      Container c;
9586
9587    public:
9588      explicit queue(const Container&amp; = Container());
9589
9590      bool      empty() const             { return c.empty(); }
9591      size_type size()  const             { return c.size(); }
9592      value_type&amp;       front()           { return c.front(); }
9593      const value_type&amp; front() const     { return c.front(); }
9594      value_type&amp;       back()            { return c.back(); }
9595      const value_type&amp; back() const      { return c.back(); }
9596      void push(const value_type&amp; x)      { c.push_back(x); }
9597      void pop()                          { c.pop_front(); }
9598    };
9599</pre>
9600
9601<p>to:</p>
9602
9603<pre>  namespace std {
9604    template &lt;class T, class Container = deque&lt;T&gt; &gt;
9605    class queue {
9606    public:
9607      typedef typename Container::value_type            value_type;
9608      typedef typename Container::reference             reference;
9609      typedef typename Container::const_reference       const_reference;
9610      typedef typename Container::value_type            value_type;
9611      typedef typename Container::size_type             size_type;
9612      typedef          Container                        container_type;
9613    protected:
9614      Container c;
9615
9616    public:
9617      explicit queue(const Container&amp; = Container());
9618
9619      bool      empty() const             { return c.empty(); }
9620      size_type size()  const             { return c.size(); }
9621      reference         front()           { return c.front(); }
9622      const_reference   front() const     { return c.front(); }
9623      reference         back()            { return c.back(); }
9624      const_reference   back() const      { return c.back(); }
9625      void push(const value_type&amp; x)      { c.push_back(x); }
9626      void pop()                          { c.pop_front(); }
9627    };
9628</pre>
9629
9630<p>Change 23.2.3.2/1 from:</p>
9631
9632<pre>  namespace std {
9633    template &lt;class T, class Container = vector&lt;T&gt;,
9634              class Compare = less&lt;typename Container::value_type&gt; &gt;
9635    class priority_queue {
9636    public:
9637      typedef typename Container::value_type            value_type;
9638      typedef typename Container::size_type             size_type;
9639      typedef          Container                        container_type;
9640    protected:
9641      Container c;
9642      Compare comp;
9643
9644    public:
9645      explicit priority_queue(const Compare&amp; x = Compare(),
9646                              const Container&amp; = Container());
9647      template &lt;class InputIterator&gt;
9648        priority_queue(InputIterator first, InputIterator last,
9649                       const Compare&amp; x = Compare(),
9650                       const Container&amp; = Container());
9651
9652      bool      empty() const       { return c.empty(); }
9653      size_type size()  const       { return c.size(); }
9654      const value_type&amp; top() const { return c.front(); }
9655      void push(const value_type&amp; x);
9656      void pop();
9657    };
9658                                  //  no equality is provided
9659  }
9660</pre>
9661
9662<p>to:</p>
9663
9664<pre>  namespace std {
9665    template &lt;class T, class Container = vector&lt;T&gt;,
9666              class Compare = less&lt;typename Container::value_type&gt; &gt;
9667    class priority_queue {
9668    public:
9669      typedef typename Container::value_type            value_type;
9670      typedef typename Container::reference             reference;
9671      typedef typename Container::const_reference       const_reference;
9672      typedef typename Container::size_type             size_type;
9673      typedef          Container                        container_type;
9674    protected:
9675      Container c;
9676      Compare comp;
9677
9678    public:
9679      explicit priority_queue(const Compare&amp; x = Compare(),
9680                              const Container&amp; = Container());
9681      template &lt;class InputIterator&gt;
9682        priority_queue(InputIterator first, InputIterator last,
9683                       const Compare&amp; x = Compare(),
9684                       const Container&amp; = Container());
9685
9686      bool      empty() const       { return c.empty(); }
9687      size_type size()  const       { return c.size(); }
9688      const_reference   top() const { return c.front(); }
9689      void push(const value_type&amp; x);
9690      void pop();
9691    };
9692                                  //  no equality is provided
9693  }
9694</pre>
9695
9696<p>And change 23.2.3.3/1 from:</p>
9697
9698<pre>  namespace std {
9699    template &lt;class T, class Container = deque&lt;T&gt; &gt;
9700    class stack {
9701    public:
9702      typedef typename Container::value_type            value_type;
9703      typedef typename Container::size_type             size_type;
9704      typedef          Container                        container_type;
9705    protected:
9706      Container c;
9707
9708    public:
9709      explicit stack(const Container&amp; = Container());
9710
9711      bool      empty() const             { return c.empty(); }
9712      size_type size()  const             { return c.size(); }
9713      value_type&amp;       top()             { return c.back(); }
9714      const value_type&amp; top() const       { return c.back(); }
9715      void push(const value_type&amp; x)      { c.push_back(x); }
9716      void pop()                          { c.pop_back(); }
9717    };
9718
9719    template &lt;class T, class Container&gt;
9720      bool operator==(const stack&lt;T, Container&gt;&amp; x,
9721                      const stack&lt;T, Container&gt;&amp; y);
9722    template &lt;class T, class Container&gt;
9723      bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9724                      const stack&lt;T, Container&gt;&amp; y);
9725    template &lt;class T, class Container&gt;
9726      bool operator!=(const stack&lt;T, Container&gt;&amp; x,
9727                      const stack&lt;T, Container&gt;&amp; y);
9728    template &lt;class T, class Container&gt;
9729      bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
9730                      const stack&lt;T, Container&gt;&amp; y);
9731    template &lt;class T, class Container&gt;
9732      bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
9733                      const stack&lt;T, Container&gt;&amp; y);
9734    template &lt;class T, class Container&gt;
9735      bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
9736                      const stack&lt;T, Container&gt;&amp; y);
9737  }
9738</pre>
9739
9740<p>to:</p>
9741
9742<pre>  namespace std {
9743    template &lt;class T, class Container = deque&lt;T&gt; &gt;
9744    class stack {
9745    public:
9746      typedef typename Container::value_type            value_type;
9747      typedef typename Container::reference             reference;
9748      typedef typename Container::const_reference       const_reference;
9749      typedef typename Container::size_type             size_type;
9750      typedef          Container                        container_type;
9751    protected:
9752      Container c;
9753
9754    public:
9755      explicit stack(const Container&amp; = Container());
9756
9757      bool      empty() const             { return c.empty(); }
9758      size_type size()  const             { return c.size(); }
9759      reference         top()             { return c.back(); }
9760      const_reference   top() const       { return c.back(); }
9761      void push(const value_type&amp; x)      { c.push_back(x); }
9762      void pop()                          { c.pop_back(); }
9763    };
9764
9765    template &lt;class T, class Container&gt;
9766      bool operator==(const stack&lt;T, Container&gt;&amp; x,
9767                      const stack&lt;T, Container&gt;&amp; y);
9768    template &lt;class T, class Container&gt;
9769      bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9770                      const stack&lt;T, Container&gt;&amp; y);
9771    template &lt;class T, class Container&gt;
9772      bool operator!=(const stack&lt;T, Container&gt;&amp; x,
9773                      const stack&lt;T, Container&gt;&amp; y);
9774    template &lt;class T, class Container&gt;
9775      bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
9776                      const stack&lt;T, Container&gt;&amp; y);
9777    template &lt;class T, class Container&gt;
9778      bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
9779                      const stack&lt;T, Container&gt;&amp; y);
9780    template &lt;class T, class Container&gt;
9781      bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
9782                      const stack&lt;T, Container&gt;&amp; y);
9783  }
9784</pre>
9785
9786<p><i>[Copenhagen: This change was discussed before the IS was released
9787and it was deliberately not adopted.  Nevertheless, the LWG believes
9788(straw poll: 10-2) that it is a genuine defect.]</i></p>
9789
9790<hr>
9791<a name="308"><h3>308.&nbsp;Table 82 mentions unrelated headers</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Mar 2001</p>
9792<p>
9793Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
9794streams (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 &lt;cstdio&gt; and
9795&lt;cwchar&gt; 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
9796why these headers are mentioned in this context since they do not
9797define any of the library entities described by the
9798subclauses. 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
9799are to be listed in the summary.
9800</p>
9801<p><b>Proposed resolution:</b></p>
9802<p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
9803Table 82.</p>
9804
9805<p><i>[Copenhagen: changed the proposed resolution slightly.  The
9806original proposed resolution also said to remove &lt;cstdio&gt; from
9807Table 82.  However, &lt;cstdio&gt; is mentioned several times within
9808section 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>
9809
9810<hr>
9811<a name="310"><h3>310.&nbsp;Is errno a macro?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
9812  <p>
9813  Exactly how should errno be declared in a conforming C++ header?
9814  </p>
9815
9816  <p>
9817  The C standard says in 7.1.4 that it is unspecified whether errno is a
9818  macro or an identifier with external linkage.  In some implementations
9819  it can be either, depending on compile-time options.  (E.g., on
9820  Solaris in multi-threading mode, errno is a macro that expands to a
9821  function call, but is an extern int otherwise.  "Unspecified" allows
9822  such variability.)
9823  </p>
9824
9825  <p>The C++ standard:</p>
9826  <ul>
9827  <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
9828  <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
9829      name (true), and implies that it is an identifier.</li>
9830  <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
9831      on to say that the contents of of C++ &lt;errno.h&gt; are the
9832      same as in C, begging the question.</li>
9833  <li>C.2, table 95 lists errno as a macro, without comment.</li>
9834  </ul>
9835
9836  <p>I find no other references to errno.</p>
9837
9838  <p>We should either explicitly say that errno must be a macro, even
9839  though it need not be a macro in C, or else explicitly leave it
9840  unspecified.  We also need to say something about namespace std.
9841  A user who includes &lt;cerrno&gt; needs to know whether to write
9842  <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
9843  else &lt;cerrno&gt; is useless.</p>
9844
9845  <p>Two acceptable fixes:</p>
9846  <ul>
9847    <li><p>errno must be a macro. This is trivially satisfied by adding<br>
9848        &nbsp;&nbsp;#define errno (::std::errno)<br>
9849        to the headers if errno is not already a macro. You then always
9850        write errno without any scope qualification, and it always expands
9851        to a correct reference. Since it is always a macro, you know to
9852        avoid using errno as a local identifer.</p></li>
9853    <li><p>errno is in the global namespace. This fix is inferior, because
9854        ::errno is not guaranteed to be well-formed.</p></li>
9855  </ul>
9856
9857  <p><i>[
9858    This issue was first raised in 1999, but it slipped through
9859    the cracks.
9860  ]</i></p>
9861<p><b>Proposed resolution:</b></p>
9862  <p>Change the Note in section 17.4.1.2p5 from</p>
9863
9864    <blockquote>
9865    Note: the names defined as macros in C include the following:
9866    assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
9867    </blockquote>
9868
9869  <p>to</p>
9870
9871    <blockquote>
9872    Note: the names defined as macros in C include the following:
9873    assert, offsetof, setjmp, va_arg, va_end, and va_start.
9874    </blockquote>
9875
9876  <p>In section 19.3, change paragraph 2 from</p>
9877
9878    <blockquote>
9879    The contents are the same as the Standard C library header
9880    &lt;errno.h&gt;.
9881    </blockquote>
9882
9883  <p>to</p>
9884
9885    <blockquote>
9886    The contents are the same as the Standard C library header
9887    &lt;errno.h&gt;, except that errno shall be defined as a macro.
9888    </blockquote>
9889<p><b>Rationale:</b></p>
9890<p>C++ must not leave it up to the implementation to decide whether or
9891not a name is a macro; it must explicitly specify exactly which names
9892are required to be macros.  The only one that really works is for it
9893to be a macro.</p>
9894
9895<p><i>[Cura�ao: additional rationale added.]</i></p>
9896
9897<hr>
9898<a name="311"><h3>311.&nbsp;Incorrect wording in basic_ostream class synopsis</h3></a><p><b>Section:</b>&nbsp;27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
9899
9900<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>
9901
9902<pre>  // partial specializationss
9903  template&lt;class traits&gt;
9904    basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
9905                                            const char * );
9906</pre>
9907
9908<p>Problems:</p>
9909<ul>
9910<li>Too many 's's at the end of "specializationss" </li>
9911<li>This is an overload, not a partial specialization</li>
9912</ul>
9913
9914<p><b>Proposed resolution:</b></p>
9915<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
9916<i>// partial specializationss</i> comment.  Also remove the same
9917comment (correctly spelled, but still incorrect) from the synopsis in
991827.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>.
9919</p>
9920
9921<p><i>[
9922Pre-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
9923comment in c++std-lib-8939.
9924]</i></p>
9925
9926<hr>
9927<a name="312"><h3>312.&nbsp;Table 27 is missing headers</h3></a><p><b>Section:</b>&nbsp;20 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.utilities"> [lib.utilities]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;29 Mar 2001</p>
9928<p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
9929Memory (lib.memory) but neglects to mention the headers
9930&lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.4.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.rel"> [lib.meta.rel]</a>.</p>
9931<p><b>Proposed resolution:</b></p>
9932<p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
9933as &lt;memory&gt;.</p>
9934<hr>
9935<a name="315"><h3>315.&nbsp;Bad "range" in list::unique complexity</h3></a><p><b>Section:</b>&nbsp;23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;1 May 2001</p>
9936<p>
993723.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a>, Para 21 describes the complexity of
9938list::unique as: "If the range (last - first) is not empty, exactly
9939(last - first) -1 applications of the corresponding predicate,
9940otherwise no applications of the predicate)".
9941</p>
9942
9943<p>
9944"(last - first)" is not a range.
9945</p>
9946<p><b>Proposed resolution:</b></p>
9947<p>
9948Change the "range" from (last - first) to [first, last).
9949</p>
9950<hr>
9951<a name="316"><h3>316.&nbsp;Vague text in Table 69</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
9952<p>Table 69 says this about a_uniq.insert(t):</p>
9953
9954<blockquote>
9955inserts t if and only if there is no element in the container with key
9956equivalent to the key of t. The bool component of the returned pair
9957indicates whether the insertion takes place and the iterator component of the
9958pair points to the element with key equivalent to the key of t.
9959</blockquote>
9960
9961<p>The description should be more specific about exactly how the bool component
9962indicates whether the insertion takes place.</p>
9963<p><b>Proposed resolution:</b></p>
9964<p>Change the text in question to</p>
9965
9966<blockquote>
9967...The bool component of the returned pair is true if and only if the insertion
9968takes place...
9969</blockquote>
9970<hr>
9971<a name="317"><h3>317.&nbsp;Instantiation vs. specialization of facets</h3></a><p><b>Section:</b>&nbsp;22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
9972<p>
9973The localization section of the standard refers to specializations of
9974the facet templates as instantiations even though the required facets
9975are typically specialized rather than explicitly (or implicitly)
9976instantiated. In the case of ctype&lt;char&gt; and
9977ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
9978actually required to be specialized. The terminology should be
9979corrected to make it clear that the standard doesn't mandate explicit
9980instantiation (the term specialization encompasses both explicit
9981instantiations and specializations).
9982</p>
9983<p><b>Proposed resolution:</b></p>
9984<p>
9985In the following paragraphs, replace all occurrences of the word
9986instantiation or instantiations with specialization or specializations,
9987respectively:
9988</p>
9989
9990<blockquote>
999122.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
999222.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
999322.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
9994Footnote 242.
9995</blockquote>
9996
9997<p>And change the text in 22.1.1.1.1, p4 from</p>
9998
9999<blockquote>
10000    An implementation is required to provide those instantiations
10001    for facet templates identified as members of a category, and
10002    for those shown in Table 52:
10003</blockquote>
10004
10005<p>to</p>
10006
10007<blockquote>
10008    An implementation is required to provide those specializations...
10009</blockquote>
10010
10011<p><i>[Nathan will review these changes, and will look for places where
10012explicit specialization is necessary.]</i></p>
10013
10014<p><b>Rationale:</b></p>
10015<p>This is a simple matter of outdated language.  The language to
10016describe templates was clarified during the standardization process,
10017but the wording in clause 22 was never updated to reflect that
10018change.</p>
10019<hr>
10020<a name="318"><h3>318.&nbsp;Misleading comment in definition of numpunct_byname</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 May 2001</p>
10021<p>The definition of the numpunct_byname template contains the following
10022comment:</p>
10023
10024<pre>    namespace std {
10025        template &lt;class charT&gt;
10026        class numpunct_byname : public numpunct&lt;charT&gt; {
10027    // this class is specialized for char and wchar_t.
10028        ...
10029</pre>
10030
10031<p>There is no documentation of the specializations and it seems
10032conceivable that an implementation will not explicitly specialize the
10033template at all, but simply provide the primary template.</p>
10034<p><b>Proposed resolution:</b></p>
10035<p>Remove the comment from the text in 22.2.3.2 and from the proposed
10036resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
10037<hr>
10038<a name="319"><h3>319.&nbsp;Storage allocation wording confuses "Required behavior", "Requires"</h3></a><p><b>Section:</b>&nbsp;18.5.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.5.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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;15 May 2001</p>
10039<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
10040behavior" elements describe "the semantics of a function definition
10041provided by either the implementation or a C++ program."</p>
10042
10043<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"
10044elements describe "the preconditions for calling the function."</p>
10045
10046<p>In the sections noted below, the current wording specifies
10047"Required Behavior" for what are actually preconditions, and thus
10048should be specified as "Requires".</p>
10049
10050<p><b>Proposed resolution:</b></p>
10051
10052<p>In 18.5.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>
10053<blockquote>
10054  <p>Required behavior: accept a value of ptr that is null or that was
10055  returned by an earlier call ...</p>
10056</blockquote>
10057<p>to:</p>
10058<blockquote>
10059  <p>Requires: the value of ptr is null or the value returned by an
10060  earlier call ...</p>
10061</blockquote>
10062
10063<p>In 18.5.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>
10064<blockquote>
10065  <p>Required behavior: accept a value of ptr that is null or that was
10066  returned by an earlier call ...</p>
10067</blockquote>
10068<p>to:</p>
10069<blockquote>
10070  <p>Requires: the value of ptr is null or the value returned by an
10071  earlier call ...</p>
10072</blockquote>
10073
10074<hr>
10075<a name="320"><h3>320.&nbsp;list::assign overspecified</h3></a><p><b>Section:</b>&nbsp;23.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
10076<p>
10077Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
10078the "effects" of a call to erase followed by a call to insert.
10079</p>
10080
10081<p>
10082I would like to document that implementers have the freedom to implement
10083assign by other methods, as long as the end result is the same and the
10084exception guarantee is as good or better than the basic guarantee.
10085</p>
10086
10087<p>
10088The motivation for this is to use T's assignment operator to recycle
10089existing nodes in the list instead of erasing them and reallocating
10090them with new values.  It is also worth noting that, with careful
10091coding, most common cases of assign (everything but assignment with
10092true input iterators) can elevate the exception safety to strong if
10093T's assignment has a nothrow guarantee (with no extra memory cost).
10094Metrowerks does this.  However I do not propose that this subtlety be
10095standardized.  It is a QoI issue.  </p>
10096
10097<p>Existing practise:
10098Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
10099</p>
10100<p><b>Proposed resolution:</b></p>
10101<p>Change 23.2.2.1/7 from:</p>
10102
10103<blockquote>
10104<p>Effects:</p>
10105
10106<pre>   erase(begin(), end());
10107   insert(begin(), first, last);
10108</pre>
10109</blockquote>
10110
10111<p>to:</p>
10112
10113<blockquote>
10114<p>Effects: Replaces the contents of the list with the range [first, last).</p>
10115</blockquote>
10116
10117<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),
10118add two new rows:</p>
10119<pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
10120                                  Replaces elements in a with a copy
10121                                  of [i, j).
10122
10123      a.assign(n,t)     void      pre: t is not a reference into a.
10124                                  Replaces elements in a with n copies
10125                                  of t.
10126</pre>
10127
10128<p>Change 23.2.2.1/8 from:</p>
10129
10130<blockquote>
10131<p>Effects:</p>
10132<pre>   erase(begin(), end());
10133   insert(begin(), n, t);
10134</pre>
10135</blockquote>
10136<p>to:</p>
10137
10138<blockquote>
10139<p>Effects: Replaces the contents of the list with n copies of t.</p>
10140</blockquote>
10141
10142<p><i>[Redmond: Proposed resolution was changed slightly.  Previous
10143version made explicit statement about exception safety, which wasn't
10144consistent with the way exception safety is expressed elsewhere.
10145Also, the change in the sequence requirements is new.  Without that
10146change, the proposed resolution would have required that assignment of
10147a subrange would have to work.  That too would have been
10148overspecification; it would effectively mandate that assignment use a
10149temporary.  Howard provided wording.
10150]</i></p>
10151
10152<p><i>[Cura�ao: Made editorial improvement in wording; changed
10153"Replaces elements in a with copies of elements in [i, j)."
10154with "Replaces the elements of a with a copy of [i, j)."
10155Changes not deemed serious enough to requre rereview.]</i></p>
10156
10157<hr>
10158<a name="321"><h3>321.&nbsp;Typo in num_get</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Kevin Djang&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
10159<p>
10160Section 22.2.2.1.2 at p7 states that "A length specifier is added to
10161the conversion function, if needed, as indicated in Table 56."
10162However, Table 56 uses the term "length modifier", not "length
10163specifier".
10164</p>
10165<p><b>Proposed resolution:</b></p>
10166<p>
10167In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
10168to be "A length modifier is added ..."
10169</p>
10170<p><b>Rationale:</b></p>
10171<p>C uses the term "length modifier".  We should be consistent.</p>
10172<hr>
10173<a name="322"><h3>322.&nbsp;iterator and const_iterator should have the same value type</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
10174<p>
10175It's widely assumed that, if X is a container,
10176iterator_traits&lt;X::iterator&gt;::value_type and
10177iterator_traits&lt;X::const_iterator&gt;::value_type should both be
10178X::value_type.  However, this is nowhere stated.  The language in
10179Table 65 is not precise about the iterators' value types (it predates
10180iterator_traits), and could even be interpreted as saying that
10181iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
10182X::value_type".
10183</p>
10184
10185<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
10186<p><b>Proposed resolution:</b></p>
10187<p>In Table 65 ("Container Requirements"), change the return type for
10188X::iterator to "iterator type whose value type is T".  Change the
10189return type for X::const_iterator to "constant iterator type whose
10190value type is T".</p>
10191<p><b>Rationale:</b></p>
10192<p>
10193This belongs as a container requirement, rather than an iterator
10194requirement, because the whole notion of iterator/const_iterator
10195pairs is specific to containers' iterator.
10196</p>
10197<p>
10198It is existing practice that (for example)
10199iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
10200is "int", rather than "const int".  This is consistent with
10201the way that const pointers are handled: the standard already
10202requires that iterator_traits&lt;const int*&gt;::value_type is int.
10203</p>
10204<hr>
10205<a name="324"><h3>324.&nbsp;Do output iterators have value types?</h3></a><p><b>Section:</b>&nbsp;24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 June 2001</p>
10206
10207<p>Table 73 suggests that output iterators have value types.  It
10208requires the expression "*a = t".  Additionally, although Table 73
10209never lists "a = t" or "X(a) = t" in the "expressions" column, it
10210contains a note saying that "a = t" and "X(a) = t" have equivalent
10211(but nowhere specified!) semantics.</p>
10212
10213<p>According to 24.1/9, t is supposed to be "a value of value type
10214T":</p>
10215
10216    <blockquote>
10217    In the following sections, a and b denote values of X, n denotes a
10218    value of the difference type Distance, u, tmp, and m denote
10219    identifiers, r denotes a value of X&amp;, t denotes a value of
10220    value type T.
10221    </blockquote>
10222
10223<p>Two other parts of the standard that are relevant to whether
10224output iterators have value types:</p>
10225
10226<ul>
10227    <li>24.1/1 says "All iterators i support the expression *i,
10228    resulting in a value of some class, enumeration, or built-in type
10229    T, called the value type of the iterator".</li>
10230
10231    <li>
10232    24.3.1/1, which says "In the case of an output iterator, the types
10233    iterator_traits&lt;Iterator&gt;::difference_type
10234    iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
10235    </li>
10236</ul>
10237
10238<p>The first of these passages suggests that "*i" is supposed to
10239return a useful value, which contradicts the note in 24.1.2/2 saying
10240that the only valid use of "*i" for output iterators is in an
10241expression of the form "*i = t".  The second of these passages appears
10242to contradict Table 73, because it suggests that "*i"'s return value
10243should be void.  The second passage is also broken in the case of a an
10244iterator type, like non-const pointers, that satisfies both the output
10245iterator requirements and the forward iterator requirements.</p>
10246
10247<p>What should the standard say about <tt>*i</tt>'s return value when
10248i is an output iterator, and what should it say about that t is in the
10249expression "*i = t"?  Finally, should the standard say anything about
10250output iterators' pointer and reference types?</p>
10251
10252<p><b>Proposed resolution:</b></p>
10253<p>24.1 p1, change</p>
10254
10255<blockquote>
10256<p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
10257in a value of some class, enumeration, or built-in type <tt>T</tt>,
10258called the value type of the iterator.</p>
10259</blockquote>
10260
10261<p>to</p>
10262
10263<blockquote>
10264<p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
10265resulting in a value of some class, enumeration, or built-in type
10266<tt>T</tt>, called the value type of the iterator. All output
10267iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
10268value of some type that is in the set of types that are <i>writable</i> to
10269the particular iterator type of <tt>i</tt>.
10270</p>
10271</blockquote>
10272
10273<p>24.1 p9, add</p>
10274
10275<blockquote>
10276<p><tt>o</tt> denotes a value of some type that is writable to the
10277output iterator.
10278</p>
10279</blockquote>
10280
10281<p>Table 73, change</p>
10282
10283<blockquote>
10284<pre>*a = t
10285</pre>
10286</blockquote>
10287
10288<p>to</p>
10289
10290<blockquote>
10291<pre>*r = o
10292</pre>
10293</blockquote>
10294
10295<p>and change</p>
10296
10297<blockquote>
10298<pre>*r++ = t
10299</pre>
10300</blockquote>
10301
10302<p>to</p>
10303
10304<blockquote>
10305<pre>*r++ = o
10306</pre>
10307</blockquote>
10308
10309<p><i>[post-Redmond: Jeremy provided wording]</i></p>
10310
10311<p><b>Rationale:</b></p>
10312<p>The LWG considered two options: change all of the language that
10313seems to imply that output iterators have value types, thus making it
10314clear that output iterators have no value types, or else define value
10315types for output iterator consistently.  The LWG chose the former
10316option, because it seems clear that output iterators were never
10317intended to have value types.  This was a deliberate design decision,
10318and any language suggesting otherwise is simply a mistake.</p>
10319
10320<p>A future revision of the standard may wish to revisit this design
10321decision.</p>
10322<hr>
10323<a name="325"><h3>325.&nbsp;Misleading text in moneypunct&lt;&gt;::do_grouping</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Jul 2001</p>
10324<p>The Returns clause in 22.2.6.3.2, p3 says about
10325moneypunct&lt;charT&gt;::do_grouping()
10326</p>
10327
10328<blockquote>
10329    Returns: A pattern defined identically as the result of
10330    numpunct&lt;charT&gt;::do_grouping().241)
10331</blockquote>
10332
10333<p>Footnote 241 then reads</p>
10334
10335<blockquote>
10336    This is most commonly the value "\003" (not "3").
10337</blockquote>
10338
10339<p>
10340The returns clause seems to imply that the two member functions must
10341return an identical value which in reality may or may not be true,
10342since the facets are usually implemented in terms of struct std::lconv
10343and return the value of the grouping and mon_grouping, respectively.
10344The footnote also implies that the member function of the moneypunct
10345facet (rather than the overridden virtual functions in moneypunct_byname)
10346most commonly return "\003", which contradicts the C standard which
10347specifies the value of "" for the (most common) C locale.
10348</p>
10349
10350<p><b>Proposed resolution:</b></p>
10351<p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
10352
10353<blockquote>
10354    Returns: A pattern defined identically as, but not necessarily
10355    equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
10356</blockquote>
10357
10358<p>and replace the text in Footnote 241 with the following:</p>
10359
10360<blockquote>
10361    To specify grouping by 3s the value is "\003", not "3".
10362</blockquote>
10363<p><b>Rationale:</b></p>
10364<p>
10365The fundamental problem is that the description of the locale facet
10366virtuals serves two purposes: describing the behavior of the base
10367class, and describing the meaning of and constraints on the behavior
10368in arbitrary derived classes.  The new wording makes that separation a
10369little bit clearer.  The footnote (which is nonnormative) is not
10370supposed to say what the grouping is in the "C" locale or in any other
10371locale. It is just a reminder that the values are interpreted as small
10372integers, not ASCII characters.
10373</p>
10374<hr>
10375<a name="327"><h3>327.&nbsp;Typo in time_get facet in table 52</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Tiki Wan&nbsp; <b>Date:</b>&nbsp;06 Jul 2001</p>
10376<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
10377<tt>time_get_byname</tt> are listed incorrectly in table 52,
10378required instantiations.  In both cases the second template
10379parameter is given as OutputIterator.  It should instead be
10380InputIterator, since these are input facets.</p>
10381<p><b>Proposed resolution:</b></p>
10382<p>
10383In table 52, required instantiations, in
1038422.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>
10385<pre>    time_get&lt;wchar_t, OutputIterator&gt;
10386    time_get_byname&lt;wchar_t, OutputIterator&gt;
10387</pre>
10388<p>to</p>
10389<pre>    time_get&lt;wchar_t, InputIterator&gt;
10390    time_get_byname&lt;wchar_t, InputIterator&gt;
10391</pre>
10392
10393<p><i>[Redmond: Very minor change in proposed resolution.  Original had
10394a typo, wchart instead of wchar_t.]</i></p>
10395
10396<hr>
10397<a name="328"><h3>328.&nbsp;Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;07 Jul 2001</p>
10398<p>The sprintf format string , "%.01f" (that's the digit one), in the
10399description of the do_put() member functions of the money_put facet in
1040022.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
10401for values of type long double, and second, the precision of 01
10402doesn't seem to make sense. What was most likely intended was
10403"%.0Lf"., that is a precision of zero followed by the L length
10404modifier.</p>
10405<p><b>Proposed resolution:</b></p>
10406<p>Change the format string to "%.0Lf".</p>
10407<p><b>Rationale:</b></p>
10408<p>Fixes an obvious typo</p>
10409<hr>
10410<a name="329"><h3>329.&nbsp;vector capacity, reserve and reallocation</h3></a><p><b>Section:</b>&nbsp;23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>, 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;13 Jul 2001</p>
10411<p>
10412There is an apparent contradiction about which circumstances can cause
10413a 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.priority.queue"> [lib.priority.queue]</a> and
10414section 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>.
10415</p>
10416
10417<p>23.2.4.2p5 says:</p>
10418<blockquote>
10419Notes: Reallocation invalidates all the references, pointers, and iterators
10420referring to the elements in the sequence. It is guaranteed that no
10421reallocation takes place during insertions that happen after a call to
10422reserve() until the time when an insertion would make the size of the vector
10423greater than the size specified in the most recent call to reserve().
10424</blockquote>
10425
10426<p>Which implies if I do</p>
10427
10428<pre>  std::vector&lt;int&gt; vec;
10429  vec.reserve(23);
10430  vec.reserve(0);
10431  vec.insert(vec.end(),1);
10432</pre>
10433
10434<p>then the implementation may reallocate the vector for the insert,
10435as the size specified in the previous call to reserve was zero.</p>
10436
10437<p>However, the previous paragraphs (23.2.4.2, p1-2) state:</p>
10438<blockquote>
10439<p>
10440(capacity) Returns: The total number of elements the vector
10441can hold without requiring reallocation
10442</p>
10443<p>
10444...After reserve(), capacity() is greater or equal to the
10445argument of reserve if reallocation happens; and equal to the previous value
10446of capacity() otherwise...
10447</p>
10448</blockquote>
10449
10450<p>
10451This implies that vec.capacity() is still 23, and so the insert()
10452should not require a reallocation, as vec.size() is 0. This is backed
10453up by 23.2.4.3p1:
10454</p>
10455<blockquote>
10456(insert) Notes: Causes reallocation if the new size is greater than the old
10457capacity.
10458</blockquote>
10459
10460<p>
10461Though this doesn't rule out reallocation if the new size is less
10462than the old capacity, I think the intent is clear.
10463</p>
10464
10465<p><b>Proposed resolution:</b></p>
10466<p>Change the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a> paragraph 5 to:</p>
10467
10468<blockquote>
10469Notes: Reallocation invalidates all the references, pointers, and
10470iterators referring to the elements in the sequence. It is guaranteed
10471that no reallocation takes place during insertions that happen after a
10472call to reserve() until the time when an insertion would make the size
10473of the vector greater than the value of capacity().
10474</blockquote>
10475
10476<p><i>[Redmond: original proposed resolution was modified slightly.  In
10477the original, the guarantee was that there would be no reallocation
10478until the size would be greater than the value of capacity() after the
10479most recent call to reserve().  The LWG did not believe that the
10480"after the most recent call to reserve()" added any useful
10481information.]</i></p>
10482
10483<p><b>Rationale:</b></p>
10484<p>There was general agreement that, when reserve() is called twice in
10485succession and the argument to the second invocation is smaller than
10486the argument to the first, the intent was for the second invocation to
10487have no effect.  Wording implying that such cases have an effect on
10488reallocation guarantees was inadvertant.</p>
10489<hr>
10490<a name="331"><h3>331.&nbsp;bad declaration of destructor for ios_base::failure</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;23 Aug 2001</p>
10491<p>
10492With 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
10493   "An implementation may strengthen the exception-specification for a
10494    non-virtual function by removing listed exceptions."
10495(issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
10496and the following declaration of ~failure() in ios_base::failure
10497</p>
10498<pre>    namespace std {
10499       class ios_base::failure : public exception {
10500       public:
10501           ...
10502           virtual ~failure();
10503           ...
10504       };
10505     }
10506</pre>
10507<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.type.info"> [lib.type.info]</a> the destructor of class exception has an empty
10508exception specification:</p>
10509<pre>    namespace std {
10510       class exception {
10511       public:
10512         ...
10513         virtual ~exception() throw();
10514         ...
10515       };
10516     }
10517</pre>
10518<p><b>Proposed resolution:</b></p>
10519<p>Remove the declaration of ~failure().</p>
10520<p><b>Rationale:</b></p>
10521<p>The proposed resolution is consistent with the way that destructors
10522of other classes derived from <tt>exception</tt> are handled.</p>
10523<hr>
10524<a name="333"><h3>333.&nbsp;does endl imply synchronization with the device?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;27 Aug 2001</p>
10525<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>
10526<blockquote>
10527    [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
10528     newline character in the output sequence controlled by cout, then
10529     synchronize it with any external file with which it might be
10530     associated. --- end foonote]
10531</blockquote>
10532
10533<p>
10534Does the term "file" here refer to the external device?
10535This leads to some implementation ambiguity on systems with fully
10536buffered files where a newline does not cause a flush to the device.
10537</p>
10538
10539<p>
10540Choosing to sync with the device leads to significant performance
10541penalties for each call to endl, while not sync-ing leads to
10542errors under special circumstances.
10543</p>
10544
10545<p>
10546I could not find any other statement that explicitly defined
10547the behavior one way or the other.
10548</p>
10549<p><b>Proposed resolution:</b></p>
10550<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>
10551<p><b>Rationale:</b></p>
10552<p>We already have normative text saying what <tt>endl</tt> does: it
10553inserts a newline character and calls <tt>flush</tt>.  This footnote
10554is at best redundant, at worst (as this issue says) misleading,
10555because it appears to make promises about what <tt>flush</tt>
10556does.</p>
10557<hr>
10558<a name="334"><h3>334.&nbsp;map::operator[] specification forces inefficient implementation</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrea Griffini&nbsp; <b>Date:</b>&nbsp;02 Sep 2001</p>
10559<p>
10560The current standard describes map::operator[] using a
10561code example. That code example is however quite
10562inefficient because it requires several useless copies
10563of both the passed key_type value and of default
10564constructed mapped_type instances.
10565My opinion is that was not meant by the comitee to
10566require all those temporary copies.
10567</p>
10568
10569<p>Currently map::operator[] behaviour is specified as: </p>
10570<pre>  Returns:
10571    (*((insert(make_pair(x, T()))).first)).second.
10572</pre>
10573
10574<p>
10575This specification however uses make_pair that is a
10576template function of which parameters in this case
10577will be deduced being of type const key_type&amp; and
10578const T&amp;. This will create a pair&lt;key_type,T&gt; that
10579isn't the correct type expected by map::insert so
10580another copy will be required using the template
10581conversion constructor available in pair to build
10582the required pair&lt;const key_type,T&gt; instance.
10583</p>
10584
10585<p>If we consider calling of key_type copy constructor
10586and mapped_type default constructor and copy
10587constructor as observable behaviour (as I think we
10588should) then the standard is in this place requiring
10589two copies of a key_type element plus a default
10590construction and two copy construction of a mapped_type
10591(supposing the addressed element is already present
10592in the map; otherwise at least another copy
10593construction for each type).
10594</p>
10595
10596<p>A simple (half) solution would be replacing the description with:</p>
10597<pre>  Returns:
10598    (*((insert(value_type(x, T()))).first)).second.
10599</pre>
10600
10601<p>This will remove the wrong typed pair construction that
10602requires one extra copy of both key and value.</p>
10603
10604<p>However still the using of map::insert requires temporary
10605objects while the operation, from a logical point of view,
10606doesn't require any. </p>
10607
10608<p>I think that a better solution would be leaving free an
10609implementer to use a different approach than map::insert
10610that, because of its interface, forces default constructed
10611temporaries and copies in this case.
10612The best solution in my opinion would be just requiring
10613map::operator[] to return a reference to the mapped_type
10614part of the contained element creating a default element
10615with the specified key if no such an element is already
10616present in the container. Also a logarithmic complexity
10617requirement should be specified for the operation.
10618</p>
10619
10620<p>
10621This would allow library implementers to write alternative
10622implementations not using map::insert and reaching optimal
10623performance in both cases of the addressed element being
10624present or absent from the map (no temporaries at all and
10625just the creation of a new pair inside the container if
10626the element isn't present).
10627Some implementer has already taken this option but I think
10628that the current wording of the standard rules that as
10629non-conforming.
10630</p>
10631
10632<p><b>Proposed resolution:</b></p>
10633
10634<p>
10635Replace 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
10636</p>
10637<blockquote>
10638<p>
10639-1- Effects:  If there is no key equivalent to x in the map, inserts
10640value_type(x, T()) into the map.
10641</p>
10642<p>
10643-2- Returns: A reference to the mapped_type corresponding to x in *this.
10644</p>
10645<p>
10646-3- Complexity: logarithmic.
10647</p>
10648</blockquote>
10649
10650<p><i>[This is the second option mentioned above.  Howard provided
10651wording.  We may also wish to have a blanket statement somewhere in
10652clause 17 saying that we do not intend the semantics of sample code
10653fragments to be interpreted as specifing exactly how many copies are
10654made.  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>
10655
10656<p><b>Rationale:</b></p>
10657<p>
10658This is the second solution described above; as noted, it is
10659consistent with existing practice.
10660</p>
10661
10662<p>Note that we now need to specify the complexity explicitly, because
10663we are no longer defining <tt>operator[]</tt> in terms of
10664<tt>insert</tt>.</p>
10665<hr>
10666<a name="335"><h3>335.&nbsp;minor issue with char_traits, table 37</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;06 Sep 2001</p>
10667<p>
10668Table 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
10669as:
10670</p>
10671<pre>  X::assign(c,d)   assigns c = d.
10672</pre>
10673
10674<p>And para 1 says:</p>
10675
10676<blockquote>
10677 [...] c and d denote values of type CharT [...]
10678</blockquote>
10679
10680<p>
10681Naturally, if c and d are <i>values</i>, then the assignment is
10682(effectively) meaningless. It's clearly intended that (in the case of
10683assign, at least), 'c' is intended to be a reference type.
10684</p>
10685
10686<p>I did a quick survey of the four implementations I happened to have
10687lying around, and sure enough they all have signatures:</p>
10688<pre>    assign( charT&amp;, const charT&amp; );
10689</pre>
10690
10691<p>(or the equivalent). It's also described this way in Nico's book.
10692(Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
10693and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
10694</p>
10695<p><b>Proposed resolution:</b></p>
10696<p>Add the following to 21.1.1 para 1:</p>
10697<blockquote>
10698 r denotes an lvalue of CharT
10699</blockquote>
10700
10701<p>and change the description of assign in the table to:</p>
10702<pre>  X::assign(r,d)   assigns r = d
10703</pre>
10704<hr>
10705<a name="336"><h3>336.&nbsp;Clause 17 lack of references to deprecated headers</h3></a><p><b>Section:</b>&nbsp;17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;05 Sep 2001</p>
10706<p>From c++std-edit-873:</p>
10707
10708<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
10709&lt;strstream&gt; is missing.</p>
10710
10711<p>This shows a general problem: The whole clause 17 refers quite
10712often to clauses 18 through 27, but D.7 is also a part of the standard
10713library (though a deprecated one).</p>
10714
10715<p><b>Proposed resolution:</b></p>
10716
10717<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
10718"&lt;strstream&gt;".</p>
10719
10720<p>In the following places, change "clauses 17 through 27" to "clauses
1072117 through 27 and Annex D":</p>
10722
10723<ul>
10724<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>
10725<li>1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.defs"> [intro.defs]</a> Definitions/1</li>
10726<li>7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.dcl"> [dcl.dcl]</a> Library introduction/9</li>
10727<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>
10728<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>
10729<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>
10730<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>
10731<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>
10732<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>
10733<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>
10734<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>
10735<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>
10736</ul>
10737
10738
10739<hr>
10740<a name="337"><h3>337.&nbsp;replace_copy_if's template parameter should be InputIterator</h3></a><p><b>Section:</b>&nbsp;25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;07 Sep 2001</p>
10741<p>From c++std-edit-876:</p>
10742
10743<p>
10744In 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
10745parameter of template replace_copy_if should be "InputIterator"
10746instead 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
10747parameter name conveys real normative meaning.
10748</p>
10749<p><b>Proposed resolution:</b></p>
10750<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
10751<hr>
10752<a name="338"><h3>338.&nbsp; is whitespace allowed between `-' and a digit?</h3></a><p><b>Section:</b>&nbsp;22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 Sep 2001</p>
10753<p>
10754From 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
10755original text or the text corrected by the proposed resolution of
10756issue <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
10757within 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
10758format for integer and floating point values, says that whitespace is
10759optional between a plusminus and a sign.
10760</p>
10761
10762<p>
10763The text needs to be clarified to either consistently allow or
10764disallow whitespace between a plusminus and a sign. It might be
10765worthwhile to consider the fact that the C library stdio facility does
10766not permit whitespace embedded in numbers and neither does the C or
10767C++ 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).
10768</p>
10769<p><b>Proposed resolution:</b></p>
10770<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>
10771<blockquote>
10772<p>
10773The syntax for number formats is as follows, where <tt>digit</tt>
10774represents the radix set specified by the <tt>fmtflags</tt> argument
10775value, <tt>whitespace</tt> is as determined by the facet
10776<tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
10777<tt>decimal-point</tt> are the results of corresponding
10778<tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
10779format:
10780</p>
10781<pre>  integer   ::= [sign] units
10782  sign      ::= plusminus [whitespace]
10783  plusminus ::= '+' | '-'
10784  units     ::= digits [thousands-sep units]
10785  digits    ::= digit [digits]
10786</pre>
10787</blockquote>
10788<p>to:</p>
10789<blockquote>
10790<p>
10791The syntax for number formats is as follows, where <tt>digit</tt>
10792represents the radix set specified by the <tt>fmtflags</tt> argument
10793value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
10794results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
10795Integer values have the format:
10796</p>
10797<pre>  integer   ::= [sign] units
10798  sign      ::= plusminus
10799  plusminus ::= '+' | '-'
10800  units     ::= digits [thousands-sep units]
10801  digits    ::= digit [digits]
10802</pre>
10803</blockquote>
10804<p><b>Rationale:</b></p>
10805<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
10806standard says how, or whether, it's used.  However, there's no reason
10807for it to differ gratuitously from the very specific description of
10808numeric 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
10809resolution removes all mention of "whitespace" from that format.</p>
10810<hr>
10811<a name="339"><h3>339.&nbsp;definition of bitmask type restricted to clause 27</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 September 2001</p>
10812<p>
10813The 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
10814likely 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
10815clause 27, making the reference in 22.2.1 somewhat dubious.
10816</p>
10817<p><b>Proposed resolution:</b></p>
10818<p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
10819    <blockquote>
10820    Several types defined in clause 27 are bitmask types. Each bitmask type
10821    can be implemented as an enumerated type that overloads certain operators,
10822    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>).
10823    </blockquote>
10824<p>to read</p>
10825    <blockquote>
10826    Several types defined in clauses lib.language.support through
10827    lib.input.output and Annex D are bitmask types. Each bitmask type can
10828    be implemented as an enumerated type that overloads certain operators,
10829    as an integer  type, or as a bitset (lib.template.bitset).
10830    </blockquote>
10831
10832<p>
10833Additionally, change the definition in 22.2.1 to adopt the same
10834convention as in clause 27 by replacing the existing text with the
10835following (note, in particluar, the cross-reference to 17.3.2.1.2 in
1083622.2.1, p1):
10837</p>
10838
10839<blockquote>
10840<p>22.2.1 The ctype category [lib.category.ctype]</p>
10841<pre>namespace std {
10842    class ctype_base {
10843    public:
10844        typedef <b><i>T</i></b> mask;
10845
10846        // numeric values are for exposition only.
10847        static const mask space = 1 &lt;&lt; 0;
10848        static const mask print = 1 &lt;&lt; 1;
10849        static const mask cntrl = 1 &lt;&lt; 2;
10850        static const mask upper = 1 &lt;&lt; 3;
10851        static const mask lower = 1 &lt;&lt; 4;
10852        static const mask alpha = 1 &lt;&lt; 5;
10853        static const mask digit = 1 &lt;&lt; 6;
10854        static const mask punct = 1 &lt;&lt; 7;
10855        static const mask xdigit = 1 &lt;&lt; 8;
10856        static const mask alnum = alpha | digit;
10857        static const mask graph = alnum | punct;
10858    };
10859}
10860</pre>
10861
10862<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>
10863</blockquote>
10864
10865<p><i>[Cura�ao: The LWG notes that T above should be bold-italics to be
10866consistent with the rest of the standard.]</i></p>
10867
10868<hr>
10869<a name="340"><h3>340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
10870</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2001</p>
10871<p>
10872It's unclear whether 22.1.1.1.1, p3 says that
10873<tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
10874from Table 51 or whether it includes Table 52 as well:
10875</p>
10876
10877<blockquote>
10878For any locale <tt>loc</tt> either constructed, or returned by
10879locale::classic(), and any facet <tt>Facet</tt> that is a member of a
10880standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
10881locale member function which takes a <tt>locale::category</tt>
10882argument operates on the corresponding set of facets.
10883</blockquote>
10884
10885<p>
10886It seems that it comes down to which facets are considered to be members of a
10887standard category. Intuitively, I would classify all the facets in Table 52 as
10888members of their respective standard categories, but there are an unbounded set
10889of them...
10890</p>
10891
10892<p>
10893The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
10894OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
10895possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
10896&gt;(loc)</tt> would have to return a reference to a distinct object for each
10897valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
10898clearly impossible.
10899</p>
10900
10901<p>
10902On the other hand, if none of the facets in Table 52 is a member of a standard
10903category then none of the locale member functions that operate on entire
10904categories of facets will work properly.
10905</p>
10906
10907<p>
10908It seems that what p3 should mention that it's required (permitted?)
10909to hold only for specializations of <tt>Facet</tt> from Table 52 on
10910<tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
10911<tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
10912{
10913{i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
10914}.
10915</p>
10916<p><b>Proposed resolution:</b></p>
10917<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
10918"that is a member of a standard category" to "shown in Table 51".</p>
10919<p><b>Rationale:</b></p>
10920<p>The facets in Table 52 are an unbounded set.  Locales should not be
10921required to contain an infinite number of facets.</p>
10922
10923<p>It's not necessary to talk about which values of InputIterator and
10924OutputIterator must be supported.  Table 51 already contains a
10925complete list of the ones we need.</p>
10926<hr>
10927<a name="341"><h3>341.&nbsp;Vector reallocation and swap</h3></a><p><b>Section:</b>&nbsp;23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;27 Sep 2001</p>
10928<p>It is a common idiom to reduce the capacity of a vector by swapping it with
10929an empty one:</p>
10930<pre>  std::vector&lt;SomeType&gt; vec;
10931  // fill vec with data
10932  std::vector&lt;SomeType&gt;().swap(vec);
10933  // vec is now empty, with minimal capacity
10934</pre>
10935
10936<p>However, the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>paragraph 5 prevents
10937the capacity of a vector being reduced, following a call to
10938reserve(). This invalidates the idiom, as swap() is thus prevented
10939from 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
10940requires the temporary to be expanded to cater for the contents of
10941vec, and the contents be copied across. This is a linear-time
10942operation.</p>
10943
10944<p>However, the container requirements state that swap must have constant
10945complexity (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>
10946
10947<p>This is an important issue, as reallocation affects the validity of
10948references and iterators.</p>
10949
10950<p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
10951references and iterators remain valid after a call to swap, if they refer to
10952an element before the new end() of the vector into which they originally
10953pointed, in which case they refer to the element at the same index position.
10954Iterators and references that referred to an element whose index position
10955was beyond the new end of the vector are invalidated.</p>
10956
10957<p>If the note to table 65 is taken as the desired intent, then there are two
10958possibilities with regard to iterators and references:</p>
10959
10960<ol>
10961<li>All Iterators and references into both vectors are invalidated.</li>
10962<li>Iterators and references into either vector remain valid, and remain
10963pointing to the same element. Consequently iterators and references that
10964referred to one vector now refer to the other, and vice-versa.</li>
10965</ol>
10966<p><b>Proposed resolution:</b></p>
10967<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.priority.queue"> [lib.priority.queue]</a> paragraph 5:</p>
10968<blockquote>
10969<pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
10970</pre>
10971<p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
10972with that of <tt>x</tt>.</p>
10973<p><b>Complexity:</b> Constant time.</p>
10974</blockquote>
10975
10976<p><i>[This solves the problem reported for this issue.  We may also
10977have a problem with a circular definition of swap() for other
10978containers.]</i></p>
10979
10980<p><b>Rationale:</b></p>
10981<p>
10982swap should be constant time.  The clear intent is that it should just
10983do pointer twiddling, and that it should exchange all properties of
10984the two vectors, including their reallocation guarantees.
10985</p>
10986<hr>
10987<a name="345"><h3>345.&nbsp;type tm in &lt;cwchar&gt;</h3></a><p><b>Section:</b>&nbsp;21.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Clark Nelson&nbsp; <b>Date:</b>&nbsp;19 Oct 2001</p>
10988<p>
10989C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
10990declares 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
10991&lt;cwchar&gt;. Is this omission intentional or accidental?
10992</p>
10993<p><b>Proposed resolution:</b></p>
10994<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>
10995<hr>
10996<a name="346"></a><h3><a name="346">346.&nbsp;Some iterator member functions should be const</a></h3><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;20 Oct 2001</p>
10997<p>Iterator member functions and operators that do not change the state
10998of the iterator should be defined as const member functions or as
10999functions that take iterators either by const reference or by
11000value. The standard does not explicitly state which functions should
11001be const.  Since this a fairly common mistake, the following changes
11002are suggested to make this explicit.</p>
11003
11004<p>The tables almost indicate constness properly through naming: r
11005for non-const and a,b for const iterators. The following changes
11006make this more explicit and also fix a couple problems.</p>
11007<p><b>Proposed resolution:</b></p>
11008<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
11009"In the following sections, a and b denote values of X..." to
11010"In the following sections, a and b denote values of type const X...".</p>
11011
11012<p>In Table 73, change</p>
11013<pre>    a-&gt;m   U&amp;         ...
11014</pre>
11015
11016<p>to</p>
11017
11018<pre>    a-&gt;m   const U&amp;   ...
11019    r-&gt;m   U&amp;         ...
11020</pre>
11021
11022<p>In Table 73 expression column, change</p>
11023
11024<pre>    *a = t
11025</pre>
11026
11027<p>to</p>
11028
11029<pre>    *r = t
11030</pre>
11031
11032<p><i>[Redmond: The container requirements should be reviewed to see if
11033the same problem appears there.]</i></p>
11034
11035<hr>
11036<a name="347"><h3>347.&nbsp;locale::category and bitmask requirements</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger, Nathan Myers&nbsp; <b>Date:</b>&nbsp;23 Oct 2001</p>
11037<p>
11038In 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
11039are described as bitmask elements.  In fact, the bitmask requirements
11040in 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>
11041and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
11042
11043<p>In particular, the requirements for <tt>none</tt> interact poorly
11044with the requirement that the LC_* constants from the C library must
11045be recognizable as C++ locale category constants.  LC_* values should
11046not be mixed with these values to make category values.</p>
11047
11048<p>We have two options for the proposed resolution.  Informally:
11049option 1 removes the requirement that LC_* values be recognized as
11050category arguments.  Option 2 changes the category type so that this
11051requirement is implementable, by allowing <tt>none</tt> to be some
11052value such as 0x1000 instead of 0.</p>
11053
11054<p>Nathan writes: "I believe my proposed resolution [Option 2] merely
11055re-expresses the status quo more clearly, without introducing any
11056changes beyond resolving the DR.</p>
11057
11058<p><b>Proposed resolution:</b></p>
11059<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>
11060<blockquote>
11061<pre>    typedef int category;
11062</pre>
11063
11064<p>Valid category values include the <tt>locale</tt> member bitmask
11065elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
11066<tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
11067represents a single locale category. In addition, <tt>locale</tt> member
11068bitmask constant <tt>none</tt> is defined as zero and represents no
11069category. And locale member bitmask constant <tt>all</tt> is defined such that
11070the expression</p>
11071<pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
11072</pre>
11073<p>
11074is <tt>true</tt>, and represents the union of all categories.  Further
11075the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
11076represent a single category, represents the union of the two
11077categories.
11078</p>
11079
11080<p>
11081<tt>locale</tt> member functions expecting a <tt>category</tt>
11082argument require one of the <tt>category</tt> values defined above, or
11083the union of two or more such values. Such a <tt>category</tt>
11084argument identifies a set of locale categories. Each locale category,
11085in turn, identifies a set of locale facets, including at least those
11086shown in Table 51:
11087</p>
11088</blockquote>
11089<p><i>[Cura�ao: need input from locale experts.]</i></p>
11090
11091<p><b>Rationale:</b></p>
11092
11093<p>The LWG considered, and rejected, an alternate proposal (described
11094  as "Option 2" in the discussion).  The main reason for rejecting it
11095  was that library implementors were concerened about implementation
11096  difficult, given that getting a C++ library to work smoothly with a
11097  separately written C library is already a delicate business.  Some
11098  library implementers were also concerned about the issue of adding
11099  extra locale categories.</p>
11100
11101<blockquote>
11102<p><b>Option 2:</b> <br>
11103Replace 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>
11104<blockquote>
11105<p>
11106Valid category values include the enumerated values.  In addition, the
11107result of applying commutative operators | and &amp; to any two valid
11108values is valid, and results in the setwise union and intersection,
11109respectively, of the argument categories.  The values <tt>all</tt> and
11110<tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
11111expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
11112<tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are
11113true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
11114remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
11115For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
11116of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of
11117those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
11118[Footnote: it is not required that <tt>all</tt> equal the setwise union
11119of the other enumerated values; implementations may add extra categories.]
11120</p>
11121</blockquote>
11122</blockquote>
11123<hr>
11124<a name="349"><h3>349.&nbsp;Minor typographical error in ostream_iterator</h3></a><p><b>Section:</b>&nbsp;24.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;24 Oct 2001</p>
11125<p>24.5.2 [lib.ostream.iterator] states:</p>
11126<pre>    [...]
11127
11128    private:
11129    // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
11130    // const char* delim; exposition only
11131</pre>
11132
11133<p>Whilst it's clearly marked "exposition only", I suspect 'delim'
11134should be of type 'const charT*'.</p>
11135<p><b>Proposed resolution:</b></p>
11136<p>
11137In 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
11138<tt>const charT* delim</tt>.
11139</p>
11140<hr>
11141<a name="352"><h3>352.&nbsp;missing fpos requirements</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Dec 2001</p>
11142<p>
11143<i>(1)</i>
11144There are no requirements on the <tt>stateT</tt> template parameter of
11145<tt>fpos</tt> listed in 27.4.3. The interface appears to require that
11146the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
11147and I think also DefaultConstructible (to implement the operations in
11148Table 88).
11149</p>
11150<p>
1115121.1.2, p3, however, only requires that
11152<tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
11153CopyConstructible types.
11154</p>
11155<p>
11156<i>(2)</i>
11157Additionally, the <tt>stateT</tt> template argument has no
11158corresponding typedef in fpos which might make it difficult to use in
11159generic code.
11160</p>
11161<p><b>Proposed resolution:</b></p>
11162<p>
11163Modify 21.1.2, p4 from
11164</p>
11165<p>
11166    Requires: <tt>state_type</tt> shall meet the requirements of
11167              CopyConstructible types (20.1.3).
11168</p>
11169<p>
11170    Requires: state_type shall meet the requirements of Assignable
11171              (23.1, p4), CopyConstructible (20.1.3), and
11172              DefaultConstructible  (20.1.4) types.
11173</p>
11174
11175<p><b>Rationale:</b></p>
11176<p>The LWG feels this is two issues, as indicated above. The first is
11177a defect---std::basic_fstream is unimplementable without these
11178additional requirements---and the proposed resolution fixes it.  The
11179second is questionable; who would use that typedef?  The class
11180template fpos is used only in a very few places, all of which know the
11181state type already.  Unless motivation is provided, the second should
11182be considered NAD.</p>
11183<hr>
11184<a name="354"><h3>354.&nbsp;Associative container lower/upper bound requirements</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Aberg&nbsp; <b>Date:</b>&nbsp;17 Dec 2001</p>
11185<p>
11186Discussions in the thread "Associative container lower/upper bound
11187requirements" on comp.std.c++ suggests that there is a defect in the
11188C++ standard, Table 69 of section 23.1.2, "Associative containers",
11189[lib.associative.reqmts].  It currently says:</p>
11190
11191<blockquote>
11192<p>
11193a.find(k): returns an iterator pointing to an element with the key equivalent to
11194k, or a.end() if such an element is not found.
11195</p>
11196
11197<p>
11198a.lower_bound(k): returns an iterator pointing to the first element with
11199key not less than k.
11200</p>
11201
11202<p>
11203a.upper_bound(k): returns an iterator pointing to the first element with
11204key greater than k.
11205</p>
11206</blockquote>
11207
11208<p>
11209We have "or a.end() if such an element is not found" for
11210<tt>find</tt>, but not for <tt>upper_bound</tt> or
11211<tt>lower_bound</tt>.  As the text stands, one would be forced to
11212insert a new element into the container and return an iterator to that
11213in case the sought iterator does not exist, which does not seem to be
11214the intention (and not possible with the "const" versions).
11215</p>
11216<p><b>Proposed resolution:</b></p>
11217
11218<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
11219to:</p>
11220
11221<blockquote>
11222<p>
11223a.lower_bound(k): returns an iterator pointing to the first element with
11224key not less than k, or a.end() if such an element is not found.
11225</p>
11226
11227<p>
11228a.upper_bound(k): returns an iterator pointing to the first element with
11229key greater than k, or a.end() if such an element is not found.
11230</p>
11231</blockquote>
11232
11233<p><i>[Cura�ao: LWG reviewed PR.]</i></p>
11234
11235<hr>
11236<a name="355"><h3>355.&nbsp;Operational semantics for a.back()</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Yaroslav Mironov&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
11237
11238<p>Table 68 "Optional Sequence Operations" in 23.1.1/12
11239specifies operational semantics for "a.back()" as
11240"*--a.end()", which may be ill-formed <i>[because calling
11241operator-- on a temporary (the return) of a built-in type is
11242ill-formed]</i>, provided a.end() returns a simple pointer rvalue
11243(this is almost always the case for std::vector::end(), for
11244example). Thus, the specification is not only incorrect, it
11245demonstrates a dangerous construct: "--a.end()" may
11246successfully compile and run as intended, but after changing the type
11247of the container or the mode of compilation it may produce
11248compile-time error. </p>
11249
11250<p><b>Proposed resolution:</b></p>
11251<p>Change the specification in table 68 "Optional Sequence
11252Operations" in 23.1.1/12 for "a.back()" from</p>
11253
11254
11255<blockquote>
11256*--a.end()
11257</blockquote>
11258
11259<p>to</p>
11260
11261<blockquote>
11262  { iterator tmp = a.end(); --tmp; return *tmp; }
11263</blockquote>
11264
11265<p>and the specification for "a.pop_back()" from</p>
11266
11267<blockquote>
11268a.erase(--a.end())
11269</blockquote>
11270
11271<p>to</p>
11272
11273<blockquote>
11274  { iterator tmp = a.end(); --tmp; a.erase(tmp); }
11275</blockquote>
11276
11277<p><i>[Cura�ao: LWG changed PR from "{ X::iterator tmp =
11278a.end(); return *--tmp; }" to "*a.rbegin()", and from
11279"{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
11280"a.erase(rbegin())".]</i></p>
11281
11282<p><i>[There is a second possible defect; table 68 "Optional
11283Sequence Operations" in the "Operational Semantics"
11284column uses operations present only in the "Reversible
11285Container" requirements, yet there is no stated dependency
11286between these separate requirements tables. Ask in Santa Cruz if the
11287LWG would like a new issue opened.]</i></p>
11288
11289<p><i>[Santa Cruz: the proposed resolution is even worse than what's in
11290  the current standard: erase is undefined for reverse iterator.  If
11291  we're going to make the change, we need to define a temporary and
11292  use operator--.  Additionally, we don't know how prevalent this is:
11293  do we need to make this change in more than one place?  Martin has
11294  volunteered to review the standard and see if this problem occurs
11295  elsewhere.]</i></p>
11296
11297<p><i>[Oxford: Matt provided new wording to address the concerns raised
11298  in Santa Cruz.  It does not appear that this problem appears
11299  anywhere else in clauses 23 or 24.]</i></p>
11300
11301<p><i>[Kona: In definition of operational semantics of back(), change
11302"*tmp" to "return *tmp;"]</i></p>
11303
11304<hr>
11305<a name="358"><h3>358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
11306</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
11307<p>
11308I don't think <tt>thousands_sep</tt> is being treated correctly after
11309decimal_point has been seen. Since grouping applies only to the
11310integral part of the number, the first such occurrence should, IMO,
11311terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
11312and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
11313interpreted in the fractional part of a number.)
11314</p>
11315
11316<p>
11317The easiest change I can think of that resolves this issue would be
11318something like below.
11319</p>
11320<p><b>Proposed resolution:</b></p>
11321<p>
11322Change the first sentence of 22.2.2.1.2, p9 from
11323</p>
11324
11325<blockquote>
11326    If discard is true then the position of the character is
11327    remembered, but the character is otherwise ignored. If it is not
11328    discarded, then a check is made to determine if c is allowed as
11329    the next character of an input field of the conversion specifier
11330    returned by stage 1. If so it is accumulated.
11331</blockquote>
11332
11333<p>to</p>
11334
11335<blockquote>
11336    If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
11337    accumulated, then the position of the character is remembered, but
11338    the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
11339    already been accumulated, the character is discarded and Stage 2
11340     terminates. ...
11341</blockquote>
11342
11343<p><b>Rationale:</b></p>
11344<p>We believe this reflects the intent of the Standard.  Thousands sep
11345  characters after the decimal point are not useful in any locale.
11346  Some formatting conventions do group digits that follow the decimal
11347  point, but they usually introduce a different grouping character
11348  instead of reusing the thousand sep character.  If we want to add
11349  support for such conventions, we need to do so explicitly.</p>
11350
11351<hr>
11352<a name="359"><h3>359.&nbsp;num_put&lt;&gt;::do_put (..., bool) undocumented</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
11353<p>22.2.2.2.1, p1:</p>
11354
11355    <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11356                   bool val) const;
11357    ...
11358
11359    1   Returns: do_put (out, str, fill, val).
11360    </pre>
11361
11362<p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
11363however, 22.2.2.2.2, p23:</p>
11364
11365<blockquote>
11366<pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11367               bool val) const;
11368</pre>
11369
11370
11371        Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
11372             out = do_put(out, str, fill, (int)val)
11373           Otherwise do
11374<pre>             string_type s =
11375                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11376                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11377</pre>
11378           and then insert the characters of s into out. <i>out</i>.
11379</blockquote>
11380
11381<p>
11382This means that the bool overload of <tt>do_put()</tt> will never be called,
11383which contradicts the first paragraph. Perhaps the declaration
11384should read <tt>do_put()</tt>, and not <tt>put()</tt>?
11385</p>
11386
11387<p>
11388Note also that there is no <b>Returns</b> clause for this function, which
11389should probably be corrected, just as should the second occurrence
11390of <i>"out."</i> in the text.
11391</p>
11392
11393<p>
11394I think the least invasive change to fix it would be something like
11395the following:
11396</p>
11397<p><b>Proposed resolution:</b></p>
11398<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
11399  the <tt>bool</tt> overload.</p>
11400
11401<p>
11402In 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
11403</p>
11404
11405<blockquote>
11406     Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
11407     of the member function.
11408</blockquote>
11409
11410<blockquote>
11411    Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
11412    avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
11413    do_put (..., bool))</tt>
11414    like so:
11415</blockquote>
11416
11417<blockquote>
11418    23   <b>Returns</b>: If <tt>(str.flags() &amp;
11419         ios_base::boolalpha) == 0</tt> then
11420         <tt>do_put (out, str, fill, (long)val)</tt>
11421         Otherwise the function obtains a string <tt>s</tt> as if by
11422<pre>             string_type s =
11423                val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11424                    : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11425</pre>
11426         and then inserts each character <tt>c</tt> of s into out via
11427           <tt>*out++ = c</tt>
11428         and returns <tt>out</tt>.
11429</blockquote>
11430
11431<p><b>Rationale:</b></p>
11432<p>
11433This fixes a couple of obvious typos, and also fixes what appears to
11434be a requirement of gratuitous inefficiency.
11435</p>
11436<hr>
11437<a name="360"><h3>360.&nbsp;locale mandates inefficient implementation</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
11438<p>
1143922.1.1, p7 (copied below) allows iostream formatters and extractors
11440to make assumptions about the values returned from facet members.
11441However, such assumptions are apparently not guaranteed to hold
11442in other cases (e.g., when the facet members are being called directly
11443rather than as a result of iostream calls, or between successive
11444calls to the same iostream functions with no interevening calls to
11445<tt>imbue()</tt>, or even when the facet member functions are called
11446from other member functions of other facets). This restriction
11447prevents locale from being implemented efficiently.
11448</p>
11449<p><b>Proposed resolution:</b></p>
11450<p>Change the first sentence in 22.1.1, p7 from</p>
11451<blockquote>
11452    In successive calls to a locale facet member function during
11453    a call to an iostream inserter or extractor or a streambuf member
11454    function, the returned result shall be identical. [Note: This
11455    implies that such results may safely be reused without calling
11456    the locale facet member function again, and that member functions
11457    of iostream classes cannot safely call <tt>imbue()</tt>
11458    themselves, except as specified elsewhere. --end note]
11459</blockquote>
11460
11461<p>to</p>
11462
11463<blockquote>
11464    In successive calls to a locale facet member function on a facet
11465    object installed in the same locale, the returned result shall be
11466    identical. ...
11467</blockquote>
11468
11469<p><b>Rationale:</b></p>
11470<p>This change is reasonable becuase it clarifies the intent of this
11471  part of the standard.</p>
11472<hr>
11473<a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p><b>Section:</b>&nbsp;D.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.lib.binders"> [depr.lib.binders]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p>
11474<p>
11475The definition of bind1st() (<font color="red">20.5.6.2</font>) can result in
11476the construction of an unsafe binding between incompatible pointer
11477types. For example, given a function whose first parameter type is
11478'pointer to T', it's possible without error to bind an argument of
11479type 'pointer to U' when U does not derive from T:
11480</p>
11481<pre>   foo(T*, int);
11482
11483   struct T {};
11484   struct U {};
11485
11486   U u;
11487
11488   int* p;
11489   int* q;
11490
11491   for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
11492</pre>
11493
11494<p>
11495The definition of bind1st() includes a functional-style conversion to
11496map its argument to the expected argument type of the bound function
11497(see below):
11498</p>
11499<pre>  typename Operation::first_argument_type(x)
11500</pre>
11501
11502<p>
11503A functional-style conversion (5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
11504semantically equivalent to an explicit cast expression (5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
11505as a reinterpret_cast, thus masking the error.
11506</p>
11507
11508<p>The problem and proposed change also apply to <font color="red">20.5.6.4</font>.</p>
11509<p><b>Proposed resolution:</b></p>
11510<p>Add this sentence to the end of 20.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.arithmetic.operations"> [lib.arithmetic.operations]</a>/1:
11511  "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
11512  favor of <tt>std::tr1::bind</tt>."</p>
11513
11514<p>(Notes to editor: (1) when and if tr1::bind is incorporated into
11515  the standard, "std::tr1::bind" should be changed to "std::bind". (2)
11516  20.5.6 should probably be moved to Annex D.</p>
11517<p><b>Rationale:</b></p>
11518<p>There is no point in fixing bind1st and bind2nd.  tr1::bind is a
11519  superior solution.  It solves this problem and others.</p>
11520<hr>
11521<a name="363"><h3>363.&nbsp;Missing exception specification in 27.4.2.1.1</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown and Marc Paterno&nbsp; <b>Date:</b>&nbsp;20 May 2002</p>
11522<p>
11523The destructor of ios_base::failure should have an empty throw
11524specification, because the destructor of its base class, exception, is
11525declared in this way.
11526</p>
11527<p><b>Proposed resolution:</b></p>
11528<p>Change the destructor to</p>
11529<pre>  virtual ~failure() throw();
11530</pre>
11531<p><b>Rationale:</b></p>
11532<p>Fixes an obvious glitch.  This is almost editorial.</p>
11533<hr>
11534<a name="364"><h3>364.&nbsp;Inconsistent wording in 27.5.2.4.2</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown, Marc Paterno&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
11535<p>
1153627.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
11537clause for seekoff.
11538</p>
11539<p><b>Proposed resolution:</b></p>
11540<p>
11541Make this paragraph, the Effects clause for setbuf, consistent in wording
11542with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
11543to indicate the purpose of setbuf:
11544</p>
11545
11546<p>Original text:</p>
11547
11548<blockquote>
115491 Effects: Performs an operation that is defined separately for each
11550class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
11551</blockquote>
11552
11553<p>Proposed text:</p>
11554
11555<blockquote>
115561 Effects: Influences stream buffering in a way that is defined separately
11557for each class derived from basic_streambuf in this clause
11558(27.7.1.3, 27.8.1.4).
11559</blockquote>
11560
11561<p><b>Rationale:</b></p>
11562<p>The LWG doesn't believe there is any normative difference between
11563  the existing wording and what's in the proposed resolution, but the
11564  change may make the intent clearer.</p>
11565<hr>
11566<a name="365"><h3>365.&nbsp;Lack of const-qualification in clause 27</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown, Marc Paterno&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
11567<p>
11568Some stream and streambuf member functions are declared non-const,
11569even thought they appear only to report information rather than to
11570change an object's logical state.  They should be declared const.  See
11571document N1360 for details and rationale.
11572</p>
11573
11574<p>The list of member functions under discussion: <tt>in_avail</tt>,
11575<tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
11576
11577<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
11578
11579<p><b>Proposed resolution:</b></p>
11580<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>
11581<p>Replace</p>
11582<pre>  bool is_open();
11583</pre>
11584<p>with</p>
11585<pre>  bool is_open() const;
11586</pre>
11587<p><b>Rationale:</b></p>
11588<p>Of the changes proposed in N1360, the only one that is safe is
11589changing the filestreams' is_open to const.  The LWG believed that
11590this 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
11591member function, after all,is already const.</p>
11592
11593<p>The other proposed changes are less safe, because some streambuf
11594functions that appear merely to report a value do actually perform
11595mutating operations.  It's not even clear that they should be
11596considered "logically const", because streambuf has two interfaces, a
11597public one and a protected one.  These functions may, and often do,
11598change the state as exposed by the protected interface, even if the
11599state exposed by the public interface is unchanged.</p>
11600
11601<p>Note that implementers can make this change in a binary compatible
11602way by providing both overloads; this would be a conforming extension.</p>
11603
11604<hr>
11605<a name="369"><h3>369.&nbsp;io stream objects and static ctors</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
11606<p>
11607Is it safe to use standard iostream objects from constructors of
11608static objects?  Are standard iostream objects constructed and are
11609their associations established at that time?
11610</p>
11611
11612<p>Surpisingly enough, Standard does NOT require that.</p>
11613
11614<p>
1161527.3/2 [lib.iostream.objects] guarantees that standard iostream
11616objects are constructed and their associations are established before
11617the body of main() begins execution.  It also refers to ios_base::Init
11618class as the panacea for constructors of static objects.
11619</p>
11620
11621<p>
11622However, there's nothing in 27.3 [lib.iostream.objects],
11623in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
11624that would require implementations to allow access to standard
11625iostream objects from constructors of static objects.
11626</p>
11627
11628<p>Details:</p>
11629
11630<p>Core text refers to some magic object ios_base::Init, which will
11631be discussed below:</p>
11632
11633<blockquote>
11634    "The [standard iostream] objects are constructed, and their
11635    associations are established at some time prior to or during
11636    first time an object of class basic_ios&lt;charT,traits&gt;::Init
11637    is constructed, and in any case before the body of main
11638    begins execution." (27.3/2 [lib.iostream.objects])
11639</blockquote>
11640
11641<p>
11642The first <i>non-normative</i> footnote encourages implementations
11643to initialize standard iostream objects earlier than required.
11644</p>
11645
11646<p>However, the second <i>non-normative</i> footnote makes an explicit
11647and unsupported claim:</p>
11648
11649<blockquote>
11650  "Constructors and destructors for static objects can access these
11651  [standard iostream] objects to read input from stdin or write output
11652  to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
11653</blockquote>
11654
11655<p>
11656The only bit of magic is related to that ios_base::Init class.  AFAIK,
11657the rationale behind ios_base::Init was to bring an instance of this
11658class to each translation unit which #included &lt;iostream&gt; or
11659related header.  Such an inclusion would support the claim of footnote
11660quoted above, because in order to use some standard iostream object it
11661is necessary to #include &lt;iostream&gt;.
11662</p>
11663
11664<p>
11665However, while Standard explicitly describes ios_base::Init as
11666an appropriate class for doing the trick, I failed to found a
11667mention of an _instance_ of ios_base::Init in Standard.
11668</p>
11669<p><b>Proposed resolution:</b></p>
11670
11671<p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence
11672of the paragraph, the following two sentences:</p>
11673
11674<blockquote>
11675If a translation unit includes &lt;iostream&gt;, or explicitly
11676constructs an ios_base::Init object, these stream objects shall
11677be constructed before dynamic initialization of non-local
11678objects defined later in that translation unit, and these stream
11679objects shall be destroyed after the destruction of dynamically
11680initialized non-local objects defined later in that translation unit.
11681</blockquote>
11682
11683<p><i>[Lillehammer: Matt provided wording.]</i></p>
11684<p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
11685<p><b>Rationale:</b></p>
11686<p>
11687The original proposed resolution unconditionally required
11688implementations to define an ios_base::Init object of some
11689implementation-defined name in the header &lt;iostream&gt;. That's an
11690overspecification. First, defining the object may be unnecessary
11691and even detrimental to performance if an implementation can
11692guarantee that the 8 standard iostream objects will be initialized
11693before any other user-defined object in a program. Second, there
11694is no need to require implementations to document the name of the
11695object.</p>
11696
11697<p>
11698The new proposed resolution gives users guidance on what they need to
11699do to ensure that stream objects are constructed during startup.</p>
11700<hr>
11701<a name="370"><h3>370.&nbsp;Minor error in basic_istream::get</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;15 Jul 2002</p>
11702<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
11703with the following signature:</p>
11704
11705<pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
11706  sb);
11707</pre>
11708
11709<p>is incorrect. It reads</p>
11710
11711<blockquote>
11712  Effects: Calls get(s,n,widen('\n'))
11713</blockquote>
11714
11715<p>which I believe should be:</p>
11716
11717<blockquote>
11718  Effects: Calls get(sb,widen('\n'))
11719</blockquote>
11720<p><b>Proposed resolution:</b></p>
11721<p>Change the <b>Effects</b> paragraph to:</p>
11722<blockquote>
11723  Effects: Calls get(sb,this-&gt;widen('\n'))
11724</blockquote>
11725
11726<p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
11727      with 'this-&gt;widen'.]</i></p>
11728
11729<p><b>Rationale:</b></p>
11730<p>Fixes an obvious typo.</p>
11731<hr>
11732<a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
11733<p>
11734The requirements for multiset and multimap containers (23.1
11735[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
1173623.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
11737the stability of the required (mutating) member functions. It appears
11738the standard allows these functions to reorder equivalent elements of
11739the container at will, yet the pervasive red-black tree implementation
11740appears to provide stable behaviour.
11741</p>
11742
11743<p>This is of most concern when considering the behaviour of erase().
11744A stability requirement would guarantee the correct working of the
11745following 'idiom' that removes elements based on a certain predicate
11746function.
11747</p>
11748
11749<pre>  multimap&lt;int, int&gt; m;
11750  multimap&lt;int, int&gt;::iterator i = m.begin();
11751  while (i != m.end()) {
11752      if (pred(i))
11753          m.erase (i++);
11754      else
11755          ++i;
11756  }
11757</pre>
11758
11759<p>
11760Although clause 23.1.2/8 guarantees that i remains a valid iterator
11761througout this loop, absence of the stability requirement could
11762potentially result in elements being skipped. This would make
11763this code incorrect, and, furthermore, means that there is no way
11764of erasing these elements without iterating first over the entire
11765container, and second over the elements to be erased. This would
11766be unfortunate, and have a negative impact on both performance and
11767code simplicity.
11768</p>
11769
11770<p>
11771If the stability requirement is intended, it should be made explicit
11772(probably through an extra paragraph in clause 23.1.2).
11773</p>
11774<p>
11775If it turns out stability cannot be guaranteed, i'd argue that a
11776remark or footnote is called for (also somewhere in clause 23.1.2) to
11777warn against relying on stable behaviour (as demonstrated by the code
11778above).  If most implementations will display stable behaviour, any
11779problems emerging on an implementation without stable behaviour will
11780be hard to track down by users. This would also make the need for an
11781erase_if() member function that much greater.
11782</p>
11783
11784<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p>
11785
11786<p><b>Proposed resolution:</b></p>
11787
11788<p>Add the following to the end of 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 4:
11789"For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
11790  are <i>stable</i>: they preserve the relative ordering of equivalent
11791  elements.</p>
11792
11793<p><i>[Lillehammer: Matt provided wording]</i></p>
11794<p><i>[Joe Gottman points out that the provided wording does not address
11795multimap and multiset.  N1780 also addresses this issue and suggests
11796wording.]</i></p>
11797
11798<p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
11799
11800<p><b>Rationale:</b></p>
11801<p>The LWG agrees that this guarantee is necessary for common user
11802  idioms to work, and that all existing implementations provide this
11803  property.  Note that this resolution guarantees stability for
11804  multimap and multiset, not for all associative containers in
11805  general.</p>
11806
11807<hr>
11808<a name="373"><h3>373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Keith Baker&nbsp; <b>Date:</b>&nbsp;23 Jul 2002</p>
11809
11810<p>
11811In 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>
11812(exception()&amp;badbit) != 0 is used in testing for rethrow, yet
11813exception() 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.type.info"> [lib.type.info]</a> that has no return type. Should member function
11814exceptions() 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?
11815</p>
11816
11817<p><b>Proposed resolution:</b></p>
11818<p>
11819In 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
11820"(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
11821</p>
11822<p><b>Rationale:</b></p>
11823<p>Fixes an obvious typo.</p>
11824<hr>
11825<a name="375"><h3>375.&nbsp;basic_ios should be ios_base in 27.7.1.3</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
11826<p>
11827In 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
1182814 all contain references to "basic_ios::" which should be
11829"ios_base::".
11830</p>
11831<p><b>Proposed resolution:</b></p>
11832<p>
11833Change all references to "basic_ios" in Table 90, Table 91, and
11834paragraph 14 to "ios_base".
11835</p>
11836<p><b>Rationale:</b></p>
11837<p>Fixes an obvious typo.</p>
11838<hr>
11839<a name="376"><h3>376.&nbsp;basic_streambuf semantics</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
11840<p>
11841In 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, the implication is that
11842the four conditions should be mutually exclusive, but they are not.
11843The first two cases, as written, are subcases of the third.</p>
11844
11845<p>
11846As written, it is unclear what should be the result if cases 1 and 2
11847are both true, but case 3 is false.
11848</p>
11849
11850<p><b>Proposed resolution:</b></p>
11851
11852<p>Rewrite these conditions as:</p>
11853<blockquote>
11854<p>
11855  (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
11856</p>
11857
11858<p>
11859  (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
11860</p>
11861
11862<p>
11863  (which &amp; (ios_base::in|ios_base::out)) ==
11864(ios_base::in|ios_base::out)
11865   and way == either ios_base::beg or ios_base::end
11866</p>
11867
11868<p>Otherwise</p>
11869</blockquote>
11870
11871<p><b>Rationale:</b></p>
11872<p>It's clear what we wanted to say, we just failed to say it.  This
11873  fixes it.</p>
11874<hr>
11875<a name="379"><h3>379.&nbsp;nonsensical ctype::do_widen() requirement</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
11876<p>
11877The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
11878</p>
11879<pre>  charT do_widen (char c) const;
11880
11881  -11- Effects: Applies the simplest reasonable transformation from
11882       a char value or sequence of char values to the corresponding
11883       charT value or values. The only characters for which unique
11884       transformations are required are those in the basic source
11885       character set (2.2). For any named ctype category with a
11886       ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
11887       M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
11888</pre>
11889<p>
11890Shouldn't the last sentence instead read
11891</p>
11892<pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11893       and valid ctype_base::mask value M
11894       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11895</pre>
11896<p>
11897I.e., if the narrow character c is not a member of a class of
11898characters then neither is the widened form of c. (To paraphrase
11899footnote 224.)
11900</p>
11901<p><b>Proposed resolution:</b></p>
11902<p>
11903Replace 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
11904following text:
11905</p>
11906<pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11907       and valid ctype_base::mask value M,
11908       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11909</pre>
11910
11911<p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
11912
11913<p><b>Rationale:</b></p>
11914<p>The LWG believes this is just a typo, and that this is the correct fix.</p>
11915<hr>
11916<a name="380"><h3>380.&nbsp;typos in codecvt tables 53 and 54</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
11917<p>
11918Tables 53 and 54 in 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a> are both titled "convert
11919result values," when surely "do_in/do_out result values" must have
11920been intended for Table 53 and "do_unshift result values" for Table
1192154.
11922</p>
11923<p>
11924Table 54, row 3 says that the meaning of partial is "more characters
11925needed to be supplied to complete termination." The function is not
11926supplied any characters, it is given a buffer which it fills with
11927characters or, more precisely, destination elements (i.e., an escape
11928sequence). So partial means that space for more than (to_limit - to)
11929destination elements was needed to terminate a sequence given the
11930value of state.
11931</p>
11932<p><b>Proposed resolution:</b></p>
11933<p>
11934Change the title of Table 53 to "do_in/do_out result values" and
11935the title of Table 54 to "do_unshift result values."
11936</p>
11937<p>
11938Change the text in Table 54, row 3 (the <b>partial</b> row), under the
11939heading Meaning, to "space for more than (to_limit - to) destination
11940elements was needed to terminate a sequence given the value of state."
11941</p>
11942<hr>
11943<a name="381"><h3>381.&nbsp;detection of invalid mbstate_t in codecvt</h3></a><p><b>Section:</b>&nbsp;22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
11944<p>
11945All but one codecvt member functions that take a state_type argument
11946list as one of their preconditions that the state_type argument have
11947a valid value. However, according to 22.2.1.5.2, p6,
11948codecvt::do_unshift() is the only codecvt member that is supposed to
11949return error if the state_type object is invalid.
11950</p>
11951
11952<p>
11953It seems to me that the treatment of state_type by all codecvt member
11954functions should be the same and the current requirements should be
11955changed. Since the detection of invalid state_type values may be
11956difficult in general or computationally expensive in some specific
11957cases, I propose the following:
11958</p>
11959<p><b>Proposed resolution:</b></p>
11960<p>
11961Add a new paragraph before 22.2.1.5.2, p5, and after the function
11962declaration below
11963</p>
11964<pre>    result do_unshift(stateT&amp; state,
11965    externT* to, externT* to_limit, externT*&amp; to_next) const;
11966</pre>
11967<p>
11968as follows:
11969</p>
11970<pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
11971    if at the beginning of a sequence, or else equal to the result of
11972    converting the preceding characters in the sequence.
11973</pre>
11974<p>
11975and change the text in Table 54, row 4, the <b>error</b> row, under
11976the heading Meaning, from
11977</p>
11978<pre>    state has invalid value
11979</pre>
11980<p>
11981to
11982</p>
11983<pre>    an unspecified error has occurred
11984</pre>
11985<p><b>Rationale:</b></p>
11986<p>The intent is that implementations should not be required to detect
11987invalid state values; such a requirement appears nowhere else.  An
11988invalid state value is a precondition violation, <i>i.e.</i> undefined
11989behavior.  Implementations that do choose to detect invalid state
11990values, or that choose to detect any other kind of error, may return
11991<b>error</b> as an indication.</p>
11992<hr>
11993<a name="383"><h3>383.&nbsp;Bidirectional iterator assertion typo</h3></a><p><b>Section:</b>&nbsp;24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;ysapir (submitted via comp.std.c++)&nbsp; <b>Date:</b>&nbsp;17 Oct 2002</p>
11994<p>
11995Following a discussion on the boost list regarding end iterators and
11996the possibility of performing operator--() on them, it seems to me
11997that there is a typo in the standard.  This typo has nothing to do
11998with that discussion.
11999</p>
12000
12001<p>
12002I have checked this newsgroup, as well as attempted a search of the
12003Active/Defect/Closed Issues List on the site for the words "s is
12004derefer" so I believe this has not been proposed before.  Furthermore,
12005the "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
1200624.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.
12007</p>
12008
12009<p>
12010The standard makes the following assertion on bidirectional iterators,
12011in section 24.1.4 [lib.bidirectional.iterators], Table 75:
12012</p>
12013
12014<pre>                         operational  assertion/note
12015expression  return type   semantics    pre/post-condition
12016
12017--r          X&amp;                        pre: there exists s such
12018                                       that r == ++s.
12019                                       post: s is dereferenceable.
12020                                       --(++r) == r.
12021                                       --r == --s implies r == s.
12022                                       &amp;r == &amp;--r.
12023</pre>
12024
12025<p>
12026(See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
12027</p>
12028
12029<p>
12030In particular, "s is dereferenceable" seems to be in error.  It seems
12031that the intention was to say "r is dereferenceable".
12032</p>
12033
12034<p>
12035If it were to say "r is dereferenceable" it would
12036make perfect sense.  Since s must be dereferenceable prior to
12037operator++, then the natural result of operator-- (to undo operator++)
12038would be to make r dereferenceable.  Furthermore, without other
12039assertions, and basing only on precondition and postconditions, we
12040could not otherwise know this.  So it is also interesting information.
12041</p>
12042
12043<p><b>Proposed resolution:</b></p>
12044<p>
12045Change the guarantee to "postcondition: r is dereferenceable."
12046</p>
12047<p><b>Rationale:</b></p>
12048<p>Fixes an obvious typo</p>
12049<hr>
12050<a name="384"><h3>384.&nbsp;equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b>&nbsp;25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;18 Oct 2002</p>
12051<p>
12052Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>
12053states that at most 2 * log(last - first) + 1
12054comparisons are allowed for equal_range.
12055</p>
12056
12057<p>It is not possible to implement equal_range with these constraints.</p>
12058
12059<p>In a range of one element as in:</p>
12060<pre>    int x = 1;
12061    equal_range(&amp;x, &amp;x + 1, 1)
12062</pre>
12063
12064<p>it is easy to see that at least 2 comparison operations are needed.</p>
12065
12066<p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
12067
12068<p>I have checked a few libraries and they all use the same (nonconforming)
12069algorithm for equal_range that has a complexity of</p>
12070<pre>     2* log(distance(first, last)) + 2.
12071</pre>
12072<p>I guess this is the algorithm that the standard assumes for equal_range.</p>
12073
12074<p>
12075It is easy to see that 2 * log(distance) + 2 comparisons are enough
12076since equal range can be implemented with lower_bound and upper_bound
12077(both log(distance) + 1).
12078</p>
12079
12080<p>
12081I think it is better to require something like 2log(distance) + O(1)  (or
12082even logarithmic as multiset::equal_range).
12083Then an implementation has more room to optimize for certain cases (e.g.
12084have log(distance) characteristics when at most match is found in the range
12085but 2log(distance) + 4 for the worst case).
12086</p>
12087
12088<p><b>Proposed resolution:</b></p>
12089<p>In 25.3.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.lower.bound"> [lib.lower.bound]</a>/4, change <tt>log(last - first) + 1</tt>
12090to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
12091
12092<p>In 25.3.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.upper.bound"> [lib.upper.bound]</a>/4, change <tt>log(last - first) + 1</tt>
12093to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
12094
12095<p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>/4, change <tt>2*log(last - first) + 1</tt>
12096to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
12097
12098<p><i>[Matt provided wording]</i></p>
12099<p><b>Rationale:</b></p>
12100<p>The LWG considered just saying <i>O</i>(log n) for all three, but
12101� decided that threw away too much valuable information.� The fact
12102� that lower_bound is twice as fast as equal_range is important.
12103� However, it's better to allow an arbitrary additive constant than to
12104� specify an exact count.� An exact count would have to
12105� involve <tt>floor</tt> or <tt>ceil</tt>.� It would be too easy to
12106� get this wrong, and don't provide any substantial value for users.</p>
12107<hr>
12108<a name="386"><h3>386.&nbsp;Reverse iterator's operator[] has impossible return type</h3></a><p><b>Section:</b>&nbsp;24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op-="> [lib.reverse.iter.op-=]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Oct 2002</p>
12109<p>In 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op-="> [lib.reverse.iter.op-=]</a>, <tt>reverse_iterator&lt;&gt;::operator[]</tt>
12110is specified as having a return type of <tt>reverse_iterator::reference</tt>,
12111which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
12112(Where <tt>Iterator</tt> is the underlying iterator type.)</p>
12113
12114<p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
12115  necessarily have a return type
12116  of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
12117  return type is merely required to be convertible
12118  to <tt>Iterator</tt>'s value type.  The return type specified for
12119  reverse_iterator's operator[] would thus appear to be impossible.</p>
12120
12121<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
12122  <tt>a[n]</tt> will continue to be required (for random access
12123  iterators) to be convertible to the value type, and also <tt>a[n] =
12124  t</tt> will be a valid expression.  Implementations of
12125  <tt>reverse_iterator</tt> will likely need to return a proxy from
12126  <tt>operator[]</tt> to meet these requirements. As mentioned in the
12127  comment from Dave Abrahams, the simplest way to specify that
12128  <tt>reverse_iterator</tt> meet this requirement to just mandate
12129  it and leave the return type of <tt>operator[]</tt> unspecified.</p>
12130
12131<p><b>Proposed resolution:</b></p>
12132
12133<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>
12134
12135<blockquote>
12136<pre>reference operator[](difference_type n) const;
12137</pre>
12138</blockquote>
12139
12140<p>to:</p>
12141
12142<blockquote>
12143<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see <font color="red">lib.random.access.iterators</font>
12144</pre>
12145</blockquote>
12146
12147
12148
12149
12150<p><i>[
12151Comments from Dave Abrahams: IMO we should resolve 386 by just saying
12152    that the return type of reverse_iterator's operator[] is
12153    unspecified, allowing the random access iterator requirements to
12154    impose an appropriate return type.  If we accept 299's proposed
12155    resolution (and I think we should), the return type will be
12156    readable and writable, which is about as good as we can do.
12157]</i></p>
12158<hr>
12159<a name="389"><h3>389.&nbsp;Const overload of valarray::operator[] returns by value</h3></a><p><b>Section:</b>&nbsp;26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;8 Nov 2002</p>
12160<p>Consider the following program:</p>
12161<pre>    #include &lt;iostream&gt;
12162    #include &lt;ostream&gt;
12163    #include &lt;vector&gt;
12164    #include &lt;valarray&gt;
12165    #include &lt;algorithm&gt;
12166    #include &lt;iterator&gt;
12167    template&lt;typename Array&gt;
12168    void print(const Array&amp; a)
12169    {
12170    using namespace std;
12171    typedef typename Array::value_type T;
12172    copy(&amp;a[0], &amp;a[0] + a.size(),
12173    ostream_iterator&lt;T&gt;(std::cout, " "));
12174    }
12175    template&lt;typename T, unsigned N&gt;
12176    unsigned size(T(&amp;)[N]) { return N; }
12177    int main()
12178    {
12179    double array[] = { 0.89, 9.3, 7, 6.23 };
12180    std::vector&lt;double&gt; v(array, array + size(array));
12181    std::valarray&lt;double&gt; w(array, size(array));
12182    print(v); // #1
12183    std::cout &lt;&lt; std::endl;
12184    print(w); // #2
12185    std::cout &lt;&lt; std::endl;
12186    }
12187</pre>
12188
12189<p>While the call numbered #1 succeeds, the call numbered #2 fails
12190because the const version of the member function
12191valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
12192const-reference. That seems to be so for no apparent reason, no
12193benefit. Not only does that defeats users' expectation but it also
12194does hinder existing software (written either in C or Fortran)
12195integration within programs written in C++.  There is no reason why
12196subscripting an expression of type valarray&lt;T&gt; that is const-qualified
12197should not return a const T&amp;.</p>
12198<p><b>Proposed resolution:</b></p>
12199<p>In the class synopsis in 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a>, and in
12200<font color="red">26.3.2.3</font> just above paragraph 1, change</p>
12201<pre>  T operator[](size_t const);
12202</pre>
12203<p>to</p>
12204<pre>  const T&amp; operator[](size_t const);
12205</pre>
12206
12207<p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
12208  wehre it belongs.]</i></p>
12209
12210<p><b>Rationale:</b></p>
12211<p>Return by value seems to serve no purpose.  Valaray was explicitly
12212designed to have a specified layout so that it could easily be
12213integrated with libraries in other languages, and return by value
12214defeats that purpose.  It is believed that this change will have no
12215impact on allowable optimizations.</p>
12216<hr>
12217<a name="391"><h3>391.&nbsp;non-member functions specified as const</h3></a><p><b>Section:</b>&nbsp;22.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.conversions"> [lib.conversions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;10 Dec 2002</p>
12218<p>
12219The specifications of toupper and tolower both specify the functions as
12220const, althought they are not member functions, and are not specified as
12221const 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>.
12222</p>
12223<p><b>Proposed resolution:</b></p>
12224<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
12225  declarations of std::toupper and std::tolower</p>
12226<p><b>Rationale:</b></p>
12227<p>Fixes an obvious typo</p>
12228<hr>
12229<a name="395"><h3>395.&nbsp;inconsistencies in the definitions of rand() and random_shuffle()</h3></a><p><b>Section:</b>&nbsp;26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;3 Jan 2003</p>
12230<p>
12231In 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a>, the C++ standard refers to the C standard for the
12232definition of rand(); in the C standard, it is written that "The
12233implementation shall behave as if no library function calls the rand
12234function."
12235</p>
12236
12237<p>
12238In 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
12239how the two parameter version of the function generates its random
12240value.  I believe that all current implementations in fact call rand()
12241(in contradiction with the requirement avove); if an implementation does
12242not call rand(), there is the question of how whatever random generator
12243it does use is seeded.  Something is missing.
12244</p>
12245
12246<p><b>Proposed resolution:</b></p>
12247<p>
12248In [lib.c.math], add a paragraph specifying that the C definition of
12249rand shal be modified to say that "Unless otherwise specified, the
12250implementation shall behave as if no library function calls the rand
12251function."
12252</p>
12253
12254<p>
12255In [lib.alg.random.shuffle], add a sentence to the effect that "In
12256the two argument form of the function, the underlying source of
12257random numbers is implementation defined. [Note: in particular, an
12258implementation is permitted to use <tt>rand</tt>.]
12259</p>
12260<p><b>Rationale:</b></p>
12261<p>The original proposed resolution proposed requiring the
12262  two-argument from of <tt>random_shuffle</tt> to
12263  use <tt>rand</tt>. We don't want to do that, because some existing
12264  implementations already use something else: gcc
12265  uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
12266  problem if the number of elements in the sequence is greater than
12267  RAND_MAX.</p>
12268<hr>
12269<a name="400"><h3>400.&nbsp;redundant type cast in lib.allocator.members</h3></a><p><b>Section:</b>&nbsp;20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
12270<p>
1227120.6.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
12272the following 3 lines:
12273</p>
12274
12275<pre>  12 Returns: new((void *) p) T( val)
12276     void destroy(pointer p);
12277  13 Returns: ((T*) p)-&gt;~T()
12278</pre>
12279
12280<p>
12281The type cast "(T*) p" in the last line is redundant cause
12282we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
12283</p>
12284<p><b>Proposed resolution:</b></p>
12285<p>
12286Replace "((T*) p)" with "p".
12287</p>
12288<p><b>Rationale:</b></p>
12289<p>Just a typo, this is really editorial.</p>
12290<hr>
12291<a name="402"><h3>402.&nbsp;wrong new expression in [some_]allocator::construct</h3></a><p><b>Section:</b>&nbsp;20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a>, 20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>, &nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
12292<p>
12293This applies to the new expression that is contained in both par12 of
1229420.6.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.default.con.req"> [lib.default.con.req]</a>.
12295I think this new expression is wrong, involving unintended side
12296effects.
12297</p>
12298
12299
12300<p>20.6.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>
12301
12302<pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
12303     void construct(pointer p, const_reference val);
12304  12 Returns: new((void *) p) T( val)
12305</pre>
12306
12307
12308<p>20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> in table 32 has the following line:</p>
12309<pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
12310</pre>
12311
12312<p>
12313.... with the prerequisits coming from the preceding two paragraphs,
12314especially from table 31:
12315</p>
12316
12317<pre>  alloc&lt;T&gt;             a     ;// an allocator for T
12318  alloc&lt;T&gt;::pointer    p     ;// random access iterator
12319                              // (may be different from T*)
12320  alloc&lt;T&gt;::reference  r = *p;// T&amp;
12321  T const&amp;             t     ;
12322</pre>
12323
12324<p>
12325Cause of using "new" but not "::new", any existing "T::operator new"
12326function will hide the global placement new function. When there is no
12327"T::operator new" with adequate signature,
12328every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
12329std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
12330would be adding placement new and delete functions with adequate
12331signature and semantic to class T, but class T might come from another
12332party. Maybe even worse is the case when T has placement new and
12333delete functions with adequate signature but with "unknown" semantic:
12334I dont like to speculate about it, but whoever implements
12335any_container&lt;T,any_alloc&gt; and wants to use construct(..)
12336probably must think about it.
12337</p>
12338<p><b>Proposed resolution:</b></p>
12339<p>
12340Replace "new" with "::new" in both cases.
12341</p>
12342<hr>
12343<a name="403"><h3>403.&nbsp;basic_string::swap should not throw exceptions</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;25 Mar 2003</p>
12344
12345<p>
12346std::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
12347basic_string "conforms to the requirements of a Sequence, as specified
12348in (23.1.1)." The sequence requirements specified in (23.1.1) to not
12349include any prohibition on swap members throwing exceptions.
12350</p>
12351
12352<p>
12353Section 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
12354which exceptions may be thrown, but applies only to "all container
12355types defined in this clause" and so excludes basic_string::swap
12356because it is defined elsewhere.
12357</p>
12358
12359<p>
12360Eric 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
12361permits basic_string::swap to invalidates iterators, which is
12362disallowed 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
12363be contradictory if it were read or extended to read as having
12364basic_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.
12365</p>
12366
12367<p>
12368Yet several LWG members have expressed the belief that the original
12369intent was that basic_string::swap should not throw exceptions as
12370specified 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
12371unclear on this issue. The complexity of basic_string::swap is
12372specified as "constant time", indicating the intent was to avoid
12373copying (which could cause a bad_alloc or other exception). An
12374important use of swap is to ensure that exceptions are not thrown in
12375exception-safe code.
12376</p>
12377
12378<p>
12379Note: There remains long standing concern over whether or not it is
12380possible 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
12381requirements when allocators are unequal. The specification of
12382basic_string::swap exception requirements is in no way intended to
12383address, prejudice, or otherwise impact that concern.
12384</p>
12385
12386
12387
12388
12389
12390<p><b>Proposed resolution:</b></p>
12391<p>
12392In 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:
12393</p>
12394
12395<p>
12396Throws: Shall not throw exceptions.
12397</p>
12398<hr>
12399<a name="404"><h3>404.&nbsp;May a replacement allocation function be declared inline?</h3></a><p><b>Section:</b>&nbsp;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.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Apr 2003</p>
12400<p>
12401The eight basic dynamic memory allocation functions (single-object
12402and array versions of ::operator new and ::operator delete, in the
12403ordinary and nothrow forms) are replaceable.  A C++ program may
12404provide an alternative definition for any of them, which will be used
12405in preference to the implementation's definition.
12406</p>
12407
12408<p>
12409Three different parts of the standard mention requirements on
12410replacement 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.5.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>
12411and 18.5.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>.
12412</p>
12413
12414<p>None of these three places say whether a replacement function may
12415  be declared inline.  18.5.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
12416  signature for the replacement function, but that's not enough:
12417  the <tt>inline</tt> specifier is not part of a function's signature.
12418  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
12419  requires that "an inline function shall be defined in every
12420  translation unit in which it is used," but this may not be quite
12421  specific enough either.  We should either explicitly allow or
12422  explicitly forbid inline replacement memory allocation
12423  functions.</p>
12424<p><b>Proposed resolution:</b></p>
12425<p>
12426Add 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:
12427"The program's definitions shall not be specified as <tt>inline</tt>.
12428No diagnostic is required."
12429</p>
12430
12431<p><i>[Kona: added "no diagnostic is required"]</i></p>
12432
12433<p><b>Rationale:</b></p>
12434<p>
12435The fact that <tt>inline</tt> isn't mentioned appears to have been
12436nothing more than an oversight.  Existing implementations do not
12437permit inline functions as replacement memory allocation functions.
12438Providing this functionality would be difficult in some cases, and is
12439believed to be of limited value.
12440</p>
12441<hr>
12442<a name="405"><h3>405.&nbsp;qsort and POD</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;08 Apr 2003</p>
12443<p>
12444Section 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
12445standard library. Paragraph 4 does not list any restrictions on qsort,
12446but it should limit the base parameter to point to POD.  Presumably,
12447qsort sorts the array by copying bytes, which requires POD.
12448</p>
12449<p><b>Proposed resolution:</b></p>
12450<p>
12451In 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
12452before the nonnormative note, add these words: "both of which have the
12453same behavior as the original declaration.  The behavior is undefined
12454unless the objects in the array pointed to by <i>base</i> are of POD
12455type."
12456</p>
12457
12458<p><i>[Something along these lines is clearly necessary.  Matt
12459  provided wording.]</i></p>
12460<hr>
12461<a name="406"><h3>406.&nbsp;vector::insert(s) exception safety</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;27 Apr 2003</p>
12462<p>
12463There is a possible defect in the standard: the standard text was
12464never intended to prevent arbitrary ForwardIterators, whose operations
12465may throw exceptions, from being passed, and it also wasn't intended
12466to require a temporary buffer in the case where ForwardIterators were
12467passed (and I think most implementations don't use one).  As is, the
12468standard appears to impose requirements that aren't met by any
12469existing implementation.
12470</p>
12471<p><b>Proposed resolution:</b></p>
12472<p>Replace 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1 with:</p>
12473<blockquote>
12474  1- Notes: Causes reallocation if the new size is greater than the
12475  old capacity. If no reallocation happens, all the iterators and
12476  references before the insertion point remain valid. If an exception
12477  is thrown other than by the copy constructor or assignment operator
12478  of T or by any InputIterator operation there are no effects.
12479</blockquote>
12480
12481<p><i>[We probably need to say something similar for deque.]</i></p>
12482
12483<hr>
12484<a name="407"><h3>407.&nbsp;Can singular iterators be destroyed?</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;3 June 2003</p>
12485<p>
12486Clause 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
12487that is defined for a singular iterator is "an assignment of a
12488non-singular value to an iterator that holds a singular value".  This
12489means that destroying a singular iterator (e.g. letting an automatic
12490variable go out of scope) is technically undefined behavior.  This
12491seems overly strict, and probably unintentional.
12492</p>
12493<p><b>Proposed resolution:</b></p>
12494<p>
12495Change the sentence in question to "... the only exceptions are
12496destroying an iterator that holds a singular value, or the assignment
12497of a non-singular value to an iterator that holds a singular value."
12498</p>
12499<hr>
12500<a name="409"><h3>409.&nbsp;Closing an fstream should clear error state</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;3 June 2003</p>
12501<p>
12502A 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
12503closing a basic_[io]fstream does not affect the error bits.  This
12504means, for example, that if you read through a file up to EOF, and
12505then close the stream and reopen it at the beginning of the file,
12506the EOF bit in the stream's error state is still set.  This is
12507counterintuitive.
12508</p>
12509<p>
12510The 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>,
12511and put in a footnote to clarify that the strict reading was indeed
12512correct.  We did that because we believed the standard was
12513unambiguous and consistent, and that we should not make architectural
12514changes in a TC.  Now that we're working on a new revision of the
12515language, those considerations no longer apply.
12516</p>
12517<p><b>Proposed resolution:</b></p>
12518
12519<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>
12520
12521<blockquote>
12522Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
12523pointer, calls setstate(failbit) (which may throw ios_base::failure
12524[Footnote: (lib.iostate.flags)].
12525</blockquote>
12526
12527<p>to:</p>
12528
12529<blockquote>Calls rdbuf()-&gt;open(s,mode|in). If that function returns
12530a null pointer, calls setstate(failbit) (which may throw
12531ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
12532</blockquote>
12533
12534<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>
12535
12536<blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
12537returns a null pointer, calls setstate(failbit) (which may throw
12538ios_base::failure [Footnote: (lib.iostate.flags)).
12539</blockquote>
12540
12541<p>to:</p>
12542
12543<blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
12544returns a null pointer, calls setstate(failbit) (which may throw
12545ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
12546</blockquote>
12547
12548<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>
12549
12550<blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
12551null pointer, calls setstate(failbit), (which may throw
12552ios_base::failure). (lib.iostate.flags) )
12553</blockquote>
12554
12555<p>to:</p>
12556
12557<blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
12558null pointer, calls setstate(failbit), (which may throw
12559ios_base::failure). (lib.iostate.flags) ), else calls clear().
12560</blockquote>
12561
12562
12563
12564<p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
12565provided wording.  He suggests having open, not close, clear the error
12566flags.]</i></p>
12567
12568<p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
12569  old one didn't make sense because it proposed to fix this at the
12570  level of basic_filebuf, which doesn't have access to the stream's
12571  error state.  Howard's proposed resolution fixes this at the level
12572  of the three fstream class template instead.]</i></p>
12573
12574<hr>
12575<a name="410"><h3>410.&nbsp;Missing semantics for stack and queue comparison operators</h3></a><p><b>Section:</b>&nbsp;23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;7 Jun 2003</p>
12576<p>
12577Sections 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a> and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.modifiers]</a> list
12578comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
12579stack.  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.list.cons"> [lib.list.cons]</a> par2) and queue::operator&lt; (23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a>
12580par3) are defined.
12581</p>
12582<p><b>Proposed resolution:</b></p>
12583
12584<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.list.cons"> [lib.list.cons]</a>
12585  paragraph 3:</p>
12586
12587<blockquote>
12588
12589<pre>  operator!=
12590</pre>
12591<p>Returns: <tt>x.c != y.c</tt></p>
12592
12593<pre>  operator&gt;
12594</pre>
12595<p>Returns: <tt>x.c &gt; y.c</tt></p>
12596
12597<pre>  operator&lt;=
12598</pre>
12599<p>Returns: <tt>x.c &lt;= y.c</tt></p>
12600
12601<pre>  operator&gt;=
12602</pre>
12603<p>Returns: <tt>x.c &gt;= y.c</tt></p>
12604
12605</blockquote>
12606
12607<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.list.modifiers"> [lib.list.modifiers]</a>:</p>
12608
12609<blockquote>
12610
12611<pre>  operator==
12612</pre>
12613<p>Returns: <tt>x.c == y.c</tt></p>
12614
12615<pre>  operator&lt;
12616</pre>
12617<p>Returns: <tt>x.c &lt; y.c</tt></p>
12618
12619<pre>  operator!=
12620</pre>
12621<p>Returns: <tt>x.c != y.c</tt></p>
12622
12623<pre>  operator&gt;
12624</pre>
12625<p>Returns: <tt>x.c &gt; y.c</tt></p>
12626
12627<pre>  operator&lt;=
12628</pre>
12629<p>Returns: <tt>x.c &lt;= y.c</tt></p>
12630
12631<pre>  operator&gt;=
12632</pre>
12633<p>Returns: <tt>x.c &gt;= y.c</tt></p>
12634
12635</blockquote>
12636
12637
12638<p><i>[Kona: Matt provided wording.]</i></p>
12639
12640<p><b>Rationale:</b></p>
12641There isn't any real doubt about what these operators are
12642supposed to do, but we ought to spell it out.
12643<hr>
12644<a name="411"><h3>411.&nbsp;Wrong names of set member functions</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Daniel Frey&nbsp; <b>Date:</b>&nbsp;9 Jul 2003</p>
12645<p>
1264625.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:
12647"The semantics of the set operations are generalized to multisets in a
12648standard way by defining union() to contain the maximum number of
12649occurrences of every element, intersection() to contain the minimum, and
12650so on."
12651</p>
12652
12653<p>
12654This is wrong.  The name of the functions are set_union() and
12655set_intersection(), not union() and intersection().
12656</p>
12657<p><b>Proposed resolution:</b></p>
12658<p>Change that sentence to use the correct names.</p>
12659<hr>
12660<a name="412"><h3>412.&nbsp;Typo in 27.4.4.3</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;10 Jul 2003</p>
12661<p>
12662The 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
12663function only throws if the respective bits are already set prior to
12664the function call. That's obviously not the intent. The typo ought to
12665be corrected and the text reworded as: "If (<i>state</i> &amp;
12666exceptions()) == 0, returns. ..."
12667</p>
12668<p><b>Proposed resolution:</b></p>
12669<p>
12670In 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() &amp;
12671exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
12672&amp; exceptions()) == 0".
12673</p>
12674
12675<p><i>[Kona: the original proposed resolution wasn't quite right.  We
12676  really do mean rdstate(); the ambiguity is that the wording in the
12677  standard doesn't make it clear whether we mean rdstate() before
12678  setting the new state, or rdsate() after setting it.  We intend the
12679  latter, of course. Post-Kona: Martin provided wording.]</i></p>
12680
12681<hr>
12682<a name="413"><h3>413.&nbsp;Proposed resolution to LDR#64 still wrong</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bo Persson&nbsp; <b>Date:</b>&nbsp;13 Jul 2003</p>
12683<p>
12684The second sentence of the proposed resolution says:
12685</p>
12686
12687<p>
12688"If it inserted no characters because it caught an exception thrown
12689while extracting characters from sb and ..."
12690</p>
12691
12692<p>
12693However, we are not extracting from sb, but extracting from the
12694basic_istream (*this) and inserting into sb. I can't really tell if
12695"extracting" or "sb" is a typo.
12696</p>
12697
12698<p><i>[
12699Sydney: Definitely a real issue. We are, indeed, extracting characters
12700from an istream and not from sb. The problem was there in the FDIS and
12701wasn'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
12702to have *this instead of sb. We're talking about the exception flag
12703state of a basic_istream object, and there's only one basic_istream
12704object in this discussion, so that would be a consistent
12705interpretation.  (But we need to be careful: the exception policy of
12706this member function must be consistent with that of other
12707extractors.)  PJP will provide wording.
12708]</i></p>
12709
12710<p><b>Proposed resolution:</b></p>
12711<p>Change the sentence from:</p>
12712
12713<blockquote>
12714If it inserted no characters because it caught an exception thrown
12715while extracting characters from sb and failbit is on in exceptions(),
12716then the caught exception is rethrown.
12717</blockquote>
12718
12719<p>to:</p>
12720
12721<blockquote>
12722If it inserted no characters because it caught an exception thrown
12723while extracting characters from *this and failbit is on in exceptions(),
12724then the caught exception is rethrown.
12725</blockquote>
12726<hr>
12727<a name="414"><h3>414.&nbsp;Which iterators are invalidated by v.erase()?</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Aug 2003</p>
12728<p>
12729Consider the following code fragment:
12730</p>
12731<blockquote>
12732<pre>int A[8] = { 1,3,5,7,9,8,4,2 };
12733std::vector&lt;int&gt; v(A, A+8);
12734
12735std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
12736std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
12737v.erase(i1);
12738</pre>
12739</blockquote>
12740
12741<p>
12742Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
12743both, or neither?
12744</p>
12745
12746<p>
12747On all existing implementations that I know of, the status of i1 and
12748i2 is the same: both of them will be iterators that point to some
12749elements of the vector (albeit not the same elements they did
12750before).  You won't get a crash if you use them.  Depending on
12751exactly what you mean by "invalidate", you might say that neither one
12752has been invalidated because they still point to <i>something</i>,
12753or you might say that both have been invalidated because in both
12754cases the elements they point to have been changed out from under the
12755iterator.
12756</p>
12757
12758<p>
12759The standard doesn't say either of those things.  It says that erase
12760invalidates all iterators and references "after the point of the
12761erase".  This doesn't include i1, since it's at the point of the
12762erase instead of after it.  I can't think of any sensible definition
12763of invalidation by which one can say that i2 is invalidated but i1
12764isn't.
12765</p>
12766
12767<p>
12768(This issue is important if you try to reason about iterator validity
12769based only on the guarantees in the standard, rather than reasoning
12770from typical implementation techniques.  Strict debugging modes,
12771which some programmers find useful, do not use typical implementation
12772techniques.)
12773</p>
12774<p><b>Proposed resolution:</b></p>
12775<p>
12776In 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 3, change "Invalidates all the
12777iterators and references after the point of the erase" to
12778"Invalidates iterators and references at or after the point of the
12779erase".
12780</p>
12781<p><b>Rationale:</b></p>
12782<p>I believe this was essentially a typographical error, and that it
12783  was taken for granted that erasing an element invalidates iterators
12784  that point to it.  The effects clause in question treats iterators
12785  and references in parallel, and it would seem counterintuitive to
12786  say that a reference to an erased value remains valid.</p>
12787<hr>
12788<a name="415"><h3>415.&nbsp;behavior of std::ws</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12789<p>
12790According to 27.6.1.4, the ws() manipulator is not required to construct
12791the sentry object. The manipulator is also not a member function so the
12792text in 27.6.1, p1 through 4 that describes the exception policy for
12793istream member functions does not apply. That seems inconsistent with
12794the rest of extractors and all the other input functions (i.e., ws will
12795not cause a tied stream to be flushed before extraction, it doesn't check
12796the stream's exceptions or catch exceptions thrown during input, and it
12797doesn't affect the stream's gcount).
12798</p>
12799<p><b>Proposed resolution:</b></p>
12800<p>
12801Add 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
12802of paragraph 1, the following text:
12803</p>
12804
12805    <blockquote>
12806    Behaves as an unformatted input function (as described in
12807    27.6.1.3, paragraph 1), except that it does not count the number
12808    of characters extracted and does not affect the value returned by
12809    subsequent calls to is.gcount(). After constructing a sentry
12810    object...
12811    </blockquote>
12812
12813<p><i>[Post-Kona: Martin provided wording]</i></p>
12814
12815<hr>
12816<a name="420"><h3>420.&nbsp;is std::FILE a complete type?</h3></a><p><b>Section:</b>&nbsp;27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12817<p>
128187.19.1, p2, of C99 requires that the FILE type only be declared in
12819&lt;stdio.h&gt;.  None of the (implementation-defined) members of the
12820struct is mentioned anywhere for obvious reasons.
12821</p>
12822
12823<p>
12824C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
12825it really the intent that FILE be a complete type or is an implementation
12826allowed to just declare it without providing a full definition?
12827</p>
12828<p><b>Proposed resolution:</b></p>
12829<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
12830  "defined" to "declared".</p>
12831<p><b>Rationale:</b></p>
12832<p>We don't want to impose any restrictions beyond what the C standard
12833  already says. We don't want to make anything implementation defined,
12834  because that imposes new requirements in implementations.</p>
12835<hr>
12836<a name="425"><h3>425.&nbsp;return value of std::get_temporary_buffer</h3></a><p><b>Section:</b>&nbsp;20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.help"> [lib.meta.help]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12837<p>
12838The standard is not clear about the requirements on the value returned from
12839a call to get_temporary_buffer(0). In particular, it fails to specify whether
12840the call should return a distinct pointer each time it is called (like
12841operator new), or whether the value is unspecified (as if returned by
12842malloc). The standard also fails to mention what the required behavior
12843is when the argument is less than 0.
12844</p>
12845<p><b>Proposed resolution:</b></p>
12846<p>Change 20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.help"> [lib.meta.help]</a> paragraph 2 from "...or a pair of 0
12847values if no storage can be obtained" to "...or a pair of 0 values if
12848no storage can be obtained or if <i>n</i> &lt;= 0."</p>
12849<p><i>[Kona: Matt provided wording]</i></p>
12850<hr>
12851<a name="426"><h3>426.&nbsp;search_n(), fill_n(), and generate_n() with negative n</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12852<p>
12853The complexity requirements for these function templates are incorrect
12854(or don't even make sense) for negative n:</p>
12855
12856<p>25.1.9, p7 (search_n):
12857<br>
12858Complexity: At most (last1 - first1) * count applications
12859of the corresponding predicate.</p>
12860
12861<p>25.2.5, p3 (fill_n):
12862<br>
12863Complexity: Exactly last - first (or n) assignments.</p>
12864<br>
12865
12866<p>25.2.6, p3 (generate_n):
12867<br>
12868Complexity: Exactly last - first (or n) assignments.</p>
12869
12870<p>
12871In addition, the Requirements or the Effects clauses for the latter two
12872templates don't say anything about the behavior when n is negative.
12873</p>
12874<p><b>Proposed resolution:</b></p>
12875<p>Change 25.1.9, p7 to</p>
12876
12877<blockquote>
12878Complexity: At most (last1 - first1) * count applications
12879of the corresponding predicate if count is positive,
12880or 0 otherwise.
12881</blockquote>
12882
12883<p>Change 25.2.5, p2 to</p>
12884<blockquote>
12885Effects: Assigns value through all the iterators in the range [first,
12886last), or [first, first + n) if n is positive, none otherwise.
12887</blockquote>
12888
12889<p>Change 25.2.5, p3 to:</p>
12890<blockquote>
12891Complexity: Exactly last - first (or n if n is positive,
12892or 0 otherwise) assignments.
12893</blockquote>
12894
12895<p>
12896Change 25.2.6, p1
12897to (notice the correction for the misspelled "through"):
12898</p>
12899<blockquote>
12900Effects: Invokes the function object genand assigns the return
12901value of gen through all the iterators in the range [first, last),
12902or [first, first + n) if n is positive, or [first, first)
12903otherwise.
12904</blockquote>
12905
12906<p>Change 25.2.6, p3 to:</p>
12907<blockquote>
12908Complexity: Exactly last - first (or n if n is positive,
12909or 0 otherwise) assignments.
12910</blockquote>
12911<p><b>Rationale:</b></p>
12912<p>Informally, we want to say that whenever we see a negative number
12913  we treat it the same as if it were zero.  We believe the above
12914  changes do that (although they may not be the minimal way of saying
12915  so).  The LWG considered and rejected the alternative of saying that
12916  negative numbers are undefined behavior.</p>
12917<hr>
12918<a name="428"><h3>428.&nbsp;string::erase(iterator) validity</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12919<p>
1292023.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
12921that q must be a valid dereferenceable iterator into the sequence a.
12922</p>
12923
12924<p>
12925However, 21.3.5.5, p5 describing string::erase(p) only requires that
12926p be a valid iterator.
12927</p>
12928
12929<p>
12930This may be interepreted as a relaxation of the general requirement,
12931which is most likely not the intent.
12932</p>
12933<p><b>Proposed resolution:</b></p>
12934<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>
12935<p><b>Rationale:</b></p>
12936<p>The LWG considered two options: changing the string requirements to
12937  match the general container requirements, or just removing the
12938  erroneous string requirements altogether.  The LWG chose the latter
12939  option, on the grounds that duplicating text always risks the
12940  possibility that it might be duplicated incorrectly.</p>
12941<hr>
12942<a name="432"><h3>432.&nbsp;stringbuf::overflow() makes only one write position available</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Christian W Brock&nbsp; <b>Date:</b>&nbsp;24 Sep 2003</p>
12943<p>27.7.1.3 par 8 says:</p>
12944<blockquote>
12945Notes: The function can make a write position available only if
12946    ( mode &amp; ios_base::out) != 0. To make a write position
12947    available, the function reallocates (or initially allocates) an
12948    array object with a sufficient number of elements to hold the
12949    current array object (if any), plus one additional write position.
12950    If ( mode &amp; ios_base::in) != 0, the function alters the read end
12951    pointer egptr() to point just past the new write position (as
12952    does the write end pointer epptr()).
12953</blockquote>
12954
12955<p>
12956The sentences "plus one additional write position." and especially
12957    "(as does the write end pointer epptr())" COULD by interpreted
12958    (and is interpreted by at least my library vendor) as:
12959</p>
12960
12961<blockquote>
12962    post-condition: epptr() == pptr()+1
12963</blockquote>
12964
12965<p>
12966This WOULD force sputc() to call the virtual overflow() each time.
12967</p>
12968
12969<p>The proposed change also affects Defect Report 169.</p>
12970
12971<p><b>Proposed resolution:</b></p>
12972<p>27.7.1.1/2 Change:</p>
12973
12974<blockquote>
129752- Notes: The function allocates no array object.
12976</blockquote>
12977
12978<p>
12979to:
12980</p>
12981
12982<blockquote>
129832- Postcondition: str() == "".
12984</blockquote>
12985
12986<p>
1298727.7.1.1/3 Change:
12988</p>
12989
12990<blockquote>
12991<p>
12992-3- Effects: Constructs an object of class basic_stringbuf,
12993initializing the base class with basic_streambuf()
12994(lib.streambuf.cons), and initializing mode with which . Then copies
12995the content of str into the basic_stringbuf underlying character
12996sequence and initializes the input and output sequences according to
12997which. If which &amp; ios_base::out is true, initializes the output
12998sequence with the underlying sequence. If which &amp; ios_base::in is
12999true, initializes the input sequence with the underlying sequence.
13000</p>
13001</blockquote>
13002
13003<p>to:</p>
13004
13005<blockquote>
13006<p>
13007-3- Effects: Constructs an object of class basic_stringbuf,
13008initializing the base class with basic_streambuf()
13009(lib.streambuf.cons), and initializing mode with which. Then copies
13010the content of str into the basic_stringbuf underlying character
13011sequence. If which &amp; ios_base::out is true, initializes the output
13012sequence such that pbase() points to the first underlying character,
13013epptr() points one past the last underlying character, and if (which &amp;
13014ios_base::ate) is true, pptr() is set equal to
13015epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
13016is true, initializes the input sequence such that eback() and gptr()
13017point to the first underlying character and egptr() points one past
13018the last underlying character.
13019</p>
13020</blockquote>
13021
13022<p>27.7.1.2/1 Change:</p>
13023
13024<blockquote>
13025<p>
13026-1- Returns: A basic_string object whose content is equal to the
13027basic_stringbuf underlying character sequence. If the buffer is only
13028created in input mode, the underlying character sequence is equal to
13029the input sequence; otherwise, it is equal to the output sequence. In
13030case of an empty underlying character sequence, the function returns
13031basic_string&lt;charT,traits,Allocator&gt;().
13032</p>
13033</blockquote>
13034
13035<p>to:</p>
13036
13037<blockquote>
13038<p>
13039-1- Returns: A basic_string object whose content is equal to the
13040basic_stringbuf underlying character sequence. If the basic_stringbuf
13041was created only in input mode, the resultant basic_string contains
13042the character sequence in the range [eback(), egptr()).  If the
13043basic_stringbuf was created with (which &amp; ios_base::out) being true
13044then the resultant basic_string contains the character sequence in the
13045range [pbase(), high_mark) where high_mark represents the position one
13046past the highest initialized character in the buffer.  Characters can
13047be initialized either through writing to the stream, or by
13048constructing the basic_stringbuf with a basic_string, or by calling
13049the str(basic_string) member function.  In the case of calling the
13050str(basic_string) member function, all characters initialized prior to
13051the call are now considered uninitialized (except for those
13052characters re-initialized by the new basic_string).  Otherwise the
13053basic_stringbuf has been created in neither input nor output mode and
13054a zero length basic_string is returned.
13055</p>
13056</blockquote>
13057
13058<p>
1305927.7.1.2/2 Change:
13060</p>
13061
13062<blockquote>
13063<p>
13064-2- Effects: If the basic_stringbuf's underlying character sequence is
13065not empty, deallocates it. Then copies the content of s into the
13066basic_stringbuf underlying character sequence and initializes the
13067input and output sequences according to the mode stored when creating
13068the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
13069initializes the output sequence with the underlying sequence. If
13070(mode&amp;ios_base::in) is true, then initializes the input sequence with
13071the underlying sequence.
13072</p>
13073</blockquote>
13074
13075<p>to:</p>
13076
13077<blockquote>
13078<p>
13079-2- Effects: Copies the content of s into the basic_stringbuf
13080underlying character sequence. If mode &amp; ios_base::out is true,
13081initializes the output sequence such that pbase() points to the first
13082underlying character, epptr() points one past the last underlying
13083character, and if (mode &amp; ios_base::ate) is true,
13084pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
13085mode &amp; ios_base::in is true, initializes the input sequence such that
13086eback() and gptr() point to the first underlying character and egptr()
13087points one past the last underlying character.
13088</p>
13089</blockquote>
13090
13091<p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>
13092
13093<p>27.7.1.3/1 Change:</p>
13094
13095<blockquote>
13096<p>
130971- Returns: If the input sequence has a read position available,
13098returns traits::to_int_type(*gptr()).  Otherwise, returns
13099traits::eof().
13100</p>
13101</blockquote>
13102
13103<p>to:</p>
13104
13105<blockquote>
13106<p>
131071- Returns: If the input sequence has a read position available,
13108returns traits::to_int_type(*gptr()).  Otherwise, returns
13109traits::eof().  Any character in the underlying buffer which has been
13110initialized is considered to be part of the input sequence.
13111</p>
13112</blockquote>
13113
13114<p>27.7.1.3/9 Change:</p>
13115
13116<blockquote>
13117<p>
13118-9- Notes: The function can make a write position available only if (
13119mode &amp; ios_base::out) != 0. To make a write position available, the
13120function reallocates (or initially allocates) an array object with a
13121sufficient number of elements to hold the current array object (if
13122any), plus one additional write position. If ( mode &amp; ios_base::in) !=
131230, the function alters the read end pointer egptr() to point just past
13124the new write position (as does the write end pointer epptr()).
13125</p>
13126</blockquote>
13127
13128<p>to:</p>
13129
13130<blockquote>
13131<p>
13132-9- The function can make a write position available only if ( mode &amp;
13133ios_base::out) != 0. To make a write position available, the function
13134reallocates (or initially allocates) an array object with a sufficient
13135number of elements to hold the current array object (if any), plus one
13136additional write position. If ( mode &amp; ios_base::in) != 0, the
13137function alters the read end pointer egptr() to point just past the
13138new write position.
13139</p>
13140</blockquote>
13141
13142<p>27.7.1.3/12 Change:</p>
13143
13144<blockquote>
13145<p>
13146-12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
13147positioning operation fails. Otherwise, the function assigns xbeg +
13148newoff + off to the next pointer xnext .
13149</p>
13150</blockquote>
13151
13152<p>to:</p>
13153
13154<blockquote>
13155<p>
13156-12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
13157uninitialized 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>
13158paragraph 1), the positioning operation fails. Otherwise, the function
13159assigns xbeg + newoff + off to the next pointer xnext .
13160</p>
13161</blockquote>
13162
13163<p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
13164  something along these lines was a good idea, but the original
13165  proposed resolution didn't say enough about the effect of various
13166  member functions on the underlying character sequences.]</i></p>
13167
13168<p><b>Rationale:</b></p>
13169<p>The current basic_stringbuf description is over-constrained in such
13170a way as to prohibit vendors from making this the high-performance
13171in-memory stream it was meant to be.  The fundamental problem is that
13172the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
13173observable from a derived client, and the current description
13174restricts the range [pbase(), epptr()) from being grown geometrically.
13175This change allows, but does not require, geometric growth of this
13176range.</p>
13177
13178<p>Backwards compatibility issues: These changes will break code that
13179derives from basic_stringbuf, observes epptr(), and depends upon
13180[pbase(), epptr()) growing by one character on each call to overflow()
13181(i.e. test suites).  Otherwise there are no backwards compatibility
13182issues.</p>
13183
13184<p>27.7.1.1/2: The non-normative note is non-binding, and if it were
13185binding, would be over specification.  The recommended change focuses
13186on the important observable fact.</p>
13187
13188<p>27.7.1.1/3: This change does two things: 1.  It describes exactly
13189what must happen in terms of the sequences.  The terms "input
13190sequence" and "output sequence" are not well defined.  2.  It
13191introduces a common extension: open with app or ate mode.  I concur
13192with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
13193
13194<p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
13195resultant basic_string is not dependent upon epptr(), and thus
13196implementors are free to grow the underlying buffer geometrically
13197during overflow() *and* place epptr() at the end of that buffer.</p>
13198
13199<p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>
13200
13201<p>27.7.1.3/1: Clarifies that characters written to the stream beyond
13202the initially specified string are available for reading in an i/o
13203basic_streambuf.</p>
13204
13205<p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
13206trailing parenthetical comment concerning epptr().</p>
13207
13208<p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
13209longer allowable since [pbase(), epptr()) may now contain
13210uninitialized characters.  Positioning is only allowable over the
13211initialized range.</p>
13212<hr>
13213<a name="434"><h3>434.&nbsp;bitset::to_string() hard to use</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
13214<p>
13215It has been pointed out a number of times that the bitset to_string() member
13216function template is tedious to use since callers must explicitly specify the
13217entire template argument list (3 arguments). At least two implementations
13218provide a number of overloads of this template to make it easier to use.
13219</p>
13220<p><b>Proposed resolution:</b></p>
13221<p>In order to allow callers to specify no template arguments at all, just the
13222first one (charT), or the first 2 (charT and traits), in addition to all
13223three template arguments, add the following three overloads to both the
13224interface (declarations only) of the class template bitset as well as to
13225section 23.3.5.2, immediately after p34, the Returns clause of the existing
13226to_string() member function template:</p>
13227
13228<pre>    template &lt;class charT, class traits&gt;
13229    basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
13230    to_string () const;
13231
13232    -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
13233
13234    template &lt;class charT&gt;
13235    basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
13236    to_string () const;
13237
13238    -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
13239
13240    basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
13241    to_string () const;
13242
13243    -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
13244</pre>
13245
13246<p><i>[Kona: the LWG agrees that this is an improvement over the
13247  status quo.  Dietmar thought about an alternative using a proxy
13248  object but now believes that the proposed resolution above is the
13249  right choice.
13250]</i></p>
13251
13252<hr>
13253<a name="435"><h3>435.&nbsp;bug in DR 25</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
13254
13255<p>
13256It has been pointed out that the proposed resolution in DR 25 may not be
13257quite up to snuff: <br>
13258http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
13259http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
13260</p>
13261
13262<p>
13263It looks like Petur is right. The complete corrected text is copied below.
13264I think we may have have been confused by the reference to 22.2.2.2.2 and
13265the subsequent description of `n' which actually talks about the second
13266argument to sputn(), not about the number of fill characters to pad with.
13267</p>
13268
13269<p>
13270So the question is: was the original text correct? If the intent was to
13271follow classic iostreams then it most likely wasn't, since setting width()
13272to less than the length of the string doesn't truncate it on output. This
13273is also the behavior of most implementations (except for SGI's standard
13274iostreams where the operator does truncate).
13275</p>
13276<p><b>Proposed resolution:</b></p>
13277<p>Change the text in 21.3.7.9, p4 from</p>
13278    <blockquote>
13279    If bool(k) is true, inserts characters as if by calling
13280    os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
13281    of lib.facet.num.put.virtuals, where n is the larger of os.width()
13282    and str.size();
13283    </blockquote>
13284<p>to</p>
13285    <blockquote>
13286    If bool(k) is true, determines padding as described in
13287    lib.facet.num.put.virtuals, and then inserts the resulting
13288    sequence of characters <tt>seq</tt> as if by calling
13289    <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
13290    <tt>os.width()</tt> and <tt>str.size()</tt>;
13291     </blockquote>
13292
13293<p><i>[Kona: it appears that neither the original wording, DR25, nor the
13294  proposed resolution, is quite what we want.  We want to say that
13295  the string will be output, padded to os.width() if necessary.  We
13296  don't want to duplicate the padding rules in clause 22, because
13297  they're complicated, but we need to be careful because they weren't
13298  quite written with quite this case in mind.  We need to say what
13299  the character sequence is, and then defer to clause 22.  Post-Kona:
13300  Benjamin provided wording.]</i></p>
13301
13302<hr>
13303<a name="436"><h3>436.&nbsp;are cv-qualified facet types valid facets?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
13304<p>
13305Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
13306and the locale template ctor? And if so, does it designate the same Facet as
13307the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
13308Different implementations behave differently: some fail to compile, others
13309accept such types but behave inconsistently.
13310</p>
13311<p><b>Proposed resolution:</b></p>
13312<p>Change 22.1.1.1.2, p1 to read:</p>
13313
13314<p>Template parameters in this clause which are required to be facets
13315are those named Facet in declarations. A program that passes a type
13316that is not a facet, or a type that refers to volatile-qualified
13317facet, as an (explicit or deduced) template parameter to a locale
13318function expecting a facet, is ill-formed.  A const-qualified facet is
13319a valid template argument to any locale function that expects a Facet
13320template parameter.</p>
13321
13322<p><i>[Kona: changed the last sentence from a footnote to normative
13323text.]</i></p>
13324
13325<hr>
13326<a name="438"><h3>438.&nbsp;Ambiguity in the "do the right thing" clause</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Oct 2003</p>
13327
13328<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
13329noticed with statements like:</p>
13330<pre>vector&lt;int&gt; v(10, 1);
13331</pre>
13332
13333<p>The intent of the above statement was to construct with:</p>
13334<pre>vector(size_type, const value_type&amp;);
13335</pre>
13336
13337<p>but early implementations failed to compile as they bound to:</p>
13338<pre>template &lt;class InputIterator&gt;
13339vector(InputIterator f, InputIterator l);
13340</pre>
13341<p>instead.</p>
13342
13343<p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
13344member template constructor will have the same effect as:</p>
13345<pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
13346</pre>
13347<p>(and similarly for the other member template functions of sequences).</p>
13348
13349<p>There is also a note that describes one implementation technique:</p>
13350<blockquote>
13351   One way that sequence implementors can satisfy this requirement is to
13352   specialize the member template for every integral type.
13353</blockquote>
13354
13355<p>This might look something like:</p>
13356<blockquote>
13357<pre>template &lt;class T&gt;
13358struct vector
13359{
13360     typedef unsigned size_type;
13361
13362     explicit vector(size_type) {}
13363     vector(size_type, const T&amp;) {}
13364
13365     template &lt;class I&gt;
13366     vector(I, I);
13367
13368     // ...
13369};
13370
13371template &lt;class T&gt;
13372template &lt;class I&gt;
13373vector&lt;T&gt;::vector(I, I) { ... }
13374
13375template &lt;&gt;
13376template &lt;&gt;
13377vector&lt;int&gt;::vector(int, int) { ... }
13378
13379template &lt;&gt;
13380template &lt;&gt;
13381vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
13382
13383//  ...
13384</pre>
13385</blockquote>
13386
13387<p>Label this solution 'A'.</p>
13388
13389<p>The standard also says:</p>
13390<blockquote>
13391 Less cumbersome implementation techniques also exist.
13392</blockquote>
13393<p>
13394A popular technique is to not specialize as above, but instead catch
13395every call with the member template, detect the type of InputIterator,
13396and then redirect to the correct logic.  Something like:
13397</p>
13398<blockquote>
13399<pre>template &lt;class T&gt;
13400template &lt;class I&gt;
13401vector&lt;T&gt;::vector(I f, I l)
13402{
13403     choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
13404}
13405
13406template &lt;class T&gt;
13407template &lt;class I&gt;
13408vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
13409{
13410    // construct with iterators
13411}
13412
13413template &lt;class T&gt;
13414template &lt;class I&gt;
13415vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
13416{
13417    size_type sz = static_cast&lt;size_type&gt;(f);
13418    value_type v = static_cast&lt;value_type&gt;(l);
13419    // construct with sz,v
13420}
13421</pre>
13422</blockquote>
13423
13424<p>Label this solution 'B'.</p>
13425
13426<p>Both of these solutions solve the case the standard specifically
13427mentions:</p>
13428<pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
13429</pre>
13430
13431<p>
13432However, (and here is the problem), the two solutions have different
13433behavior in some cases where the value_type of the sequence is not an
13434integral type.  For example consider:
13435</p>
13436<blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
13437     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
13438</pre></blockquote>
13439<p>
13440The second line of this snippet is likely an error.  Solution A catches
13441the error and refuses to compile.  The reason is that there is no
13442specialization of the member template constructor that looks like:
13443</p>
13444<pre>template &lt;&gt;
13445template &lt;&gt;
13446vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
13447</pre>
13448
13449<p>
13450So the expression binds to the unspecialized member template
13451constructor, and then fails (compile time) because char is not an
13452InputIterator.
13453</p>
13454
13455<p>
13456Solution B compiles the above example though.  'a' is casted to an
13457unsigned integral type and used to size the outer vector.  'b' is
13458static casted to the inner vector using it's explicit constructor:
13459</p>
13460
13461<pre>explicit vector(size_type n);
13462</pre>
13463
13464<p>
13465and so you end up with a static_cast&lt;size_type&gt;('a') by
13466static_cast&lt;size_type&gt;('b') matrix.
13467</p>
13468
13469<p>
13470It is certainly possible that this is what the coder intended.  But the
13471explicit qualifier on the inner vector has been thwarted at any rate.
13472</p>
13473
13474<p>
13475The standard is not clear whether the expression:
13476</p>
13477
13478<pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
13479</pre>
13480
13481<p>
13482(and similar expressions) are:
13483</p>
13484
13485<ol>
13486<li>  undefined behavior.</li>
13487<li>  illegal and must be rejected.</li>
13488<li>  legal and must be accepted.</li>
13489</ol>
13490
13491<p>My preference is listed in the order presented.</p>
13492
13493<p>There are still other techniques for implementing the requirements of
13494paragraphs 9-11, namely the "restricted template technique" (e.g.
13495enable_if).  This technique is the most compact and easy way of coding
13496the requirements, and has the behavior of #2 (rejects the above
13497expression).
13498</p>
13499
13500<p>
13501Choosing 1 would allow all implementation techniques I'm aware of.
13502Choosing 2 would allow only solution 'A' and the enable_if technique.
13503Choosing 3 would allow only solution 'B'.
13504</p>
13505
13506<p>
13507Possible wording for a future standard if we wanted to actively reject
13508the expression above would be to change "static_cast" in paragraphs
135099-11 to "implicit_cast" where that is defined by:
13510</p>
13511
13512<blockquote>
13513<pre>template &lt;class T, class U&gt;
13514inline
13515T implicit_cast(const U&amp; u)
13516{
13517     return u;
13518}
13519</pre>
13520</blockquote>
13521
13522<p><b>Proposed resolution:</b></p>
13523
13524Replace 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:
13525
13526<p>For every sequence defined in this clause and in clause lib.strings:</p>
13527
13528<ul>
13529  <li>
13530    <p>If the constructor</p>
13531       <pre>       template &lt;class InputIterator&gt;
13532       X(InputIterator f, InputIterator l,
13533         const allocator_type&amp; a = allocator_type())
13534       </pre>
13535    <p>is called with a type InputIterator that does not qualify as
13536    an input iterator, then the constructor will behave as if the
13537    overloaded constructor:</p>
13538       <pre>       X(size_type, const value_type&amp; = value_type(),
13539         const allocator_type&amp; = allocator_type())
13540       </pre>
13541    <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
13542  </li>
13543
13544  <li>
13545    <p>If the member functions of the forms:</p>
13546       <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
13547       rt fx1(iterator p, InputIterator f, InputIterator l);
13548
13549       template &lt;class InputIterator&gt;          //  such as  append(), assign()
13550       rt fx2(InputIterator f, InputIterator l);
13551
13552       template &lt;class InputIterator&gt;          //  such as  replace()
13553       rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
13554       </pre>
13555    <p>are called with a type InputIterator that does not qualify as
13556    an input iterator, then these functions will behave as if the
13557    overloaded member functions:</p>
13558       <pre>       rt fx1(iterator, size_type, const value_type&amp;);
13559
13560       rt fx2(size_type, const value_type&amp;);
13561
13562       rt fx3(iterator, iterator, size_type, const value_type&amp;);
13563       </pre>
13564    <p>were called instead, with the same arguments.</p>
13565  </li>
13566</ul>
13567
13568<p>In the previous paragraph the alternative binding will fail if f
13569is not implicitly convertible to X::size_type or if l is not implicitly
13570convertible to X::value_type.</p>
13571
13572<p>
13573The extent to which an implementation determines that a type cannot be
13574an input iterator is unspecified, except that as a minimum integral
13575types shall not qualify as input iterators.
13576</p>
13577
13578
13579
13580<p><i>[
13581Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
13582to be accepted, and also agreed that this is surprising behavior.  The
13583LWG considered several options, including something like
13584implicit_cast, which doesn't appear to be quite what we want.  We
13585considered Howards three options: allow acceptance or rejection,
13586require rejection as a compile time error, and require acceptance.  By
13587straw poll (1-6-1), we chose to require a compile time error.
13588Post-Kona: Howard provided wording.
13589]</i></p>
13590
13591<p><i>[
13592Sydney: The LWG agreed with this general direction, but there was some
13593discomfort with the wording in the original proposed resolution.
13594Howard submitted new wording, and we will review this again in
13595Redmond.
13596]</i></p>
13597
13598<p><i>[Redmond: one very small change in wording: the first argument
13599  is cast to size_t.  This fixes the problem of something like
13600  <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not
13601  implicitly convertible to the value type.]</i></p>
13602
13603<p><b>Rationale:</b></p>
13604<p>The proposed resolution fixes:</p>
13605
13606<pre>  vector&lt;int&gt; v(10, 1);
13607</pre>
13608
13609<p>
13610since as integral types 10 and 1 must be disqualified as input
13611iterators and therefore the (size,value) constructor is called (as
13612if).</p>
13613
13614<p>The proposed resolution breaks:</p>
13615
13616<pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
13617</pre>
13618
13619<p>
13620because the integral type 1 is not *implicitly* convertible to
13621vector&lt;T&gt;.  The wording above requires a diagnostic.</p>
13622
13623<p>
13624The proposed resolution leaves the behavior of the following code
13625unspecified.
13626</p>
13627
13628<pre>  struct A
13629  {
13630    operator int () const {return 10;}
13631  };
13632
13633  struct B
13634  {
13635    B(A) {}
13636  };
13637
13638  vector&lt;B&gt; v(A(), A());
13639</pre>
13640
13641<p>
13642The implementation may or may not detect that A is not an input
13643iterator and employee the (size,value) constructor.  Note though that
13644in the above example if the B(A) constructor is qualified explicit,
13645then the implementation must reject the constructor as A is no longer
13646implicitly convertible to B.
13647</p>
13648<hr>
13649<a name="441"><h3>441.&nbsp;Is fpos::state const?</h3></a><p><b>Section:</b>&nbsp;27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;17 Nov 2003</p>
13650<p>
13651In 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&lt;stateT&gt;::state() is declared
13652non 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.
13653</p>
13654<p><b>Proposed resolution:</b></p>
13655<p>
13656In 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
13657<tt>fpos&lt;stateT&gt;::state()</tt> to const.
13658</p>
13659<hr>
13660<a name="442"><h3>442.&nbsp;sentry::operator bool() inconsistent signature</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;18 Nov 2003</p>
13661<p>
13662In 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
13663basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
13664as non const, but in section 27.6.2.3, in synopsis it is declared
13665const.
13666</p>
13667<p><b>Proposed resolution:</b></p>
13668<p>
13669In 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
13670of <tt>sentry::operator bool()</tt> to const.
13671</p>
13672<hr>
13673<a name="443"><h3>443.&nbsp;filebuf::close() inconsistent use of EOF</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
13674<p>
13675In 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
13676basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
13677should be overflow(traits::eof()).
13678</p>
13679<p><b>Proposed resolution:</b></p>
13680<p>
13681Change overflow(EOF) to overflow(traits::eof()).
13682</p>
13683<hr>
13684<a name="444"><h3>444.&nbsp;Bad use of casts in fstream</h3></a><p><b>Section:</b>&nbsp;27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
13685<p>
1368627.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
13687<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
13688</p>
13689<p><b>Proposed resolution:</b></p>
13690
13691<p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
13692 constness. The other two places are stylistic: we could change the
13693 C-style casts to const_cast. Post-Sydney: Howard provided wording.
13694]</i></p>
13695
13696<p>Change 27.8.1.7/1 from:</p>
13697<blockquote>
13698  Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
13699</blockquote>
13700
13701<p>to:</p>
13702<blockquote>
13703  Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13704</blockquote>
13705
13706<p>Change 27.8.1.10/1 from:</p>
13707<blockquote>
13708  Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
13709</blockquote>
13710
13711<p>to:</p>
13712<blockquote>
13713  Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13714</blockquote>
13715
13716<p>Change 27.8.1.13/1 from:</p>
13717<blockquote>
13718  Returns: &amp;sb.
13719</blockquote>
13720
13721<p>to:</p>
13722<blockquote>
13723  Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13724</blockquote>
13725
13726
13727
13728<hr>
13729<a name="445"><h3>445.&nbsp;iterator_traits::reference unspecified for some iterator categories</h3></a><p><b>Section:</b>&nbsp;24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;9 Dec 2003</p>
13730<p>
13731The standard places no restrictions at all on the reference type
13732of input, output, or forward iterators (for forward iterators it
13733only specifies that *x must be value_type&amp; and doesn't mention
13734the reference type).  Bidirectional iterators' reference type is
13735restricted only by implication, since the base iterator's
13736reference type is used as the return type of reverse_iterator's
13737operator*, which must be T&amp; in order to be a conforming forward
13738iterator.
13739</p>
13740
13741<p>
13742Here's what I think we ought to be able to expect from an input
13743or forward iterator's reference type R, where a is an iterator
13744and V is its value_type
13745</p>
13746
13747<ul>
13748  <li>
13749      *a is convertible to R
13750  </li>
13751
13752  <li>
13753      R is convertible to V
13754  </li>
13755
13756  <li>
13757      static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
13758      static_cast&lt;V&gt;(*a)
13759  </li>
13760</ul>
13761
13762<p>A mutable forward iterator ought to satisfy, for x of type V:</p>
13763  <li>
13764      { R r = *a; r = x; } is equivalent to *a = x;
13765  </li>
13766
13767<p>
13768I think these requirements capture existing container iterators
13769(including vector&lt;bool&gt;'s), but render istream_iterator invalid;
13770its reference type would have to be changed to a constant
13771reference.
13772</p>
13773
13774
13775<p>
13776(Jeremy Siek) During the discussion in Sydney, it was felt that a
13777simpler long term solution for this was needed. The solution proposed
13778was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
13779and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
13780iterators in the Standard Library already meet this requirement. Some
13781iterators are output iterators, and do not need to meet the
13782requirement, and others are only specified through the general
13783iterator requirements (which will change with this resolution). The
13784sole case where there is an explicit definition of the reference type
13785that will need to change is <tt>istreambuf_iterator</tt> which returns
13786<tt>charT</tt> from <tt>operator*</tt> but has a reference type of
13787<tt>charT&amp;</tt>. We propose changing the reference type of
13788<tt>istreambuf_iterator</tt> to <tt>charT</tt>.
13789</p>
13790
13791<p>The other option for resolving the issue with <tt>pointer</tt>,
13792  mentioned in the note below, is to remove <tt>pointer</tt>
13793  altogether. I prefer placing requirements on <tt>pointer</tt> to
13794  removing it for two reasons. First, <tt>pointer</tt> will become
13795  useful for implementing iterator adaptors and in particular,
13796  <tt>reverse_iterator</tt> will become more well defined. Second,
13797  removing <tt>pointer</tt> is a rather drastic and publicly-visible
13798  action to take.</p>
13799
13800<p>The proposed resolution technically enlarges the requirements for
13801iterators, which means there are existing iterators (such as
13802<tt>istreambuf_iterator</tt>, and potentially some programmer-defined
13803iterators) that will no longer meet the requirements. Will this break
13804existing code? The scenario in which it would is if an algorithm
13805implementation (say in the Standard Library) is changed to rely on
13806<tt>iterator_traits::reference</tt>, and then is used with one of the
13807iterators that do not have an appropriately defined
13808<tt>iterator_traits::reference</tt>.
13809</p>
13810
13811
13812<p>The proposed resolution makes one other subtle change. Previously,
13813it was required that output iterators have a <tt>difference_type</tt>
13814and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
13815iterator could not be an output iterator. This is clearly a mistake,
13816so I've changed the wording to say that those types may be
13817<tt>void</tt>.
13818</p>
13819
13820<p><b>Proposed resolution:</b></p>
13821
13822<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>
13823
13824<blockquote>
13825be defined as the iterator's difference type, value type and iterator
13826category, respectively.
13827</blockquote>
13828
13829<p>add</p>
13830
13831<blockquote>
13832In addition, the types
13833<pre>iterator_traits&lt;Iterator&gt;::reference
13834iterator_traits&lt;Iterator&gt;::pointer
13835</pre>
13836must be defined as the iterator's reference and pointer types, that
13837is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
13838respectively.
13839</blockquote>
13840
13841<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>
13842
13843<blockquote>
13844In the case of an output iterator, the types
13845<pre>iterator_traits&lt;Iterator&gt;::difference_type
13846iterator_traits&lt;Iterator&gt;::value_type
13847</pre>
13848are both defined as <tt>void</tt>.
13849</blockquote>
13850
13851<p>to:</p>
13852<blockquote>
13853In the case of an output iterator, the types
13854<pre>iterator_traits&lt;Iterator&gt;::difference_type
13855iterator_traits&lt;Iterator&gt;::value_type
13856iterator_traits&lt;Iterator&gt;::reference
13857iterator_traits&lt;Iterator&gt;::pointer
13858</pre>
13859may be defined as <tt>void</tt>.
13860</blockquote>
13861
13862<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>
13863<blockquote>
13864<pre>typename traits::off_type, charT*, charT&amp;&gt;
13865</pre>
13866</blockquote>
13867<p>to:</p>
13868<blockquote>
13869<pre>typename traits::off_type, charT*, charT&gt;
13870</pre>
13871</blockquote>
13872
13873<p><i>[
13874Redmond: there was concern in Sydney that this might not be the only place
13875where things were underspecified and needed to be changed.  Jeremy
13876reviewed iterators in the standard and confirmed that nothing else
13877needed to be changed.
13878]</i></p>
13879
13880<hr>
13881<a name="448"><h3>448.&nbsp;Random Access Iterators over abstract classes</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 Jan 2004</p>
13882<p>
13883Table 76, the random access iterator requirement table, says that the
13884return type of a[n] must be "convertible to T".  When an iterator's
13885value_type T is an abstract class, nothing is convertible to T.
13886Surely this isn't an intended restriction?
13887</p>
13888<p><b>Proposed resolution:</b></p>
13889<p>
13890Change the return type to "convertible to T const&amp;".
13891</p>
13892<hr>
13893<a name="449"><h3>449.&nbsp;Library Issue 306 Goes Too Far</h3></a><p><b>Section:</b>&nbsp;18.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;15 Jan 2004</p>
13894<p>Original text:</p>
13895<blockquote>
13896The macro offsetof accepts a restricted set of type arguments in this
13897International Standard. type shall be a POD structure or a POD union
13898(clause 9). The result of applying the offsetof macro to a field that
13899is a static data member or a function member is undefined."
13900</blockquote>
13901
13902<p>Revised text:</p>
13903<blockquote>
13904"If type is not a POD structure or a POD union the results are undefined."
13905</blockquote>
13906
13907<p>
13908Looks to me like the revised text should have replaced only the second
13909sentence. It doesn't make sense standing alone.
13910</p>
13911
13912<p><b>Proposed resolution:</b></p>
13913<p>Change 18.1, paragraph 5, to:</p>
13914
13915<blockquote>
13916The macro offsetof accepts a restricted set of type arguments in this
13917International Standard.  If type is not a POD structure or a POD union
13918the results are undefined.  The result of applying the offsetof macro
13919to a field that is a static data member or a function member is
13920undefined."
13921</blockquote>
13922<hr>
13923<a name="453"><h3>453.&nbsp;basic_stringbuf::seekoff need not always fail for an empty stream</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
13924<pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
13925                                    ios_base::openmode);
13926</pre>
13927<p>
13928is obliged to fail if nothing has been inserted into the stream. This
13929is unnecessary and undesirable. It should be permissible to seek to
13930an effective offset of zero.</p>
13931
13932<p><i>[
13933 Sydney: Agreed that this is an annoying problem: seeking to zero should be
13934 legal. Bill will provide wording.
13935]</i></p>
13936
13937<p><b>Proposed resolution:</b></p>
13938<p>Change the sentence from:</p>
13939<blockquote>
13940For a sequence to be positioned, if its next pointer (either
13941gptr() or pptr()) is a null pointer, the positioning operation
13942fails.
13943</blockquote>
13944
13945<p>to:</p>
13946
13947<blockquote>
13948For a sequence to be positioned, if its next pointer (either
13949gptr() or pptr()) is a null pointer and the new offset newoff
13950is nonzero, the positioning operation fails.
13951</blockquote>
13952<hr>
13953<a name="455"><h3>455.&nbsp;cerr::tie() and wcerr::tie() are overspecified</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
13954<p>
13955Both cerr::tie() and wcerr::tie() are obliged to be null at program
13956startup. This is overspecification and overkill. It is both traditional
13957and useful to tie cerr to cout, to ensure that standard output is drained
13958whenever an error message is written. This behavior should at least be
13959permitted if not required. Same for wcerr::tie().
13960</p>
13961<p><b>Proposed resolution:</b></p>
13962
13963<p>Add to the description of cerr:</p>
13964<blockquote>
13965After the object cerr is initialized, cerr.tie() returns &amp;cout.
13966Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
13967(lib.basic.ios.cons).
13968</blockquote>
13969
13970<p>Add to the description of wcerr:</p>
13971
13972<blockquote>
13973After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
13974Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
13975(lib.basic.ios.cons).
13976</blockquote>
13977
13978<p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
13979  permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
13980  provide wording.]</i></p>
13981<hr>
13982<a name="457"><h3>457.&nbsp;bitset constructor: incorrect number of initialized bits</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dag Henriksson&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
13983<p>
13984The constructor from unsigned long says it initializes "the first M
13985bit positions to the corresponding bit values in val. M is the smaller
13986of N and the value CHAR_BIT * sizeof(unsigned long)."
13987</p>
13988
13989<p>
13990Object-representation vs. value-representation strikes again. CHAR_BIT *
13991sizeof (unsigned long) does not give us the number of bits an unsigned long
13992uses to hold the value. Thus, the first M bit position above is not
13993guaranteed to have any corresponding bit values in val.
13994</p>
13995<p><b>Proposed resolution:</b></p>
13996<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
13997  N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
13998  "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
13999  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
14000  long</tt>."
14001</p>
14002<hr>
14003<a name="460"><h3>460.&nbsp;Default modes missing from basic_fstream member specifications</h3></a><p><b>Section:</b>&nbsp;27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Ben Hutchings&nbsp; <b>Date:</b>&nbsp;1 Apr 2004</p>
14004<p>
14005The second parameters of the non-default constructor and of the open
14006member function for basic_fstream, named "mode", are optional
14007according to the class declaration in 27.8.1.11 [lib.fstream].  The
14008specifications of these members in 27.8.1.12 [lib.fstream.cons] and
1400927.8.1.13 lib.fstream.members] disagree with this, though the
14010constructor declaration has the "explicit" function-specifier implying
14011that it is intended to be callable with one argument.
14012</p>
14013<p><b>Proposed resolution:</b></p>
14014<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>
14015<pre>  explicit basic_fstream(const char* s, ios_base::openmode mode);
14016</pre>
14017<p>to</p>
14018<pre>  explicit basic_fstream(const char* s,
14019                         ios_base::openmode mode = ios_base::in|ios_base::out);
14020</pre>
14021<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>
14022<pre>  void open(const char*s, ios_base::openmode mode);
14023</pre>
14024<p>to</p>
14025  void open(const char*s,
14026            ios_base::openmode mode = ios_base::in|ios_base::out);
14027<hr>
14028<a name="461"><h3>461.&nbsp;time_get hard or impossible to implement</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
14029<p>
14030Template time_get currently contains difficult, if not impossible,
14031requirements for do_date_order, do_get_time, and do_get_date. All require
14032the implementation to scan a field generated by the %x or %X conversion
14033specifier in strftime. Yes, do_date_order can always return no_order, but
14034that doesn't help the other functions. The problem is that %x can be
14035nearly anything, and it can vary widely with locales. It's horribly
14036onerous to have to parse "third sunday after Michaelmas in the year of
14037our Lord two thousand and three," but that's what we currently ask of
14038do_get_date. More practically, it leads some people to think that if
14039%x produces 10.2.04, we should know to look for dots as separators. Still
14040not easy.
14041</p>
14042
14043<p>
14044Note that this is the <i>opposite</i> effect from the intent stated in the
14045footnote earlier in this subclause:
14046</p>
14047
14048<blockquote>
14049"In other words, user confirmation is required for reliable parsing of
14050user-entered dates and times, but machine-generated formats can be
14051parsed reliably. This allows parsers to be aggressive about interpreting
14052user variations on standard formats."
14053</blockquote>
14054
14055<p>
14056We should give both implementers and users an easier and more reliable
14057alternative: provide a (short) list of alternative delimiters and say
14058what the default date order is for no_order. For backward compatibility,
14059and maximum latitude, we can permit an implementation to parse whatever
14060%x or %X generates, but we shouldn't require it.
14061</p>
14062<p><b>Proposed resolution:</b></p>
14063
14064<p><b>In the description:</b></p>
14065<pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
14066        ios_base::iostate&amp; err, tm* t) const;
14067</pre>
14068
14069<p>
140702 Effects: Reads characters starting at suntil it has extracted those
14071struct tm members, and remaining format characters, used by
14072time_put&lt;&gt;::put to produce the format specified by 'X', or until it
14073encounters an error or end of sequence.
14074</p>
14075
14076<p><b>change:</b> 'X'</p>
14077
14078<p><b>to:</b> "%H:%M:%S"</p>
14079
14080
14081<p>Change</p>
14082<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
14083        ios_base::iostate&amp; err, tm* t) const;
14084
140854 Effects: Reads characters starting at s until it has extracted those
14086struct tm members, and remaining format characters, used by
14087time_put&lt;&gt;::put to produce the format specified by 'x', or until it
14088encounters an error.
14089</pre>
14090
14091<p>to</p>
14092iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
14093        ios_base::iostate&amp; err, tm* t) const;
14094
140954 Effects: Reads characters starting at s until it has extracted those
14096struct tm members, and remaining format characters, used by
14097time_put&lt;&gt;::put to produce one of the following formats, or until it
14098encounters an error. The format depends on the value returned by
14099date_order() as follows:
14100
14101        date_order()  format
14102
14103        no_order      "%m/%d/%y"
14104        dmy           "%d/%m/%y"
14105        mdy           "%m/%d/%y"
14106        ymd           "%y/%m/%d"
14107        ydm           "%y/%d/%m"
14108
14109An implementation may also accept additional implementation-defined formats.
14110<pre></pre>
14111
14112<p><i>[Redmond: agreed that this is a real problem.  The solution is
14113  probably to match C99's parsing rules.  Bill provided wording.
14114]</i></p>
14115
14116<hr>
14117<a name="464"><h3>464.&nbsp;Suggestion for new member functions in standard containers</h3></a><p><b>Section:</b>&nbsp;23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>, 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Thorsten Ottosen&nbsp; <b>Date:</b>&nbsp;12 May 2004</p>
14118
14119<p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
14120<ol>
14121<li> add vector&lt;T&gt;::data() member (const and non-const version)
14122semantics: if( empty() ) return 0; else return buffer_;</li>
14123<li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
14124<i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
14125</ol>
14126
14127<p>Rationale:</p>
14128
14129<ul>
14130<li>To obtain a pointer to the vector's buffer, one must use either
14131operator[]() (which can give undefined behavior for empty vectors) or
14132at() (which will then throw if the vector is empty). </li>
14133<li>tr1::array&lt;T,sz&gt; already has a data() member</li>
14134<li>e cannot use operator[]() when T is not DefaultDonstructible</li>
14135<li>Neither when the map is const.</li>
14136<li>when we want to make sure we don't add an element accidently</li>
14137<li>when it should be considered an error if a key is not in the map</li>
14138</ul>
14139
14140<p><b>Proposed resolution:</b></p>
14141<p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>, add the following to the <tt>vector</tt>
14142  synopsis after "element access" and before "modifiers":</p>
14143<pre>  // <i>[lib.vector.data] data access</i>
14144  pointer       data();
14145  const_pointer data() const;
14146</pre>
14147
14148<p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>:</p>
14149<blockquote>
14150<p>23.2.4.x <tt>vector</tt> data access</p>
14151<pre>   pointer       data();
14152   const_pointer data() const;
14153</pre>
14154<p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
14155   range.  For a non-empty vector, data() == &amp;front().</p>
14156<p><b>Complexity:</b> Constant time.</p>
14157<p><b>Throws:</b> Nothing.</p>
14158</blockquote>
14159
14160<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>
14161synopsis immediately after the line for operator[]:</p>
14162<pre>  T&amp;       at(const key_type&amp; x);
14163  const T&amp; at(const key_type&amp; x) const;
14164</pre>
14165
14166<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>
14167<blockquote>
14168<pre>  T&amp;       at(const key_type&amp; x);
14169  const T&amp; at(const key_type&amp; x) const;
14170</pre>
14171
14172<p><b>Returns:</b> A reference to the element whose key is equivalent
14173  to x, if such an element is present in the map.</p>
14174<p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
14175
14176</blockquote>
14177
14178<p><b>Rationale:</b></p>
14179<p>Neither of these additions provides any new functionality but the
14180  LWG agreed that they are convenient, especially for novices.  The
14181  exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
14182  was chosen to match <tt>vector::at</tt>.</p>
14183<hr>
14184<a name="465"><h3>465.&nbsp;Contents of &lt;ciso646&gt;</h3></a><p><b>Section:</b>&nbsp;17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;3 Jun 2004</p>
14185<p>C header &lt;iso646.h&gt; defines macros for some operators, such as
14186not_eq for !=.</p>
14187
14188<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
14189clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
14190as the C header &lt;name.h&gt;. In particular, table 12 lists
14191&lt;ciso646&gt; as a C++ header.</p>
14192
14193<p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
14194&lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
14195contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
14196
14197<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
14198"Header &lt;iso646.h&gt;" says that the alternative tokens are not
14199defined as macros in &lt;ciso646&gt;, but does not mention the contents
14200of &lt;iso646.h&gt;.</p>
14201
14202<p>I don't find any normative text to support C.2.2.2.</p>
14203
14204<p><b>Proposed resolution:</b></p>
14205<p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
14206  paragraph 6 (the one about functions must be functions):</p>
14207
14208<blockquote>
14209<p>Identifiers that are keywords or operators in C++ shall not be defined
14210as macros in C++ standard library headers.
14211[Footnote:In particular, including the standard header &lt;iso646.h&gt;
14212or &lt;ciso646&gt; has no effect. </p>
14213</blockquote>
14214
14215<p><i>[post-Redmond: Steve provided wording.]</i></p>
14216
14217<hr>
14218<a name="467"><h3>467.&nbsp;char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
14219
14220<p>
14221Table 37 describes the requirements on Traits::compare() in terms of
14222those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
14223to yield the same result as operator&lt;(char, char).
14224</p>
14225
14226<p>
14227Most, if not all, implementations of char_traits&lt;char&gt;::compare()
14228call memcmp() for efficiency. However, the C standard requires both
14229memcmp() and strcmp() to interpret characters under comparison as
14230unsigned, regardless of the signedness of char. As a result, all
14231these char_traits implementations fail to meet the requirement
14232imposed by Table 37 on compare() when char is signed.
14233</p>
14234
14235
14236<p>Read email thread starting with c++std-lib-13499 for more. </p>
14237<p><b>Proposed resolution:</b></p>
14238
14239
14240<p>Change 21.1.3.1, p6 from</p>
14241<blockquote>
14242    The two-argument members assign, eq, and lt are defined identically
14243    to the built-in operators =, ==, and &lt; respectively.
14244</blockquote>
14245<p>to</p>
14246<blockquote>
14247  The two-argument member assign is defined identically to
14248  the built-in operator =. The two
14249  argument members eq and lt are defined identically to
14250  the built-in operators == and &lt; for type unsigned char.
14251</blockquote>
14252
14253<p><i>[Redmond: The LWG agreed with this general direction, but we
14254  also need to change <tt>eq</tt> to be consistent with this change.
14255  Post-Redmond: Martin provided wording.]</i></p>
14256
14257<hr>
14258<a name="468"><h3>468.&nbsp;unexpected consequences of ios_base::operator void*()</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
14259
14260<p>The program below is required to compile but when run it typically
14261produces unexpected results due to the user-defined conversion from
14262std::cout or any object derived from basic_ios to void*.
14263</p>
14264
14265<pre>    #include &lt;cassert&gt;
14266    #include &lt;iostream&gt;
14267
14268    int main ()
14269    {
14270        assert (std::cin.tie () == std::cout);
14271        // calls std::cout.ios::operator void*()
14272    }
14273</pre>
14274
14275<p><b>Proposed resolution:</b></p>
14276
14277<p>
14278Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
14279conversion operator to some unspecified type that is guaranteed not
14280to be convertible to any other type except for bool (a pointer-to-member
14281might be one such suitable type). In addition, make it clear that the
14282pointer type need not be a pointer to a complete type and when non-null,
14283the value need not be valid.
14284</p>
14285
14286<p>Specifically, change in [lib.ios] the signature of</p>
14287<pre>    operator void*() const;
14288</pre>
14289<p>to</p>
14290<pre>    operator unspecified-bool-type() const;
14291</pre>
14292<p>and change [lib.iostate.flags], p1 from</p>
14293<pre>    operator void*() const;
14294</pre>
14295<p>to</p>
14296<pre>operator unspecified-bool-type() const;
14297
14298     -1- Returns: if fail() then a value that will evaluate false in a
14299      boolean context; otherwise a value that will evaluate true in a
14300      boolean context. The value type returned shall not be
14301      convertible to int.
14302
14303     -2- [Note: This conversion can be used in contexts where a bool
14304      is expected (e.g., an if condition); however, implicit
14305      conversions (e.g., to int) that can occur with bool are not
14306      allowed, eliminating some sources of user error. One possible
14307      implementation choice for this type is pointer-to-member.  - end
14308      note]
14309</pre>
14310
14311<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
14312<p><i>[Lillehammer: Doug provided revised wording for
14313  "unspecified-bool-type".]</i></p>
14314
14315<hr>
14316<a name="469"><h3>469.&nbsp;vector&lt;bool&gt; ill-formed relational operators</h3></a><p><b>Section:</b>&nbsp;23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
14317
14318<p>
14319The overloads of relational operators for vector&lt;bool&gt; specified
14320in [lib.vector.bool] are redundant (they are semantically identical
14321to those provided for the vector primary template) and may even be
14322diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
14323in c++std-lib-13647).
14324</p>
14325
14326<p><b>Proposed resolution:</b></p>
14327<p>
14328Remove all overloads of overloads of relational operators for
14329vector&lt;bool&gt; from [lib.vector.bool].
14330</p>
14331<hr>
14332<a name="474"><h3>474.&nbsp;confusing Footnote 297</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;1 Jul 2004</p>
14333
14334<p>
14335I think Footnote 297 is confused. The paragraph it applies to seems
14336quite clear in that widen() is only called if the object is not a char
14337stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
14338value of widen(c) is otherwise.
14339</p>
14340<p><b>Proposed resolution:</b></p>
14341<p>
14342I propose to strike the Footnote.
14343</p>
14344<hr>
14345<a name="475"></a><h3><a name="475">475.&nbsp;May the function object passed to for_each modify the elements of the iterated sequence?</a></h3><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Stephan T. Lavavej, Jaakko Jarvi&nbsp; <b>Date:</b>&nbsp;9 Jul 2004</p>
14346<p>
14347It is not clear whether the function object passed to for_each is allowed to
14348modify the elements of the sequence being iterated over.
14349</p>
14350
14351<p>
14352for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
14353Non-modifying sequence operations". 'Non-modifying sequence operation' is
14354never defined.
14355</p>
14356
14357<p>
1435825(5) says: "If an algorithm's Effects section says that a value pointed to
14359by any iterator passed as an argument is modified, then that algorithm has
14360an additional type requirement: The type of that argument shall satisfy the
14361requirements of a mutable iterator (24.1)."
14362</p>
14363
14364<p>for_each's Effects section does not mention whether arguments can be
14365modified:</p>
14366
14367<blockquote>
14368  "Effects: Applies f to the result of dereferencing every iterator in the
14369   range [first, last), starting from first and proceeding to last - 1."
14370</blockquote>
14371
14372<p>
14373Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
14374the sense that neither the algorithms themselves nor the function objects
14375passed to the algorithms may modify the sequences or elements in any way.
14376This DR affects only for_each.
14377</p>
14378
14379<p>
14380We suspect that for_each's classification in "non-modifying sequence
14381operations" means that the algorithm itself does not inherently modify the
14382sequence or the elements in the sequence, but that the function object
14383passed to it may modify the elements it operates on.
14384</p>
14385
14386<p>
14387The original STL document by Stepanov and Lee explicitly prohibited the
14388function object from modifying its argument.
14389The "obvious" implementation of for_each found in several standard library
14390implementations, however, does not impose this restriction.
14391As a result, we suspect that the use of for_each with function objects that modify
14392their arguments is wide-spread.
14393If the restriction was reinstated, all such code would become non-conforming.
14394Further, none of the other algorithms in the Standard
14395could serve the purpose of for_each (transform does not guarantee the order in
14396which its function object is called).
14397</p>
14398
14399<p>
14400We suggest that the standard be clarified to explicitly allow the function object
14401passed to for_each modify its argument.</p>
14402
14403<p><b>Proposed resolution:</b></p>
14404<p>Add a nonnormative note to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>: If
14405the type of 'first' satisfies the requirements of a mutable iterator,
14406'f' may apply nonconstant functions through the dereferenced iterators
14407passed to it.
14408</p>
14409
14410<p><b>Rationale:</b></p>
14411<p>The LWG believes that nothing in the standard prohibits function
14412  objects that modify the sequence elements. The problem is that
14413  for_each is in a secion entitled "nonmutating algorithms", and the
14414  title may be confusing.  A nonnormative note should clarify that.</p>
14415<hr>
14416<a name="478"><h3>478.&nbsp;Should forward iterator requirements table have a line for r-&gt;m?</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;11 Jul 2004</p>
14417<p>
14418The Forward Iterator requirements table contains the following:
14419</p>
14420<pre> expression  return type         operational  precondition
14421                                  semantics
14422  ==========  ==================  ===========  ==========================
14423  a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
14424              otherwise const U&amp;
14425
14426  r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
14427</pre>
14428
14429<p>The second line may be unnecessary.  Paragraph 11 of
14430  [lib.iterator.requirements] says:
14431</p>
14432
14433<blockquote>
14434   In the following sections, a and b denote values of type const X, n
14435   denotes a value of the difference type Distance, u, tmp, and m
14436   denote identifiers, r denotes a value of X&amp;, t denotes a value of
14437   value type T, o denotes a value of some type that is writable to
14438   the output iterator.
14439</blockquote>
14440
14441<p>
14442Because operators can be overloaded on an iterator's const-ness, the
14443current requirements allow iterators to make many of the operations
14444specified using the identifiers a and b invalid for non-const
14445iterators.</p>
14446
14447<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
14448<p><b>Proposed resolution:</b></p>
14449
14450<p>Remove the "r-&gt;m" line from the Forward Iterator requirements
14451table. Change</p>
14452<blockquote>
14453    "const X"
14454</blockquote>
14455
14456<p> to </p>
14457
14458<blockquote>
14459    "X or const X"
14460</blockquote>
14461
14462<p>in paragraph 11 of [lib.iterator.requirements].</p>
14463
14464
14465<p><b>Rationale:</b></p>
14466<p>
14467This is a defect because it constrains an lvalue to returning a modifiable lvalue.
14468</p>
14469<hr>
14470<a name="495"><h3>495.&nbsp;Clause 22 template parameter requirements</h3></a><p><b>Section:</b>&nbsp;22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;10 Jan 2005</p>
14471<p>It appears that there are no requirements specified for many of the
14472template parameters in clause 22. It looks like this issue has never
14473come up, except perhaps for Facet.</p>
14474
14475<p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
14476either, which is the wording that allows requirements on template
14477parameters to be identified by name.</p>
14478
14479<p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
14480changed to cover clause 22. A better change, which will cover us in
14481the future, would be to say that it applies to all the library
14482clauses. Then if a template gets added to any library clause we are
14483covered.</p>
14484
14485<p>charT, InputIterator, and other names with requirements defined
14486elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
14487But there are a few template arguments names which I don't think have
14488requirements given elsewhere:</p>
14489
14490<ul>
14491<li>internT and externT.  The fix is to add wording saying that internT
14492and externT must meet the same requirements as template arguments
14493named charT.</li>
14494
14495<li>stateT.  I'm not sure about this one. There already is some wording,
14496but it seems a bit vague.</li>
14497
14498<li>Intl.  [lib.locale.moneypunct.byname] The fix for this one is to
14499rename "Intl" to "International". The name is important because other
14500text identifies the requirements for the name International but not
14501for Intl.</li>
14502</ul>
14503<p><b>Proposed resolution:</b></p>
14504<p>Change 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>, paragraph 1, from:</p>
14505<blockquote>
14506The Requirements subclauses may describe names that are used to
14507specify constraints on template arguments.153) These names are used in
14508clauses 20, 23, 25, and 26 to describe the types that may be supplied
14509as arguments by a C++ program when instantiating template components
14510from the library.
14511</blockquote>
14512<p>to:</p>
14513<blockquote>
14514The Requirements subclauses may describe names that are used to
14515specify constraints on template arguments.153) These names are used in
14516library clauses to describe the types that may be supplied as
14517arguments by a C++ program when instantiating template components from
14518the library.
14519</blockquote>
14520
14521<p>In the front matter of class 22, locales, add:</p>
14522<blockquote>
14523Template parameter types internT and externT shall meet the
14524requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>).
14525</blockquote>
14526<p><b>Rationale:</b></p>
14527<p>
14528 Again, a blanket clause isn't blanket enough. Also, we've got a
14529 couple of names that we don't have blanket requirement statements
14530 for. The only issue is what to do about stateT. This wording is
14531 thin, but probably adequate.</p>
14532<hr>
14533<a name="496"><h3>496.&nbsp;Illegal use of "T" in vector&lt;bool&gt;</h3></a><p><b>Section:</b>&nbsp;23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;richard@ex-parrot.com&nbsp; <b>Date:</b>&nbsp;10 Feb 2005</p>
14534<p>
14535In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>,
14536the non-template assign() function has the signature</p>
14537
14538<pre>  void assign( size_type n, const T&amp; t );
14539</pre>
14540
14541<p>The type, T, is not defined in this context.</p>
14542<p><b>Proposed resolution:</b></p>
14543<p>Replace "T" with "value_type".</p>
14544<hr>
14545<a name="497"><h3>497.&nbsp;meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b>&nbsp;18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Mar 2005</p>
14546
14547<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
14548
14549<blockquote>
14550<p>static const bool traps;<br>
14551-59- true if trapping is implemented for the type.204)
14552<br>
14553Footnote 204: Required by LIA-1.
14554</p>
14555</blockquote>
14556
14557<p>It's not clear what is meant by "is implemented" here.</p>
14558
14559<p>
14560In the context of floating point numbers it seems reasonable to expect
14561to be able to use traps to determine whether a program can "safely" use
14562infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
14563without causing a trap (i.e., on UNIX without having to worry about
14564getting a signal). When traps is true, I would expect any of the
14565operations in section 7 of IEEE 754 to cause a trap (and my program
14566to get a SIGFPE). So, for example, on Alpha, I would expect traps
14567to be true by default (unless I compiled my program with the -ieee
14568option), false by default on most other popular architectures,
14569including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
14570traps to be explicitly enabled by the program.
14571</p>
14572
14573<p>
14574Another possible interpretation of p59 is that traps should be true
14575on any implementation that supports traps regardless of whether they
14576are enabled by default or not. I don't think such an interpretation
14577makes the traps member very useful, even though that is how traps is
14578implemented on several platforms. It is also the only way to implement
14579traps on platforms that allow programs to enable and disable trapping
14580at runtime.
14581</p>
14582<p><b>Proposed resolution:</b></p>
14583<p>Change p59 to read:</p>
14584<blockquote>True if, at program startup, there exists a value of the type that
14585  would cause an arithmetic operation using that value to trap.</blockquote>
14586<p><b>Rationale:</b></p>
14587<p>
14588 Real issue, since trapping can be turned on and off. Unclear what a
14589 static query can say about a dynamic issue. The real advice we should
14590 give users is to use cfenv for these sorts of queries. But this new
14591 proposed resolution is at least consistent and slightly better than
14592 nothing.</p>
14593<hr>
14594<a name="505"><h3>505.&nbsp;Result_type in random distribution requirements</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14595<p>
14596Table 17: Random distribution requirements
14597</p>
14598<p>
14599Row 1 requires that each random distribution provide a nested type "input_type";
14600this type denotes the type of the values that the distribution consumes.
14601</p>
14602<p>
14603Inspection of all distributions in [tr.rand.dist] reveals that each distribution
14604provides a second typedef ("result_type") that denotes the type of the values the
14605distribution produces when called.
14606</p>
14607<p><b>Proposed resolution:</b></p>
14608<p>
14609It seems to me that this is also a requirement
14610for all distributions and should therefore be  indicated as such via a new second
14611row to this table 17:
14612</p>
14613<table border="1" cellpadding="5">
14614<tbody><tr>
14615<td>X::result_type</td>
14616<td>T</td>
14617<td>---</td>
14618<td>compile-time</td>
14619</tr>
14620</tbody></table>
14621
14622<p><i>[
14623Berlin:  Voted to WP.  N1932 adopts the proposed resolution:  see Table 5 row 1.
14624]</i></p>
14625
14626<hr>
14627<a name="507"><h3>507.&nbsp;Missing requirement for variate_generator::operator()</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14628<p>
14629Paragraph 11 of [tr.rand.var] equires that the member template
14630</p>
14631<blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
14632</pre></blockquote>
14633<p>
14634return
14635</p>
14636<blockquote><pre>distribution()(e, value)
14637</pre></blockquote>
14638<p>
14639However, not all distributions have an operator() with a corresponding signature.
14640</p>
14641
14642<p><i>[
14643Berlin:  As a working group we voted in favor of N1932 which makes this moot:
14644variate_generator has been eliminated.  Then in full committee we voted to give
14645this issue WP status (mistakenly).
14646]</i></p>
14647
14648<p><b>Proposed resolution:</b></p>
14649<p>
14650We therefore  recommend that we insert the following precondition before paragraph 11:
14651</p>
14652<blockquote>
14653Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
14654</blockquote>
14655<hr>
14656<a name="508"><h3>508.&nbsp;Bad parameters for ranlux64_base_01</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.predef"> [tr.rand.predef]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14657<p>
14658The fifth of these engines with predefined parameters, ranlux64_base_01,
14659appears to have an unintentional error for which there is a simple correction.
14660The two pre-defined  subtract_with_carry_01 engines are given as:
14661</p>
14662<blockquote><pre>typedef subtract_with_carry_01&lt;float,  24, 10, 24&gt; ranlux_base_01;
14663typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
14664</pre></blockquote>
14665<p>
14666We demonstrate below that ranlux64_base_01 fails to meet the intent of the
14667random number generation proposal, but that the simple correction to
14668</p>
14669<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48,  5, 12&gt; ranlux64_base_01;
14670</pre></blockquote>
14671<p>
14672does meet the intent of defining well-known good parameterizations.
14673</p>
14674<p>
14675The ranlux64_base_01 engine as presented fails to meet the intent for
14676predefined engines, stated in proposal N1398 (section E):
14677</p>
14678<blockquote><p>
14679In order to make good random numbers available to a large number of library
14680users, this proposal not only defines generic random-number engines, but also
14681provides a number of predefined well-known good parameterizations for those.
14682</p></blockquote>
14683<p>
14684The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
14685long period and so meets this criterion.  This property makes it suitable for
14686use in the excellent discard_block  engines defined subsequently.  The proof
14687of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
14688+ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
14689as defined in [tr.rand.eng.sub1]).
14690</p>
14691<p>
14692The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
14693For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
14694explicit factorization  would be a challenge).  In consequence, while it is
14695certainly possible for some seeding states that this engine would have a very
14696long period, it is not at all �well-known� that this is the case. The intent
14697in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
14698use in the physics community.  This is isomorphic to the predefined ranlux_base_01,
14699but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
14700to deliver 48 random bits at a time rather than 24.
14701</p>
14702<p><b>Proposed resolution:</b></p>
14703<p>
14704To achieve this intended behavior, the correct template parameteriztion  would be:
14705</p>
14706<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
14707</pre></blockquote>
14708<p>
14709The sequence of mantissa bits delivered by this is isomorphic (treating each
14710double as having the  bits of two floats) to that delivered by ranlux_base_01.
14711</p>
14712<p>
14713<b>References:</b>
14714</p>
14715<ol>
14716<li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
14717<li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
14718<li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
14719</ol>
14720
14721<p><i>[
14722Berlin: Voted to WP.  N1932 adopts the proposed resolution in 26.3.5,
14723just above paragraph 5.
14724]</i></p>
14725
14726<hr>
14727<a name="519"><h3>519.&nbsp;Data() undocumented</h3></a><p><b>Section:</b>&nbsp;TR1 6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.array.array"> [tr.array.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14728<p>
14729<tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
14730</p>
14731<p><b>Proposed resolution:</b></p>
14732<p>
14733Add a new section, after 6.2.2.3:
14734</p>
14735<blockquote><pre>T*       data()
14736const T* data() const;
14737</pre></blockquote>
14738<p>
14739<b>Returns:</b> <tt>elems</tt>.
14740</p>
14741<p>
14742Change 6.2.2.4/2 to:
14743</p>
14744<blockquote>
14745In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
14746of <tt>data()</tt> is unspecified.
14747</blockquote>
14748<hr>
14749<a name="520"><h3>520.&nbsp;Result_of and pointers to data members</h3></a><p><b>Section:</b>&nbsp;TR1 3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind"> [tr.func.bind]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14750<p>
14751In the original proposal for binders, the return type of bind() when
14752called with a pointer to member data as it's callable object was
14753defined to be mem_fn(ptr); when Peter Dimov and I  unified the
14754descriptions of the TR1 function objects we hoisted the descriptions
14755of return types into the INVOKE pseudo-function and into result_of.
14756Unfortunately, we left pointer to member data out of result_of, so
14757bind doesn't have any specified behavior when called with a pointer
14758to  member data.
14759</p>
14760<p><b>Proposed resolution:</b></p>
14761<p><i>[
14762Pete and Peter will provide wording.
14763]</i></p>
14764
14765<p>
14766In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:
14767</p>
14768<ol start="3">
14769<li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt>
14770shall be <tt><i>cv</i> R&amp;</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&amp;</tt>,
14771<tt>R</tt> otherwise.</li>
14772</ol>
14773
14774<p><i>[
14775Peter provided wording.
14776]</i></p>
14777<hr>
14778<a name="521"><h3>521.&nbsp;Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b>&nbsp;TR1 2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.refwrp.refwrp"> [tr.util.refwrp.refwrp]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14779<p>
147802.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
14781derived from unary_function&lt;T, R&gt; if T is:
14782</p>
14783<blockquote>
14784a pointer to member function type with cv-qualifier cv and no arguments;
14785the type T1 is cv T* and R is the return type of the pointer to member function;
14786</blockquote>
14787<p>
14788The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
14789function. It should be a pointer to the class that T is a pointer to member of.
14790Like this:
14791</p>
14792<blockquote>
14793a pointer to a member function R T0::f() cv (where cv represents the member
14794function's cv-qualifiers); the type T1 is cv T0*
14795</blockquote>
14796<p>
14797Similarly, bullet item 2 in 2.1.2/4 should be:
14798</p>
14799<blockquote>
14800a pointer to a member function R T0::f(T2) cv (where cv represents the member
14801function's cv-qualifiers); the type T1 is cv T0*
14802</blockquote>
14803<p><b>Proposed resolution:</b></p>
14804
14805<p>
14806Change bullet item 2 in 2.1.2/3:
14807</p>
14808
14809<blockquote>
14810<ul>
14811<li>
14812a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
14813the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return
14814type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
14815(where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
14816the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
14817</li>
14818</ul>
14819</blockquote>
14820
14821<p>
14822Change bullet item 2 in 2.1.2/4:
14823</p>
14824
14825<blockquote>
14826<ul>
14827<li>
14828a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
14829of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and
14830<tt>R</tt> is the return type of the pointer to member function</del>
14831<ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
14832function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
14833</li>
14834</ul>
14835</blockquote>
14836
14837<hr>
14838<a name="530"><h3>530.&nbsp;Must elements of a string be contiguous?</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;15 Nov 2005</p>
14839<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated
14840&nbsp;&nbsp; that the elements of a vector must be stored in contiguous memory.
14841&nbsp;&nbsp; Should the same also apply to <tt>basic_string</tt>?</p>
14842
14843<p>We almost require contiguity already. Clause 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>
14844&nbsp; defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
14845&nbsp; is a similar guarantee if we access the string's elements via the
14846&nbsp; iterator interface.</p>
14847
14848<p>Given the existence of <tt>data()</tt>, and the definition of
14849&nbsp; <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
14850&nbsp; I don't believe it's possible to write a useful and standard-
14851&nbsp; conforming <tt>basic_string</tt> that isn't contiguous. I'm not
14852&nbsp; aware of any non-contiguous implementation. We should just require
14853&nbsp; it.
14854</p>
14855<p><b>Proposed resolution:</b></p>
14856<p>Add the following text to the end of 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>,
14857paragraph 2. </p>
14858
14859<blockquote>
14860&nbsp; <p>The characters in a string are stored contiguously, meaning that if
14861&nbsp; <tt>s</tt> is a <tt>basic_string&lt;charT, Allocator&gt;</tt>, then
14862&nbsp; it obeys the identity
14863&nbsp; <tt>&amp;*(s.begin() + n) == &amp;*s.begin() + n</tt>
14864&nbsp; for all <tt>0 &lt;= n &lt; s.size()</tt>.
14865  </p>
14866</blockquote>
14867<hr>
14868<a name="533"><h3>533.&nbsp;typo in 2.2.3.10/1</h3></a><p><b>Section:</b>&nbsp;TR1 2.2.3.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.getdeleter"> [tr.util.smartptr.getdeleter]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;9 Nov 2005</p>
14869<p>
14870I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
14871says:
14872</p>
14873<blockquote>
14874If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>...
14875</blockquote>
14876<p>
14877but <tt>get_deleter</tt> is a free function!
14878</p>
14879<p><b>Proposed resolution:</b></p>
14880<p>
14881Therefore, I think should be:
14882</p>
14883<blockquote>
14884If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
14885</blockquote>
14886<hr>
14887<a name="535"><h3>535.&nbsp;std::string::swap specification poorly worded</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;14 Dec 2005</p>
14888<p>
14889std::string::swap currently says for effects and postcondition:
14890</p>
14891
14892<blockquote>
14893<p>
14894<i>Effects:</i> Swaps the contents of the two strings.
14895</p>
14896
14897<p>
14898<i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>,
14899<tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>.
14900</p>
14901</blockquote>
14902
14903<p>
14904Specifying both Effects and Postcondition seems redundant, and the postcondition
14905needs to be made stronger. Users would be unhappy if the characters were not in
14906the same order after the swap.
14907</p>
14908<p><b>Proposed resolution:</b></p>
14909<blockquote>
14910<p>
14911<del><i>Effects:</i> Swaps the contents of the two strings.</del>
14912</p>
14913
14914<p>
14915<i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins>
14916characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
14917<tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that
14918<del>were</del> <ins>was</ins> in <tt>*this</tt>.
14919</p>
14920</blockquote>
14921<hr>
14922<a name="537"><h3>537.&nbsp;Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;12 Feb 2006</p>
14923<p>
14924In the most recent working draft, I'm still seeing:
14925</p>
14926
14927<blockquote><pre>seekg(off_type&amp; off, ios_base::seekdir dir)
14928</pre></blockquote>
14929
14930<p>
14931and
14932</p>
14933
14934<blockquote><pre>seekp(pos_type&amp; pos)
14935
14936seekp(off_type&amp; off, ios_base::seekdir dir)
14937</pre></blockquote>
14938
14939<p>
14940that is, by reference off and pos arguments.
14941</p>
14942<p><b>Proposed resolution:</b></p>
14943<p>
14944After 27.6.1.3p42 change:
14945</p>
14946
14947<blockquote><pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
14948</pre></blockquote>
14949
14950<p>
14951After 27.6.2.4p1 change:
14952</p>
14953
14954<blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(pos_type<del>&amp;</del> <i>pos</i>);
14955</pre></blockquote>
14956
14957<p>
14958After 27.6.2.4p3 change:
14959</p>
14960
14961<blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
14962</pre></blockquote>
14963<hr>
14964<a name="538"></a><h3><a name="538">538.&nbsp;241 again: Does unique_copy() require CopyConstructible and Assignable?</a></h3><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;9 Feb 2006</p>
14965<p>
14966I believe I botched the resolution of
14967<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">
14968241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now
14969has WP status.
14970</p>
14971
14972<p>
14973This talks about <tt>unique_copy</tt> requirements and currently reads:
14974</p>
14975
14976<blockquote>
14977-5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
14978<tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
14979shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> shall
14980be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
14981requirements of forward iterator then the value type of <tt>InputIterator</tt>
14982must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required.
14983</blockquote>
14984
14985<p>
14986The problem (which Paolo discovered) is that when the iterators are at their
14987most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want
14988<tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and
14989<tt>CopyAssignable</tt> (for the most efficient implementation).  However this
14990proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>,
14991and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>.
14992This latter requirement does not necessarily imply that you can:
14993</p>
14994
14995<blockquote><pre>*<i>first</i> = *<i>first</i>;
14996</pre></blockquote>
14997<p><b>Proposed resolution:</b></p>
14998<blockquote>
14999-5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
15000<tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
15001shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt>
15002shall
15003be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
15004requirements of forward iterator then the <del>value type</del>
15005<ins><tt>value_type</tt></ins> of <tt>InputIterator</tt>
15006must be CopyConstructible (20.1.3) <ins>and Assignable</ins>.
15007Otherwise CopyConstructible is not required.
15008</blockquote>
15009<hr>
15010<a name="540"><h3>540.&nbsp;shared_ptr&lt;void&gt;::operator*()</h3></a><p><b>Section:</b>&nbsp;TR1 2.2.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared.obs"> [tr.util.smartptr.shared.obs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2005</p>
15011<p>
15012I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
15013that talks about the operator*() member function of shared_ptr:
15014</p>
15015
15016<blockquote>
15017  Notes: When T is void, attempting to instantiate this member function
15018  renders the program ill-formed. [Note: Instantiating shared_ptr&lt;void&gt;
15019  does not necessarily result in instantiating this member function.
15020  --end note]
15021</blockquote>
15022
15023<p>
15024with the requirement in temp.inst, p1:
15025</p>
15026
15027<blockquote>
15028  The implicit instantiation of a class template specialization causes
15029  the implicit instantiation of the declarations, but not of the
15030  definitions...
15031</blockquote>
15032
15033<p>
15034I assume that what the note is really trying to say is that
15035"instantiating shared_ptr&lt;void&gt; *must not* result in instantiating
15036this member function." That is, that this function must not be
15037declared a member of shared_ptr&lt;void&gt;. Is my interpretation
15038correct?
15039</p>
15040<p><b>Proposed resolution:</b></p>
15041<p>
15042Change 2.2.3.5p6
15043</p>
15044
15045<blockquote>
15046-6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate
15047this member function renders the program ill-formed. [<i>Note:</i>
15048Instantiating <tt>shared_ptr&lt;void&gt;</tt> does not necessarily result in
15049instantiating this member function. <i>--end note</i>]</del> <ins>it is
15050unspecified whether this member function is declared or not, and if so, what its
15051return type is, except that the declaration (although not necessarily the
15052definition) of the function shall be well-formed.</ins>
15053</blockquote>
15054
15055<hr>
15056<a name="541"><h3>541.&nbsp;shared_ptr template assignment and void</h3></a><p><b>Section:</b>&nbsp;TR1 2.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared"> [tr.util.smartptr.shared]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;16 Oct 2005</p>
15057<p>
15058Is the void specialization of the template assignment operator taking
15059a shared_ptr&lt;void&gt; as an argument supposed be well-formed?
15060</p>
15061<p>
15062I.e., is this snippet well-formed:
15063</p>
15064<blockquote><pre>shared_ptr&lt;void&gt; p;
15065p.operator=&lt;void&gt;(p);
15066</pre></blockquote>
15067
15068<p>
15069Gcc complains about auto_ptr&lt;void&gt;::operator*() returning a reference
15070to void. I suspect it's because shared_ptr has two template assignment
15071operators, one of which takes auto_ptr, and the auto_ptr template gets
15072implicitly instantiated in the process of overload resolution.
15073</p>
15074
15075<p>
15076The only way I see around it is to do the same trick with auto_ptr&lt;void&gt;
15077operator*() as with the same operator in shared_ptr&lt;void&gt;.
15078</p>
15079
15080<p>
15081PS Strangely enough, the EDG front end doesn't mind the code, even
15082though in a small test case (below) I can reproduce the error with
15083it as well.
15084</p>
15085
15086<blockquote><pre>template &lt;class T&gt;
15087struct A { T&amp; operator*() { return *(T*)0; } };
15088
15089template &lt;class T&gt;
15090struct B {
15091    void operator= (const B&amp;) { }
15092    template &lt;class U&gt;
15093    void operator= (const B&lt;U&gt;&amp;) { }
15094    template &lt;class U&gt;
15095    void operator= (const A&lt;U&gt;&amp;) { }
15096};
15097
15098int main ()
15099{
15100    B&lt;void&gt; b;
15101    b.operator=&lt;void&gt;(b);
15102}
15103</pre></blockquote>
15104<p><b>Proposed resolution:</b></p>
15105<p>
15106In [lib.memory] change:
15107</p>
15108<blockquote><pre>template&lt;class X&gt; class auto_ptr;
15109<ins>template&lt;&gt; class auto_ptr&lt;void&gt;;</ins>
15110</pre></blockquote>
15111
15112<p>
15113In [lib.auto.ptr]/2 add the following before the last closing brace:
15114</p>
15115
15116<blockquote><pre>template&lt;&gt; class auto_ptr&lt;void&gt;
15117{
15118public:
15119&nbsp; &nbsp; typedef void element_type;
15120};
15121</pre></blockquote>
15122
15123<p>----- End of document -----</p>
15124</body></html>