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 Active Issues 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">N2130=06-0200</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 <howard.hinnant@gmail.com></td> 24</tr> 25</tbody></table> 26<h1>C++ Standard Library Active Issues 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-defects.html">Library Defect Reports 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>The purpose of this document is to record the status of issues 40 which have come before the Library Working Group (LWG) of the ANSI 41 (J16) and ISO (WG21) C++ Standards Committee. Issues represent 42 potential defects in the ISO/IEC IS 14882:1998(E) document. Issues 43 are not to be used to request new features. </p> 44 45 <p>This document contains only library issues which are actively being 46 considered by the Library Working Group. That is, issues which have a 47 status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>, 48 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>. See 49 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and 50 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p> 51 52 <p>The issues in these lists are not necessarily formal ISO Defect 53 Reports (DR's). While some issues will eventually be elevated to 54 official Defect Report status, other issues will be disposed of in 55 other ways. See <a href="#Status">Issue Status</a>.</p> 56 57 <p>This document is in an experimental format designed for both 58 viewing via a world-wide web browser and hard-copy printing. It 59 is available as an HTML file for browsing or PDF file for 60 printing.</p> 61 62 <p>Prior to Revision 14, library issues lists existed in two slightly 63 different versions; a Committee Version and a Public 64 Version. Beginning with Revision 14 the two versions were combined 65 into a single version.</p> 66 67 <p>This document includes <i>[bracketed italicized notes]</i> as a 68 reminder to the LWG of current progress on issues. Such notes are 69 strictly unofficial and should be read with caution as they may be 70 incomplete or incorrect. Be aware that LWG support for a particular 71 resolution can quickly change if new viewpoints or killer examples are 72 presented in subsequent discussions.</p> 73 74 <p>For the most current official version of this document see 75 <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>. 76 Requests for further information about this document should include 77 the document number above, reference ISO/IEC 14882:1998(E), and be 78 submitted to Information Technology Industry Council (ITI), 1250 Eye 79 Street NW, Washington, DC 20005.</p> 80 81 <p>Public information as to how to obtain a copy of the C++ Standard, 82 join the standards committee, submit an issue, or comment on an issue 83 can be found in the comp.std.c++ FAQ. 84 Public discussion of C++ Standard related issues occurs on <a href="news://comp.std.c++/">news:comp.std.c++</a>. 85 </p> 86 87 <p>For committee members, files available on the committee's private 88 web site include the HTML version of the Standard itself. HTML 89 hyperlinks from this issues list to those files will only work for 90 committee members who have downloaded them into the same disk 91 directory as the issues list files. </p> 92<h2>Revision History</h2> 93<ul> 94<li>R45: 952006-11-03 post-Portland mailing. 96Moved 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. 97Moved 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. 98Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup. 99Moved 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. 100Moved 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. 101Moved 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. 102Added 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>. 103</li> 104<li>R44: 1052006-09-08 pre-Portland mailing. 106Added 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>. 107</li> 108<li>R43: 1092006-06-23 mid-term mailing. 110Added 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>. 111Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>. 112Moved 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. 113</li> 114<li>R42: 1152006-04-21 post-Berlin mailing. 116Added 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>. 117Moved 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. 118Moved 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. 119Moved 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. 120Moved 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. 121Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#534">534</a> to Review. 122</li> 123<li>R41: 1242006-02-24 pre-Berlin mailing. 125Added 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>. 126Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open. 127Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>. 128</li> 129<li>R40: 1302005-12-16 mid-term mailing. 131Added 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>. 132</li> 133<li>R39: 1342005-10-14 post-Mont Tremblant mailing. 135Added 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>. 136Moved 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. 137Moved 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. 138Moved 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. 139Moved 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. 140Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD. 141Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review. 142</li> 143<li>R38: 1442005-07-03 pre-Mont Tremblant mailing. 145Merged 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>. 146Added 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> 147</li> 148<li>R37: 1492005-06 mid-term mailing. 150Added 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>. 151</li> 152<li>R36: 1532005-04 post-Lillehammer mailing. All issues in "ready" status except 154for <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 155previously in "DR" status were moved to "WP". 156</li> 157<li>R35: 1582005-03 pre-Lillehammer mailing. 159</li> 160<li>R34: 1612005-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>. 162</li> 163<li>R33: 1642004-11 post-Redmond mailing. Reflects actions taken in Redmond. 165</li> 166<li>R32: 1672004-09 pre-Redmond mailing: reflects new proposed resolutions and 168new issues received after the 2004-07 mailing. Added 169new 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>. 170</li> 171<li>R31: 1722004-07 mid-term mailing: reflects new proposed resolutions and 173new issues received after the post-Sydney mailing. Added 174new 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>. 175</li> 176<li>R30: 177Post-Sydney mailing: reflects decisions made at the Sydney meeting. 178Voted all "Ready" issues from R29 into the working paper. 179Added 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>. 180</li> 181<li>R29: 182Pre-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>. 183</li> 184<li>R28: 185Post-Kona mailing: reflects decisions made at the Kona meeting. 186Added 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>. 187</li> 188<li>R27: 189Pre-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>. 190</li> 191<li>R26: 192Post-Oxford mailing: reflects decisions made at the Oxford meeting. 193All issues in Ready status were voted into DR status. All issues in 194DR status were voted into WP status. 195</li> 196<li>R25: 197Pre-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>. 198</li> 199<li>R24: 200Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz 201meeting. 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 202moved 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 203at 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 204concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording. 205</li> 206<li>R23: 207Pre-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>. 208Moved issues in the TC to TC status. 209</li> 210<li>R22: 211Post-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>. 212</li> 213<li>R21: 214Pre-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>. 215</li> 216<li>R20: 217Post-Redmond mailing; reflects actions taken in Redmond. Added 218new 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 219<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 220not discussed at the meeting. 221 222All Ready issues were moved to DR status, with the exception of issues 223<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>. 224 225Noteworthy issues discussed at Redmond include 226<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>, 227<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>. 228</li> 229<li>R19: 230Pre-Redmond mailing. Added new issues 231<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>. 232</li> 233<li>R18: 234Post-Copenhagen mailing; reflects actions taken in Copenhagen. 235Added 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 236new 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>. 237 238Changed status of issues 239<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> 240<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> 241<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> 242<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> 243<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> 244<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> 245<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a> 246to DR. 247 248Changed status of issues 249<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> 250<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> 251<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> 252<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> 253<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> 254<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> 255<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> 256<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> 257<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> 258to Ready. 259 260Closed issues 261<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> 262<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> 263<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a> 264as NAD. 265 266</li> 267<li>R17: 268Pre-Copenhagen mailing. Converted issues list to XML. Added proposed 269resolutions 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>. 270Added 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>. 271</li> 272<li>R16: 273post-Toronto mailing; reflects actions taken in Toronto. Added new 274issues <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 275<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>, 276<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>, 277<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>, 278<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>, 279<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>, 280<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>, 281<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>, 282<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>, 283<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>, 284<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>, 285<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>, 286<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>, 287<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 288issue <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 289<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 290issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it 291appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix 292the bug in enough places. 293</li> 294<li>R15: 295pre-Toronto mailing. Added issues 296<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 297changes so that we pass Weblint tests. 298</li> 299<li>R14: 300post-Tokyo II mailing; reflects committee actions taken in 301Tokyo. 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) 302</li> 303<li>R13: 304pre-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>. 305</li> 306<li>R12: 307pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to 308<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 309of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue 310<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>. 311</li> 312<li>R11: 313post-Kona mailing: Updated to reflect LWG and full committee actions 314in Kona (99-0048/N1224). Note changed resolution of issues 315<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> 316to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and 317"closed" documents. Changed the proposed resolution of issue 318<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 319of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. 320</li> 321<li>R10: 322pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, 323<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>, 324<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 325<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99) 326</li> 327<li>R9: 328pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to 329<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and 330"closed" documents. (99-0030/N1206, 25 Aug 99) 331</li> 332<li>R8: 333post-Dublin mailing. Updated to reflect LWG and full committee actions 334in Dublin. (99-0016/N1193, 21 Apr 99) 335</li> 336<li>R7: 337pre-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>, 338<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>, 339<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>, 340<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) 341</li> 342<li>R6: 343pre-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>, 344and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99) 345</li> 346<li>R5: 347update 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 348<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 349for making list public. (30 Dec 98) 350</li> 351<li>R4: 352post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>, 353<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 354issues corrected. (22 Oct 98) 355</li> 356<li>R3: 357post-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> 358added, many issues updated to reflect LWG consensus (12 Oct 98) 359</li> 360<li>R2: 361pre-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, 362issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98) 363</li> 364<li>R1: 365Correction 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 366format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98) 367</li> 368</ul> 369<h2> 370<a name="Status"></a>Issue Status</h2> 371 <p><b><a name="New">New</a></b> - The issue has not yet been 372 reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a 373 suggestion from the issue submitter, and should not be construed as 374 the view of LWG.</p> 375 376 <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue 377 but is not yet ready to move the issue forward. There are several 378 possible reasons for open status:</p> 379 <ul> 380 <li>Consensus may have not yet have been reached as to how to deal 381 with the issue.</li> 382 <li>Informal consensus may have been reached, but the LWG awaits 383 exact <b>Proposed Resolution</b> wording for review.</li> 384 <li>The LWG wishes to consult additional technical experts before 385 proceeding.</li> 386 <li>The issue may require further study.</li> 387 </ul> 388 389 <p>A <b>Proposed Resolution</b> for an open issue is still not be 390 construed as the view of LWG. Comments on the current state of 391 discussions are often given at the end of open issues in an italic 392 font. Such comments are for information only and should not be given 393 undue importance.</p> 394 395 <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that 396 the issue is a duplicate of another issue, and will not be further 397 dealt with. A <b>Rationale</b> identifies the duplicated issue's 398 issue number. </p> 399 400 <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that 401 the issue is not a defect in the Standard, and the issue is ready to 402 forward to the full committee as a proposed record of response. A 403 <b>Rationale</b> discusses the LWG's reasoning.</p> 404 405 <p><b><a name="Review">Review</a></b> - Exact wording of a 406 <b>Proposed Resolution</b> is now available for review on an issue 407 for which the LWG previously reached informal consensus.</p> 408 409 <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has 410 been reviewed online, but not in a meeting, and some support has been formed 411 for the proposed resolution. Tentatively Ready issues may be moved to Ready 412 and forwarded to full committee within the same meeting. Unlike Ready issues 413 they will be reviewed in subcommittee prior to forwarding to full committee.</p> 414 415 <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus 416 that the issue is a defect in the Standard, the <b>Proposed 417 Resolution</b> is correct, and the issue is ready to forward to the 418 full committee for further action as a Defect Report (DR).</p> 419 420 <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16 421 committee has voted to forward the issue to the Project Editor to be 422 processed as a Potential Defect Report. The Project Editor reviews 423 the issue, and then forwards it to the WG21 Convenor, who returns it 424 to the full committee for final disposition. This issues list 425 accords the status of DR to all these Defect Reports regardless of 426 where they are in that process.</p> 427 428 <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full 429 WG21 committee has voted to accept the Defect Report's Proposed 430 Resolution as a Technical Corrigenda. Action on this issue is thus 431 complete and no further action is possible under ISO rules.</p> 432 433 <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed 434 resolution has not been accepted as a Technical Corrigendum, but 435 the full WG21 committee has voted to apply the Defect Report's Proposed 436 Resolution to the working paper.</p> 437 438 <p><b><a name="RR">RR</a></b> - (Record of Response) - The full WG21 439 committee has determined that this issue is not a defect in the 440 Standard. Action on this issue is thus complete and no further 441 action is possible under ISO rules.</p> 442 443 <p><b><a name="Future">Future</a></b> - In addition to the regular 444 status, the LWG believes that this issue should be revisited at the 445 next revision of the standard. It is usually paired with NAD.</p> 446 447 <p>Issues are always given the status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> when 448 they first appear on the issues list. They may progress to 449 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> while the LWG 450 is actively working on them. When the LWG has reached consensus on 451 the disposition of an issue, the status will then change to 452 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> as appropriate. Once the full J16 committee votes to 453 forward Ready issues to the Project Editor, they are given the 454 status of Defect Report ( <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>). These in turn may 455 become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>), 456 or are closed without action other than a Record of Response 457 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a> ). The intent of this LWG process is that 458 only issues which are truly defects in the Standard move to the 459 formal ISO DR status. 460 </p> 461 462<h2>Active Issues</h2> 463<hr> 464<a name="23"><h3>23. Num_get overflow result</h3></a><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p> 465<p>The current description of numeric input does not account for the 466possibility of overflow. This is an implicit result of changing the 467description to rely on the definition of scanf() (which fails to 468report overflow), and conflicts with the documented behavior of 469traditional and current implementations. </p> 470 471<p>Users expect, when reading a character sequence that results in a 472value unrepresentable in the specified type, to have an error 473reported. The standard as written does not permit this. </p> 474 475<p><b>Further comments from Dietmar:</b></p> 476 477<p> 478I don't feel comfortable with the proposed resolution to issue 23: It 479kind of simplifies the issue to much. Here is what is going on: 480</p> 481 482<p> 483Currently, the behavior of numeric overflow is rather counter intuitive 484and hard to trace, so I will describe it briefly: 485</p> 486 487<ul> 488 <li> 489 According to 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> 490 paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would 491 return an input error; otherwise a value is converted to the rules 492 of <tt>scanf</tt>. 493 </li> 494 <li> 495 <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>. 496 </li> 497 <li> 498 <tt>fscanf()</tt> returns an input failure if during conversion no 499 character matching the conversion specification could be extracted 500 before reaching EOF. This is the only reason for <tt>fscanf()</tt> 501 to fail due to an input error and clearly does not apply to the case 502 of overflow. 503 </li> 504 <li> 505 Thus, the conversion is performed according to the rules of 506 <tt>fscanf()</tt> which basically says that <tt>strtod</tt>, 507 <tt>strtol()</tt>, etc. are to be used for the conversion. 508 </li> 509 <li> 510 The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as 511 many matching characters as there are and on overflow continue to 512 consume matching characters but also return a value identical to 513 the maximum (or minimum for signed types if there was a leading minus) 514 value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>. 515 </li> 516 <li> 517 Thus, according to the current wording in the standard, overflows 518 can be detected! All what is to be done is to check <tt>errno</tt> 519 after reading an element and, of course, clearing <tt>errno</tt> 520 before trying a conversion. With the current wording, it can be 521 detected whether the overflow was due to a positive or negative 522 number for signed types. 523 </li> 524</ul> 525 526<p><b>Further discussion from Redmond:</b></p> 527 528<p>The basic problem is that we've defined our behavior, 529including our error-reporting behavior, in terms of C90. However, 530C90's method of reporting overflow in scanf is not technically an 531"input error". The <tt>strto_*</tt> functions are more precise.</p> 532 533<p>There was general consensus that <tt>failbit</tt> should be set 534upon overflow. We considered three options based on this:</p> 535<ol> 536<li>Set failbit upon conversion error (including overflow), and 537 don't store any value.</li> 538<li>Set failbit upon conversion error, and also set <tt>errno</tt> to 539 indicated the precise nature of the error.</li> 540<li>Set failbit upon conversion error. If the error was due to 541 overflow, store +-numeric_limits<T>::max() as an 542 overflow indication.</li> 543</ol> 544 545<p>Straw poll: (1) 5; (2) 0; (3) 8.</p> 546 547 548<p><b>Proposed resolution:</b></p> 549 550<p>Discussed at Lillehammer. General outline of what we want the 551 solution to look like: we want to say that overflow is an error, and 552 provide a way to distinguish overflow from other kinds of errors. 553 Choose candidate field the same way scanf does, but don't describe 554 the rest of the process in terms of format. If a finite input field 555 is too large (positive or negative) to be represented as a finite 556 value, then set failbit and assign the nearest representable value. 557 Bill will provide wording.</p> 558 559<hr> 560<a name="96"><h3>96. Vector<bool> is not a container</h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> 561<p><tt>vector<bool></tt> is not a container as its reference and 562pointer types are not references and pointers. </p> 563 564<p>Also it forces everyone to have a space optimization instead of a 565speed one.</p> 566 567<p><b>See also:</b> 99-0008 == N1185 Vector<bool> is 568Nonconforming, Forces Optimization Choice.</p> 569<p><b>Proposed resolution:</b></p> 570 571<p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p> 572 573<p><i>[In Dublin many present felt that failure to meet Container 574requirements was a defect. There was disagreement as to whether 575or not the optimization requirements constituted a defect.]</i></p> 576 577<p><i>[The LWG looked at the following resolutions in some detail: 578<br> 579 * Not A Defect.<br> 580 * Add a note explaining that vector<bool> does not meet 581Container requirements.<br> 582 * Remove vector<bool>.<br> 583 * Add a new category of container requirements which 584vector<bool> would meet.<br> 585 * Rename vector<bool>.<br> 586<br> 587No alternative had strong, wide-spread, support and every alternative 588had at least one "over my dead body" response.<br> 589<br> 590There was also mention of a transition scheme something like (1) add 591vector_bool and deprecate vector<bool> in the next standard. (2) 592Remove vector<bool> in the following standard.]</i></p> 593 594<p><i>[Modifying container requirements to permit returning proxies 595(thus allowing container requirements conforming vector<bool>) 596was also discussed.]</i></p> 597 598<p><i>[It was also noted that there is a partial but ugly workaround in 599that vector<bool> may be further specialized with a customer 600allocator.]</i></p> 601 602<p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211, 603vector<bool>: More Problems, Better Solutions. Much discussion 604of a two step approach: a) deprecate, b) provide replacement under a 605new name. LWG straw vote on that: 1-favor, 11-could live with, 2-over 606my dead body. This resolution was mentioned in the LWG report to the 607full committee, where several additional committee members indicated 608over-my-dead-body positions.]</i></p> 609 610<p>Discussed at Lillehammer. General agreement that we should 611 deprecate vector<bool> and introduce this functionality under 612 a different name, e.g. bit_vector. This might make it possible to 613 remove the vector<bool> specialization in the standard that comes 614 after C++0x. There was also a suggestion that 615 in C++0x we could additional say that it's implementation defined 616 whether vector<bool> refers to the specialization or to the 617 primary template, but there wasn't general agreement that this was a 618 good idea.</p> 619 620<p>We need a paper for the new bit_vector class.</p> 621 622<hr> 623<a name="201"><h3>201. Numeric limits terminology wrong</h3></a><p><b>Section:</b> 18.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.limits"> [lib.limits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 21 Dec 1999</p> 624<p> 625In some places in this section, the terms "fundamental types" and 626"scalar types" are used when the term "arithmetic types" is intended. 627The current usage is incorrect because void is a fundamental type and 628pointers are scalar types, neither of which should have 629specializations of numeric_limits. 630</p> 631<p><b>Proposed resolution:</b></p> 632<p><i>[Lillehammer: it remains true that numeric_limits is using 633 imprecise language. However, none of the proposals for changed 634 wording are clearer. A redesign of numeric_limits is needed, but this 635 is more a task than an open issue.]</i></p> 636<hr> 637<a name="206"></a><h3><a name="206">206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 29 Aug 1999</p> 638<p>As specified, the implementation of the nothrow version of operator 639new does not necessarily call the ordinary operator new, but may 640instead simply call the same underlying allocator and return a null 641pointer instead of throwing an exception in case of failure.</p> 642 643<p>Such an implementation breaks code that replaces the ordinary 644version of new, but not the nothrow version. If the ordinary version 645of new/delete is replaced, and if the replaced delete is not 646compatible with pointers returned from the library versions of new, 647then when the replaced delete receives a pointer allocated by the 648library new(nothrow), crash follows.</p> 649 650<p>The fix appears to be that the lib version of new(nothrow) must 651call the ordinary new. Thus when the ordinary new gets replaced, the 652lib version will call the replaced ordinary new and things will 653continue to work.</p> 654 655<p>An alternative would be to have the ordinary new call 656new(nothrow). This seems sub-optimal to me as the ordinary version of 657new is the version most commonly replaced in practice. So one would 658still need to replace both ordinary and nothrow versions if one wanted 659to replace the ordinary version.</p> 660 661<p>Another alternative is to put in clear text that if one version is 662replaced, then the other must also be replaced to maintain 663compatibility. Then the proposed resolution below would just be a 664quality of implementation issue. There is already such text in 665paragraph 7 (under the new(nothrow) version). But this nuance is 666easily missed if one reads only the paragraphs relating to the 667ordinary new.</p> 668 669<p><b>Proposed resolution:</b></p> 670<p><b>Rationale:</b></p> 671<p>Yes, they may become unlinked, and that is by design. If a user 672replaces one, the user should also replace the other.</p> 673 674<p><i>[ 675Reopened due to a gcc conversation between Howard, Martin and Gaby. Forwarding 676or not is visible behavior to the client and it would be useful for the client 677to know which behavior it could depend on. 678]</i></p> 679 680<hr> 681<a name="233"><h3>233. Insertion hints in associative containers</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Apr 2000</p> 682<p> 683If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator 684into the multimap, then <tt>mm.insert(p, x)</tt> inserts 685<tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as 686to where it should go. Table 69 claims that the execution time is 687amortized constant if the insert winds up taking place adjacent to 688<tt>p</tt>, but does not say when, if ever, this is guaranteed to 689happen. All it says it that <tt>p</tt> is a hint as to where to 690insert. 691</p> 692<p> 693The question is whether there is any guarantee about the relationship 694between <tt>p</tt> and the insertion point, and, if so, what it 695is. 696</p> 697<p> 698I believe the present state is that there is no guarantee: The user 699can supply <tt>p</tt>, and the implementation is allowed to 700disregard it entirely. 701</p> 702 703<p><b>Additional comments from Nathan:</b><br> 704 705The vote [in Redmond] was on whether to elaborately specify the use of 706the hint, or to require behavior only if the value could be inserted 707adjacent to the hint. I would like to ensure that we have a chance to 708vote for a deterministic treatment: "before, if possible, otherwise 709after, otherwise anywhere appropriate", as an alternative to the 710proposed "before or after, if possible, otherwise [...]". 711</p> 712 713 714<p><b>Proposed resolution:</b></p> 715 716<p>In table 69 "Associative Container Requirements" in 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in the row for <tt>a.insert(p, t)</tt>, 717change</p> 718 719<blockquote> 720iterator p is a hint pointing to where the insert 721should start to search. 722</blockquote> 723 724<p>to</p> 725 726<blockquote> 727insertion adjacent to iterator p is preferred if 728more than one insertion point is valid. 729</blockquote> 730 731<p>and change</p> 732 733<blockquote> 734logarithmic in general, but amortized constant if 735t is inserted right after p. 736</blockquote> 737 738<p>to</p> 739 740<blockquote> 741logarithmic in general, but amortized constant if 742t is inserted adjacent to iterator p. 743</blockquote> 744 745<p><i>[Toronto: there was general agreement that this is a real defect: 746when inserting an element x into a multiset that already contains 747several copies of x, there is no way to know whether the hint will be 748used. The proposed resolution was that the new element should always 749be inserted as close to the hint as possible. So, for example, if 750there is a subsequence of equivalent values, then providing a.begin() 751as the hint means that the new element should be inserted before the 752subsequence even if a.begin() is far away. JC van Winkel supplied 753precise wording for this proposed resolution, and also for an 754alternative resolution in which hints are only used when they are 755adjacent to the insertion point.]</i></p> 756 757<p><i>[Copenhagen: the LWG agreed to the original proposed resolution, 758in which an insertion hint would be used even when it is far from the 759insertion point. This was contingent on seeing a reference 760implementation showing that it is possible to implement this 761requirement without loss of efficiency. John Potter provided such a 762reference implementation.]</i></p> 763 764<p><i>[Redmond: The LWG was reluctant to adopt the proposal that 765emerged from Copenhagen: it seemed excessively complicated, and went 766beyond fixing the defect that we identified in Toronto. PJP provided 767the new wording described in this issue. Nathan agrees that we 768shouldn't adopt the more detailed semantics, and notes: "we know that 769you can do it efficiently enough with a red-black tree, but there are 770other (perhaps better) balanced tree techniques that might differ 771enough to make the detailed semantics hard to satisfy."]</i></p> 772 773<p><i>[Cura�ao: Nathan should give us the alternative wording he 774suggests so the LWG can decide between the two options.]</i></p> 775 776<p><i>[Lillehammer: The LWG previously rejected the more detailed 777 semantics, because it seemed more loike a new feature than like 778 defect fixing. We're now more sympathetic to it, but we (especially 779 Bill) are still worried about performance. N1780 describes a naive 780 algorithm, but it's not clear whether there is a non-naive 781 implementation. Is it possible to implement this as efficently as 782 the current version of insert?]</i></p> 783 784<p><i>[Post Lillehammer: N1780 updated in post meeting mailing with 785feedback from Lillehammer with more information regarding performance. 786]</i></p> 787 788<hr> 789<a name="254"><h3>254. Exception types in clause 19 are constructed from <tt>std::string</tt> 790</h3></a><p><b>Section:</b> 19.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.std.exceptions"> [lib.std.exceptions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Aug 2000</p> 791<p> 792Many of the standard exception types which implementations are 793required to throw are constructed with a const std::string& 794parameter. For example: 795</p> 796 797<pre> 19.1.5 Class out_of_range [lib.out.of.range] 798 namespace std { 799 class out_of_range : public logic_error { 800 public: 801 explicit out_of_range(const string& what_arg); 802 }; 803 } 804 805 1 The class out_of_range defines the type of objects thrown as excep- 806 tions to report an argument value not in its expected range. 807 808 out_of_range(const string& what_arg); 809 810 Effects: 811 Constructs an object of class out_of_range. 812 Postcondition: 813 strcmp(what(), what_arg.c_str()) == 0. 814</pre> 815 816<p> 817There are at least two problems with this: 818</p> 819<ol> 820<li>A program which is low on memory may end up throwing 821std::bad_alloc instead of out_of_range because memory runs out while 822constructing the exception object.</li> 823<li>An obvious implementation which stores a std::string data member 824may end up invoking terminate() during exception unwinding because the 825exception object allocates memory (or rather fails to) as it is being 826copied.</li> 827</ol> 828 829<p> 830There may be no cure for (1) other than changing the interface to 831out_of_range, though one could reasonably argue that (1) is not a 832defect. Personally I don't care that much if out-of-memory is reported 833when I only have 20 bytes left, in the case when out_of_range would 834have been reported. People who use exception-specifications might care 835a lot, though. 836</p> 837 838<p> 839There is a cure for (2), but it isn't completely obvious. I think a 840note for implementors should be made in the standard. Avoiding 841possible termination in this case shouldn't be left up to chance. The 842cure is to use a reference-counted "string" implementation 843in the exception object. I am not necessarily referring to a 844std::string here; any simple reference-counting scheme for a NTBS 845would do. 846</p> 847 848<p><b>Further discussion, in email:</b></p> 849 850<p> 851...I'm not so concerned about (1). After all, a library implementation 852can add const char* constructors as an extension, and users don't 853<i>need</i> to avail themselves of the standard exceptions, though this is 854a lame position to be forced into. FWIW, std::exception and 855std::bad_alloc don't require a temporary basic_string. 856</p> 857 858<p> 859...I don't think the fixed-size buffer is a solution to the problem, 860strictly speaking, because you can't satisfy the postcondition 861<br> 862 <tt> strcmp(what(), what_arg.c_str()) == 0</tt> 863<br> 864For all values of what_arg (i.e. very long values). That means that 865the only truly conforming solution requires a dynamic allocation. 866</p> 867 868<p><b>Further discussion, from Redmond:</b></p> 869 870<p>The most important progress we made at the Redmond meeting was 871realizing that there are two separable issues here: the const 872string& constructor, and the copy constructor. If a user writes 873something like <tt>throw std::out_of_range("foo")</tt>, the const 874string& constructor is invoked before anything gets thrown. The 875copy constructor is potentially invoked during stack unwinding.</p> 876 877<p>The copy constructor is a more serious problem, becuase failure 878during stack unwinding invokes <tt>terminate</tt>. The copy 879constructor must be nothrow. <i>Cura�ao: Howard thinks this 880requirement may already be present.</i></p> 881 882<p>The fundamental problem is that it's difficult to get the nothrow 883requirement to work well with the requirement that the exception 884objects store a string of unbounded size, particularly if you also try 885to make the const string& constructor nothrow. Options discussed 886include:</p> 887 888<ul> 889<li>Limit the size of a string that exception objects are required to 890throw: change the postconditions of 19.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.domain.error"> [lib.domain.error]</a> paragraph 3 891and 19.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.runtime.error"> [lib.runtime.error]</a> paragraph 3 to something like this: 892"strncmp(what(), what_arg._str(), N) == 0, where N is an 893implementation defined constant no smaller than 256".</li> 894<li>Allow the const string& constructor to throw, but not the 895copy constructor. It's the implementor's responsibility to get it 896right. (An implementor might use a simple refcount class.)</li> 897<li>Compromise between the two: an implementation is not allowed to 898throw if the string's length is less than some N, but, if it doesn't 899throw, the string must compare equal to the argument.</li> 900<li>Add a new constructor that takes a const char*</li> 901</ul> 902 903<p>(Not all of these options are mutually exclusive.)</p> 904 905<p><b>Proposed resolution:</b></p> 906<p><b>Rationale:</b></p> 907 908<p>Throwing a bad_alloc while trying to construct a message for another 909exception-derived class is not necessarily a bad thing. And the 910bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p> 911 912<p><b>Future:</b></p> 913 914<p>All involved would like to see const char* constructors added, but 915this should probably be done for C++0X as opposed to a DR.</p> 916 917<p>I believe the no throw specs currently decorating these functions 918could be improved by some kind of static no throw spec checking 919mechanism (in a future C++ language). As they stand, the copy 920constructors might fail via a call to unexpected. I think what is 921intended here is that the copy constructors can't fail.</p> 922 923<p><i>[Pre-Sydney: reopened at the request of Howard Hinnant. 924 Post-Redmond: James Kanze noticed that the copy constructors of 925 exception-derived classes do not have nothrow clauses. Those 926 classes have no copy constructors declared, meaning the 927 compiler-generated implicit copy constructors are used, and those 928 compiler-generated constructors might in principle throw anything.]</i></p> 929 930<hr> 931<a name="255"><h3>255. Why do <tt>basic_streambuf<>::pbump()</tt> and <tt>gbump()</tt> take an int?</h3></a><p><b>Section:</b> 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Aug 2000</p> 932<p> 933The basic_streambuf members gbump() and pbump() are specified to take an 934int argument. This requirement prevents the functions from effectively 935manipulating buffers larger than std::numeric_limits<int>::max() 936characters. It also makes the common use case for these functions 937somewhat difficult as many compilers will issue a warning when an 938argument of type larger than int (such as ptrdiff_t on LLP64 939architectures) is passed to either of the function. Since it's often the 940result of the subtraction of two pointers that is passed to the 941functions, a cast is necessary to silence such warnings. Finally, the 942usage of a native type in the functions signatures is inconsistent with 943other member functions (such as sgetn() and sputn()) that manipulate the 944underlying character buffer. Those functions take a streamsize argument. 945</p> 946<p><b>Proposed resolution:</b></p> 947<p> 948Change the signatures of these functions in the synopsis of template 949class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4 950and 27.5.2.3.2, p4) to take a streamsize argument. 951</p> 952 953<p> 954Although this change has the potential of changing the ABI of the 955library, the change will affect only platforms where int is different 956than the definition of streamsize. However, since both functions are 957typically inline (they are on all known implementations), even on such 958platforms the change will not affect any user code unless it explicitly 959relies on the existing type of the functions (e.g., by taking their 960address). Such a possibility is IMO quite remote. 961</p> 962 963<p> 964Alternate Suggestion from Howard Hinnant, c++std-lib-7780: 965</p> 966 967<p> 968This is something of a nit, but I'm wondering if streamoff wouldn't be a 969better choice than streamsize. The argument to pbump and gbump MUST be 970signed. But the standard has this to say about streamsize 971(27.4.1/2/Footnote): 972</p> 973 974<blockquote> 975 [Footnote: streamsize is used in most places where ISO C would use 976 size_t. Most of the uses of streamsize could use size_t, except for 977 the strstreambuf constructors, which require negative values. It 978 should probably be the signed type corresponding to size_t (which is 979 what Posix.2 calls ssize_t). --- end footnote] 980</blockquote> 981 982<p> 983This seems a little weak for the argument to pbump and gbump. Should we 984ever really get rid of strstream, this footnote might go with it, along 985with the reason to make streamsize signed. 986</p> 987<p><b>Rationale:</b></p> 988<p>The LWG believes this change is too big for now. We may wish to 989reconsider this for a future revision of the standard. One 990possibility is overloading pbump, rather than changing the 991signature.</p> 992<p><i>[ 993[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)] 994]</i></p> 995<hr> 996<a name="258"><h3>258. Missing allocator requirement</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Aug 2000</p> 997<p> 998From lib-7752: 999</p> 1000 1001<p> 1002I've been assuming (and probably everyone else has been assuming) that 1003allocator instances have a particular property, and I don't think that 1004property can be deduced from anything in Table 32. 1005</p> 1006 1007<p> 1008I think we have to assume that allocator type conversion is a 1009homomorphism. That is, if x1 and x2 are of type X, where 1010X::value_type is T, and if type Y is X::template 1011rebind<U>::other, then Y(x1) == Y(x2) if and only if x1 == x2. 1012</p> 1013 1014<p> 1015Further discussion: Howard Hinnant writes, in lib-7757: 1016</p> 1017 1018<p> 1019I think I can prove that this is not provable by Table 32. And I agree 1020it needs to be true except for the "and only if". If x1 != x2, I see no 1021reason why it can't be true that Y(x1) == Y(x2). Admittedly I can't 1022think of a practical instance where this would happen, or be valuable. 1023But I also don't see a need to add that extra restriction. I think we 1024only need: 1025</p> 1026 1027<blockquote> 1028 if (x1 == x2) then Y(x1) == Y(x2) 1029</blockquote> 1030 1031<p> 1032If we decide that == on allocators is transitive, then I think I can 1033prove the above. But I don't think == is necessarily transitive on 1034allocators. That is: 1035</p> 1036 1037<p> 1038Given x1 == x2 and x2 == x3, this does not mean x1 == x3. 1039</p> 1040 1041<p>Example:</p> 1042 1043<blockquote> 1044<p> 1045x1 can deallocate pointers from: x1, x2, x3 <br> 1046x2 can deallocate pointers from: x1, x2, x4 <br> 1047x3 can deallocate pointers from: x1, x3 <br> 1048x4 can deallocate pointers from: x2, x4 1049</p> 1050 1051<p> 1052x1 == x2, and x2 == x4, but x1 != x4 1053</p> 1054</blockquote> 1055<p><b>Proposed resolution:</b></p> 1056 1057<p><i>[Toronto: LWG members offered multiple opinions. One 1058opinion is that it should not be required that <tt>x1 == x2</tt> 1059implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be 1060required that <tt>X(x1) == x1</tt>. Another opinion is that 1061the second line from the bottom in table 32 already implies the 1062desired property. This issue should be considered in light of 1063other issues related to allocator instances.]</i></p> 1064<hr> 1065<a name="290"><h3>290. Requirements to for_each and its function object</h3></a><p><b>Section:</b> 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 03 Jan 2001</p> 1066<p>The specification of the for_each algorithm does not have a 1067"Requires" section, which means that there are no 1068restrictions imposed on the function object whatsoever. In essence it 1069means that I can provide any function object with arbitrary side 1070effects and I can still expect a predictable result. In particular I 1071can expect that the function object is applied exactly last - first 1072times, which is promised in the "Complexity" section. 1073</p> 1074 1075<p>I don't see how any implementation can give such a guarantee 1076without imposing requirements on the function object. 1077</p> 1078 1079<p>Just as an example: consider a function object that removes 1080elements from the input sequence. In that case, what does the 1081complexity guarantee (applies f exactly last - first times) mean? 1082</p> 1083 1084<p>One can argue that this is obviously a nonsensical application and 1085a theoretical case, which unfortunately it isn't. I have seen 1086programmers shooting themselves in the foot this way, and they did not 1087understand that there are restrictions even if the description of the 1088algorithm does not say so. 1089</p> 1090<p><b>Proposed resolution:</b></p> 1091<p><i>[Lillehammer: This is more general than for_each. We don't want 1092 the function object in transform invalidiating iterators 1093 either. There should be a note somewhere in clause 17 (17, not 25) 1094 saying that user code operating on a range may not invalidate 1095 iterators unless otherwise specified. Bill will provide wording.]</i></p> 1096 1097<hr> 1098<a name="299"><h3>299. Incorrect return types for iterator dereference</h3></a><p><b>Section:</b> 24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> John Potter <b>Date:</b> 22 Jan 2001</p> 1099<p> 1100In section 24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 1101Table 75 gives the return type of *r-- as convertible to T. This is 1102not consistent with Table 74 which gives the return type of *r++ as 1103T&. *r++ = t is valid while *r-- = t is invalid. 1104</p> 1105 1106<p> 1107In section 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>, 1108Table 76 gives the return type of a[n] as convertible to T. This is 1109not consistent with the semantics of *(a + n) which returns T& by 1110Table 74. *(a + n) = t is valid while a[n] = t is invalid. 1111</p> 1112 1113<p> 1114Discussion from the Copenhagen meeting: the first part is 1115uncontroversial. The second part, operator[] for Random Access 1116Iterators, requires more thought. There are reasonable arguments on 1117both sides. Return by value from operator[] enables some potentially 1118useful iterators, e.g. a random access "iota iterator" (a.k.a 1119"counting iterator" or "int iterator"). There isn't any obvious way 1120to do this with return-by-reference, since the reference would be to a 1121temporary. On the other hand, <tt>reverse_iterator</tt> takes an 1122arbitrary Random Access Iterator as template argument, and its 1123operator[] returns by reference. If we decided that the return type 1124in Table 76 was correct, we would have to change 1125<tt>reverse_iterator</tt>. This change would probably affect user 1126code. 1127</p> 1128 1129<p> 1130History: the contradiction between <tt>reverse_iterator</tt> and the 1131Random Access Iterator requirements has been present from an early 1132stage. In both the STL proposal adopted by the committee 1133(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by 1134Stepanov and Lee), the Random Access Iterator requirements say that 1135operator[]'s return value is "convertible to T". In N0527 1136reverse_iterator's operator[] returns by value, but in HPL-95-11 1137(R.1), and in the STL implementation that HP released to the public, 1138reverse_iterator's operator[] returns by reference. In 1995, the 1139standard was amended to reflect the contents of HPL-95-11 (R.1). The 1140original intent for operator[] is unclear. 1141</p> 1142 1143<p> 1144In the long term it may be desirable to add more fine-grained 1145iterator requirements, so that access method and traversal strategy 1146can be decoupled. (See "Improved Iterator Categories and 1147Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions 1148about issue 299 should keep this possibility in mind. 1149</p> 1150 1151<p>Further discussion: I propose a compromise between John Potter's 1152resolution, which requires <tt>T&</tt> as the return type of 1153<tt>a[n]</tt>, and the current wording, which requires convertible to 1154<tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt> 1155for the return type of the expression <tt>a[n]</tt>, but to also add 1156<tt>a[n] = t</tt> as a valid expression. This compromise "saves" the 1157common case uses of random access iterators, while at the same time 1158allowing iterators such as counting iterator and caching file 1159iterators to remain random access iterators (iterators where the 1160lifetime of the object returned by <tt>operator*()</tt> is tied to the 1161lifetime of the iterator). 1162</p> 1163 1164<p> 1165Note that the compromise resolution necessitates a change to 1166<tt>reverse_iterator</tt>. It would need to use a proxy to support 1167<tt>a[n] = t</tt>. 1168</p> 1169 1170<p> 1171Note also there is one kind of mutable random access iterator that 1172will no longer meet the new requirements. Currently, iterators that 1173return an r-value from <tt>operator[]</tt> meet the requirements for a 1174mutable random access iterartor, even though the expression <tt>a[n] = 1175t</tt> will only modify a temporary that goes away. With this proposed 1176resolution, <tt>a[n] = t</tt> will be required to have the same 1177operational semantics as <tt>*(a + n) = t</tt>. 1178</p> 1179 1180<p><b>Proposed resolution:</b></p> 1181 1182<p> 1183In section 24.1.4 [lib.bidirectdional.iterators], change the return 1184type in table 75 from "convertible to <tt>T</tt>" to 1185<tt>T&</tt>. 1186</p> 1187 1188<p> 1189In section 24.1.5 [lib.random.access.iterators], change the 1190operational semantics for <tt>a[n]</tt> to " the r-value of 1191<tt>a[n]</tt> is equivalent to the r-value of <tt>*(a + 1192n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt> 1193with a return type of convertible to <tt>T</tt> and operational semantics of 1194<tt>*(a + n) = t</tt>. 1195</p> 1196 1197<p><i>[Lillehammer: Real problem, but should be addressed as part of 1198 iterator redesign]</i></p> 1199 1200<hr> 1201<a name="309"><h3>309. Does sentry catch exceptions?</h3></a><p><b>Section:</b> 27.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 19 Mar 2001</p> 1202<p> 1203The descriptions of the constructors of basic_istream<>::sentry 1204(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>) and basic_ostream<>::sentry 1205(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>) do not explain what the functions do in 1206case an exception is thrown while they execute. Some current 1207implementations allow all exceptions to propagate, others catch them 1208and set ios_base::badbit instead, still others catch some but let 1209others propagate. 1210</p> 1211 1212<p> 1213The text also mentions that the functions may call setstate(failbit) 1214(without actually saying on what object, but presumably the stream 1215argument is meant). That may have been fine for 1216basic_istream<>::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since 1217the function performs an input operation which may fail. However, 1218issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 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>, p2 to 1219clarify that the function should actually call setstate(failbit | 1220eofbit), so the sentence in p3 is redundant or even somewhat 1221contradictory. 1222</p> 1223 1224<p> 1225The same sentence that appears in 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>, p3 1226doesn't seem to be very meaningful for basic_istream<>::sentry 1227which performs no input. It is actually rather misleading since it 1228would appear to guide library implementers to calling 1229setstate(failbit) when os.tie()->flush(), the only called function, 1230throws an exception (typically, it's badbit that's set in response to 1231such an event). 1232</p> 1233 1234<p><b>Additional comments from Martin, who isn't comfortable with the 1235 current proposed resolution</b> (see c++std-lib-11530)</p> 1236 1237<p> 1238The istream::sentry ctor says nothing about how the function 1239deals with exemptions (27.6.1.1.2, p1 says that the class is 1240responsible for doing "exception safe"(*) prefix and suffix 1241operations but it doesn't explain what level of exception 1242safety the class promises to provide). The mockup example 1243of a "typical implementation of the sentry ctor" given in 124427.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show 1245exception handling, either. Since the ctor is not classified 1246as a formatted or unformatted input function, the text in 124727.6.1.1, p1 through p4 does not apply. All this would seem 1248to suggest that the sentry ctor should not catch or in any 1249way handle exceptions thrown from any functions it may call. 1250Thus, the typical implementation of an istream extractor may 1251look something like [1]. 1252</p> 1253 1254<p> 1255The problem with [1] is that while it correctly sets ios::badbit 1256if an exception is thrown from one of the functions called from 1257the sentry ctor, if the sentry ctor reaches EOF while extracting 1258whitespace from a stream that has eofbit or failbit set in 1259exceptions(), it will cause an ios::failure to be thrown, which 1260will in turn cause the extractor to set ios::badbit. 1261</p> 1262 1263<p> 1264The only straightforward way to prevent this behavior is to 1265move the definition of the sentry object in the extractor 1266above the try block (as suggested by the example in 22.2.8, 1267p9 and also indirectly supported by 27.6.1.3, p1). See [2]. 1268But such an implementation will allow exceptions thrown from 1269functions called from the ctor to freely propagate to the 1270caller regardless of the setting of ios::badbit in the stream 1271object's exceptions(). 1272</p> 1273 1274<p> 1275So since neither [1] nor [2] behaves as expected, the only 1276possible solution is to have the sentry ctor catch exceptions 1277thrown from called functions, set badbit, and propagate those 1278exceptions if badbit is also set in exceptions(). (Another 1279solution exists that deals with both kinds of sentries, but 1280the code is non-obvious and cumbersome -- see [3].) 1281</p> 1282 1283<p> 1284Please note that, as the issue points out, current libraries 1285do not behave consistently, suggesting that implementors are 1286not quite clear on the exception handling in istream::sentry, 1287despite the fact that some LWG members might feel otherwise. 1288(As documented by the parenthetical comment here: 1289http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309) 1290</p> 1291 1292<p> 1293Also please note that those LWG members who in Copenhagen 1294felt that "a sentry's constructor should not catch exceptions, 1295because sentries should only be used within (un)formatted input 1296functions and that exception handling is the responsibility of 1297those functions, not of the sentries," as noted here 1298http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309 1299would in effect be either arguing for the behavior described 1300in [1] or for extractors implemented along the lines of [3]. 1301</p> 1302 1303<p> 1304The original proposed resolution (Revision 25 of the issues 1305list) clarifies the role of the sentry ctor WRT exception 1306handling by making it clear that extractors (both library 1307or user-defined) should be implemented along the lines of 1308[2] (as opposed to [1]) and that no exception thrown from 1309the callees should propagate out of either function unless 1310badbit is also set in exceptions(). 1311</p> 1312 1313 1314<p>[1] Extractor that catches exceptions thrown from sentry:</p> 1315 1316<blockquote> 1317<pre>struct S { long i; }; 1318 1319istream& operator>> (istream &strm, S &s) 1320{ 1321 ios::iostate err = ios::goodbit; 1322 try { 1323 const istream::sentry guard (strm, false); 1324 if (guard) { 1325 use_facet<num_get<char> >(strm.getloc ()) 1326 .get (istreambuf_iterator<char>(strm), 1327 istreambuf_iterator<char>(), 1328 strm, err, s.i); 1329 } 1330 } 1331 catch (...) { 1332 bool rethrow; 1333 try { 1334 strm.setstate (ios::badbit); 1335 rethrow = false; 1336 } 1337 catch (...) { 1338 rethrow = true; 1339 } 1340 if (rethrow) 1341 throw; 1342 } 1343 if (err) 1344 strm.setstate (err); 1345 return strm; 1346} 1347</pre> 1348</blockquote> 1349 1350<p>[2] Extractor that propagates exceptions thrown from sentry:</p> 1351 1352<blockquote> 1353<pre>istream& operator>> (istream &strm, S &s) 1354{ 1355 istream::sentry guard (strm, false); 1356 if (guard) { 1357 ios::iostate err = ios::goodbit; 1358 try { 1359 use_facet<num_get<char> >(strm.getloc ()) 1360 .get (istreambuf_iterator<char>(strm), 1361 istreambuf_iterator<char>(), 1362 strm, err, s.i); 1363 } 1364 catch (...) { 1365 bool rethrow; 1366 try { 1367 strm.setstate (ios::badbit); 1368 rethrow = false; 1369 } 1370 catch (...) { 1371 rethrow = true; 1372 } 1373 if (rethrow) 1374 throw; 1375 } 1376 if (err) 1377 strm.setstate (err); 1378 } 1379 return strm; 1380} 1381</pre> 1382</blockquote> 1383 1384<p> 1385[3] Extractor that catches exceptions thrown from sentry 1386but doesn't set badbit if the exception was thrown as a 1387result of a call to strm.clear(). 1388</p> 1389 1390<blockquote> 1391<pre>istream& operator>> (istream &strm, S &s) 1392{ 1393 const ios::iostate state = strm.rdstate (); 1394 const ios::iostate except = strm.exceptions (); 1395 ios::iostate err = std::ios::goodbit; 1396 bool thrown = true; 1397 try { 1398 const istream::sentry guard (strm, false); 1399 thrown = false; 1400 if (guard) { 1401 use_facet<num_get<char> >(strm.getloc ()) 1402 .get (istreambuf_iterator<char>(strm), 1403 istreambuf_iterator<char>(), 1404 strm, err, s.i); 1405 } 1406 } 1407 catch (...) { 1408 if (thrown && state & except) 1409 throw; 1410 try { 1411 strm.setstate (ios::badbit); 1412 thrown = false; 1413 } 1414 catch (...) { 1415 thrown = true; 1416 } 1417 if (thrown) 1418 throw; 1419 } 1420 if (err) 1421 strm.setstate (err); 1422 1423 return strm; 1424} 1425</pre> 1426</blockquote> 1427 1428<p> 1429[Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage. 1430</p> 1431 1432<p> 1433[Pre-Portland] A relevant newsgroup post: 1434</p> 1435 1436<p> 1437The current proposed resolution of issue #309 1438(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is 1439unacceptable. I write commerical software and coding around this 1440makes my code ugly, non-intuitive, and requires comments referring 1441people to this very issue. Following is the full explanation of my 1442experience. 1443</p> 1444<p> 1445In the course of writing software for commercial use, I constructed 1446std::ifstream's based on user-supplied pathnames on typical POSIX 1447systems. 1448</p> 1449<p> 1450It was expected that some files that opened successfully might not read 1451successfully -- such as a pathname which actually refered to a 1452directory. Intuitively, I expected the streambuffer underflow() code 1453to throw an exception in this situation, and recent implementations of 1454libstdc++'s basic_filebuf do just that (as well as many of my own 1455custom streambufs). 1456</p> 1457<p> 1458I also intuitively expected that the istream code would convert these 1459exceptions to the "badbit' set on the stream object, because I had not 1460requested exceptions. I refer to 27.6.1.1. P4. 1461</p> 1462<p> 1463However, this was not the case on at least two implementations -- if 1464the first thing I did with an istream was call operator>>( T& ) for T 1465among the basic arithmetic types and std::string. Looking further I 1466found that the sentry's constructor was invoking the exception when it 1467pre-scanned for whitespace, and the extractor function (operator>>()) 1468was not catching exceptions in this situation. 1469</p> 1470<p> 1471So, I was in a situation where setting 'noskipws' would change the 1472istream's behavior even though no characters (whitespace or not) could 1473ever be successfully read. 1474</p> 1475<p> 1476Also, calling .peek() on the istream before calling the extractor() 1477changed the behavior (.peek() had the effect of setting the badbit 1478ahead of time). 1479</p> 1480<p> 1481I found this all to be so inconsistent and inconvenient for me and my 1482code design, that I filed a bugzilla entry for libstdc++. I was then 1483told that the bug cannot be fixed until issue #309 is resolved by the 1484committee. 1485</p> 1486 1487<p><b>Proposed resolution:</b></p> 1488<p><b>Rationale:</b></p> 1489<p>The LWG agrees there is minor variation between implementations, 1490 but believes that it doesn't matter. This is a rarely used corner 1491 case. There is no evidence that this has any commercial importance 1492 or that it causes actual portability problems for customers trying 1493 to write code that runs on multiple implementations.</p> 1494<hr> 1495<a name="342"><h3>342. seek and eofbit</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 09 Oct 2001</p> 1496<p>I think we have a defect.</p> 1497 1498<p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the 1499description of seekg 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 38 now looks 1500like:</p> 1501 1502<blockquote> 1503Behaves as an unformatted input function (as described in 27.6.1.3, 1504paragraph 1), except that it does not count the number of characters 1505extracted and does not affect the value returned by subsequent calls to 1506gcount(). After constructing a sentry object, if fail() != true, 1507executes rdbuf()�>pubseekpos( pos). 1508</blockquote> 1509 1510<p>And according to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> which is also now a dr, 151127.6.1.3, paragraph 1 looks like:</p> 1512 1513<blockquote> 1514Each unformatted input function begins execution by constructing an 1515object of class sentry with the default argument noskipws (second) 1516argument true. If the sentry object returns true, when converted to a 1517value of type bool, the function endeavors to obtain the requested 1518input. Otherwise, if the sentry constructor exits by throwing an 1519exception or if the sentry object returns false, when converted to a 1520value of type bool, the function returns without attempting to obtain 1521any input. In either case the number of extracted characters is set to 15220; unformatted input functions taking a character array of non-zero 1523size as an argument shall also store a null character (using charT()) 1524in the first location of the array. If an exception is thrown during 1525input then ios::badbit is turned on in *this'ss error state. If 1526(exception()&badbit)!= 0 then the exception is rethrown. It also counts 1527the number of characters extracted. If no exception has been thrown it 1528ends by storing the count in a member object and returning the value 1529specified. In any event the sentry object is destroyed before leaving 1530the unformatted input function. 1531</blockquote> 1532 1533<p>And finally 27.6.1.1.2/5 says this about sentry:</p> 1534 1535<blockquote> 1536If, after any preparation is completed, is.good() is true, ok_ != false 1537otherwise, ok_ == false. 1538</blockquote> 1539 1540<p> 1541So although the seekg paragraph says that the operation proceeds if 1542!fail(), the behavior of unformatted functions says the operation 1543proceeds only if good(). The two statements are contradictory when only 1544eofbit is set. I don't think the current text is clear which condition 1545should be respected. 1546</p> 1547 1548<p><b>Further discussion from Redmond:</b></p> 1549 1550<p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is 1551"unformatted". That makes specific claims about sentry that 1552aren't quite appropriate for seeking, which has less fragile failure 1553modes than actual input. If we do really mean that it's unformatted 1554input, it should behave the same way as other unformatted input. On 1555the other hand, "principle of least surprise" is that seeking from EOF 1556ought to be OK.</p> 1557 1558<p> 1559Pre-Berlin: Paolo points out several problems with the proposed resolution in 1560Ready state: 1561</p> 1562 1563<ul> 1564<li>It should apply to both overloads of seekg.</li> 1565<li>tellg has similar issues, except that it should not call clear().</li> 1566<li>The point about clear() seems to apply to seekp().</li> 1567<li>Depending on the outcome of 1568<a href="file:///Volumes/Data/lwg/lwg-active.html#419">419</a> if the sentry 1569sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then 1570you can never seek away from the end of stream.</li> 1571</ul> 1572 1573<p><b>Proposed resolution:</b></p> 1574 1575<p>Change 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> to:</p> 1576<blockquote> 1577Behaves as an unformatted input function (as described in 27.6.1.3, 1578paragraph 1), except that it does not count the number of characters 1579extracted, does not affect the value returned by subsequent calls to 1580gcount(), and does not examine the value returned by the sentry 1581object. After constructing a sentry object, if <tt>fail() != 1582true</tt>, executes <tt>rdbuf()->pubseekpos(pos)</tt>. In 1583case of success, the function calls clear(). 1584In case of failure, the function calls <tt>setstate(failbit)</tt> 1585(which may throw <tt>ios_base::failure</tt>). 1586</blockquote> 1587 1588<p><i>[Lillehammer: Matt provided wording.]</i></p> 1589 1590<p><b>Rationale:</b></p> 1591<p>In C, fseek does clear EOF. This is probably what most users would 1592 expect. We agree that having eofbit set should not deter a seek, 1593 and that a successful seek should clear eofbit. Note 1594 that <tt>fail()</tt> is true only if <tt>failbit</tt> 1595 or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather 1596 than <tt>good()</tt>, satisfies this goal.</p> 1597<hr> 1598<a name="382"><h3>382. codecvt do_in/out result</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 30 Aug 2002</p> 1599<p> 1600It seems that the descriptions of codecvt do_in() and do_out() leave 1601sufficient room for interpretation so that two implementations of 1602codecvt may not work correctly with the same filebuf. Specifically, 1603the following seems less than adequately specified: 1604</p> 1605 1606<ol> 1607<li> 1608 the conditions under which the functions terminate 1609</li> 1610<li> 1611 precisely when the functions return ok 1612</li> 1613<li> 1614 precisely when the functions return partial 1615</li> 1616<li> 1617 the full set of conditions when the functions return error 1618</li> 1619</ol> 1620 1621<ol> 1622<li> 1623 <font color="red">22.2.1.5.2</font>, p2 says this about the effects of the 1624 function: ...Stops if it encounters a character it cannot 1625 convert... This assumes that there *is* a character to 1626 convert. What happens when there is a sequence that doesn't form a 1627 valid source character, such as an unassigned or invalid UNICODE 1628 character, or a sequence that cannot possibly form a character 1629 (e.g., the sequence "\xc0\xff" in UTF-8)? 1630</li> 1631<li> 1632 Table 53 says that the function returns codecvt_base::ok 1633 to indicate that the function(s) "completed the conversion." 1634 Suppose that the source sequence is "\xc0\x80" in UTF-8, 1635 with from pointing to '\xc0' and (from_end==from + 1). 1636 It is not clear whether the return value should be ok 1637 or partial (see below). 1638</li> 1639<li> 1640 Table 53 says that the function returns codecvt_base::partial 1641 if "not all source characters converted." With the from pointers 1642 set up the same way as above, it is not clear whether the return 1643 value should be partial or ok (see above). 1644</li> 1645<li> 1646 Table 53, in the row describing the meaning of error mistakenly 1647 refers to a "from_type" character, without the symbol from_type 1648 having been defined. Most likely, the word "source" character 1649 is intended, although that is not sufficient. The functions 1650 may also fail when they encounter an invalid source sequence 1651 that cannot possibly form a valid source character (e.g., as 1652 explained in bullet 1 above). 1653</li> 1654</ol> 1655<p> 1656Finally, the conditions described at the end of <font color="red">22.2.1.5.2</font>, p4 don't seem to be possible: 1657</p> 1658<blockquote> 1659 "A return value of partial, if (from_next == from_end), 1660 indicates that either the destination sequence has not 1661 absorbed all the available destination elements, or that 1662 additional source elements are needed before another 1663 destination element can be produced." 1664</blockquote> 1665<p> 1666If the value is partial, it's not clear to me that (from_next 1667==from_end) could ever hold if there isn't enough room 1668in the destination buffer. In order for (from_next==from_end) to 1669hold, all characters in that range must have been successfully 1670converted (according to <font color="red">22.2.1.5.2</font>, p2) and since there are no 1671further source characters to convert, no more room in the 1672destination buffer can be needed. 1673</p> 1674<p> 1675It's also not clear to me that (from_next==from_end) could ever 1676hold if additional source elements are needed to produce another 1677destination character (not element as incorrectly stated in the 1678text). partial is returned if "not all source characters have 1679been converted" according to Table 53, which also implies that 1680(from_next==from) does NOT hold. 1681</p> 1682<p> 1683Could it be that the intended qualifying condition was actually 1684(from_next != from_end), i.e., that the sentence was supposed 1685to read 1686</p> 1687<blockquote> 1688 "A return value of partial, if (from_next != from_end),..." 1689</blockquote> 1690<p> 1691which would make perfect sense, since, as far as I understand it, 1692partial can only occur if (from_next != from_end)? 1693</p> 1694<p><b>Proposed resolution:</b></p> 1695 1696<p><i>[Lillehammer: Defer for the moment, but this really needs to be 1697 fixed. Right now, the description of codecvt is too vague for it to 1698 be a useful contract between providers and clients of codecvt 1699 facets. (Note that both vendors and users can be both providers and 1700 clients of codecvt facets.) The major philosophical issue is whether 1701 the standard should only describe mappings that take a single wide 1702 character to multiple narrow characters (and vice versa), or whether 1703 it should describe fully general N-to-M conversions. When the 1704 original standard was written only the former was contemplated, but 1705 today, in light of the popularity of utf8 and utf16, that doesn't 1706 seem sufficient for C++0x. Bill supports general N-to-M conversions; 1707 we need to make sure Martin and Howard agree.]</i></p> 1708 1709<hr> 1710<a name="385"><h3>385. Does call by value imply the CopyConstructible requirement?</h3></a><p><b>Section:</b> 17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Oct 2002</p> 1711<p> 1712Many function templates have parameters that are passed by value; 1713a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in 171425.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a>. Are the corresponding template parameters 1715(<tt>Predicate</tt> in this case) implicitly required to be 1716CopyConstructible, or does that need to be spelled out explicitly? 1717</p> 1718 1719<p> 1720This isn't quite as silly a question as it might seem to be at first 1721sight. If you call <tt>find_if</tt> in such a way that template 1722argument deduction applies, then of course you'll get call by value 1723and you need to provide a copy constructor. If you explicitly provide 1724the template arguments, however, you can force call by reference by 1725writing something like <tt>find_if<my_iterator, 1726my_predicate&></tt>. The question is whether implementation 1727are required to accept this, or whether this is ill-formed because 1728my_predicate& is not CopyConstructible. 1729</p> 1730 1731<p> 1732The scope of this problem, if it is a problem, is unknown. Function 1733object arguments to generic algorithms in clauses 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> 1734and 26 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numerics"> [lib.numerics]</a> are obvious examples. A review of the whole 1735library is necessary. 1736</p> 1737<p><b>Proposed resolution:</b></p> 1738<p><i>[ 1739This is really two issues. First, predicates are typically passed by 1740value but we don't say they must be Copy Constructible. They should 1741be. Second: is specialization allowed to transform value arguments 1742into references? References aren't copy constructible, so this should 1743not be allowed. 1744]</i></p> 1745<hr> 1746<a name="387"><h3>387. std::complex over-encapsulated</h3></a><p><b>Section:</b> 26.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 8 Nov 2002</p> 1747<p> 1748The absence of explicit description of std::complex<T> layout 1749makes it imposible to reuse existing software developed in traditional 1750languages like Fortran or C with unambigous and commonly accepted 1751layout assumptions. There ought to be a way for practitioners to 1752predict with confidence the layout of std::complex<T> whenever T 1753is a numerical datatype. The absence of ways to access individual 1754parts of a std::complex<T> object as lvalues unduly promotes 1755severe pessimizations. For example, the only way to change, 1756independently, the real and imaginary parts is to write something like 1757</p> 1758 1759<pre>complex<T> z; 1760// ... 1761// set the real part to r 1762z = complex<T>(r, z.imag()); 1763// ... 1764// set the imaginary part to i 1765z = complex<T>(z.real(), i); 1766</pre> 1767 1768<p> 1769At this point, it seems appropriate to recall that a complex number 1770is, in effect, just a pair of numbers with no particular invariant to 1771maintain. Existing practice in numerical computations has it that a 1772complex number datatype is usually represented by Cartesian 1773coordinates. Therefore the over-encapsulation put in the specification 1774of std::complex<> is not justified. 1775</p> 1776 1777<p><b>Proposed resolution:</b></p> 1778<p>Add the following requirements to 26.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> as 26.3/4:</p> 1779<blockquote> 1780<p>If z is an lvalue expression of type cv std::complex<T> then</p> 1781 1782<ul> 1783<li>the expression reinterpret_cast<cv T(&)[2]>(z) 1784is well-formed; and</li> 1785<li>reinterpret_cast<cvT(&)[2]>(z)[0]designates the 1786real part of z; and</li> 1787<li>reinterpret_cast<cvT(&)[2]>(z)[1]designates the 1788imaginary part of z.</li> 1789</ul> 1790 1791<p> 1792Moreover, if a is an expression of pointer type cv complex<T>* 1793and the expression a[i] is well-defined for an integer expression 1794i then: 1795</p> 1796 1797<ul> 1798<li>reinterpret_cast<cvT*>(a)[2+i] designates the real 1799part of a[i]; and</li> 1800<li>reinterpret_cast<cv T*>(a)[2+i+1] designates the 1801imaginary part of a[i].</li> 1802</ul> 1803</blockquote> 1804 1805<p>In the header synopsis 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>, replace</p> 1806<pre> template<class T> T real(const complex<T>&); 1807 template<class T> T imag(const complex<T>&); 1808</pre> 1809 1810<p>with</p> 1811 1812<pre> template<class T> const T& real(const complex<T>&); 1813 template<class T> T& real( complex<T>&); 1814 template<class T> const T& imag(const complex<T>&); 1815 template<class T> T& imag( complex<T>&); 1816</pre> 1817 1818<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> paragraph 1, change</p> 1819<pre> template<class T> T real(const complex<T>&); 1820</pre> 1821<p>to</p> 1822<pre> template<class T> const T& real(const complex<T>&); 1823 template<class T> T& real( complex<T>&); 1824</pre> 1825<p>and change the <b>Returns</b> clause to "<b>Returns:</b> The real 1826part of <i>x</i></p>. 1827 1828<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> paragraph 2, change</p> 1829<pre> template<class T> T imag(const complex<T>&); 1830</pre> 1831<p>to</p> 1832<pre> template<class T> const T& imag(const complex<T>&); 1833 template<class T> T& imag( complex<T>&); 1834</pre> 1835<p>and change the <b>Returns</b> clause to "<b>Returns:</b> The imaginary 1836part of <i>x</i></p>. 1837 1838<p><i>[Kona: The layout guarantee is absolutely necessary for C 1839 compatibility. However, there was disagreement about the other part 1840 of this proposal: retrieving elements of the complex number as 1841 lvalues. An alternative: continue to have real() and imag() return 1842 rvalues, but add set_real() and set_imag(). Straw poll: return 1843 lvalues - 2, add setter functions - 5. Related issue: do we want 1844 reinterpret_cast as the interface for converting a complex to an 1845 array of two reals, or do we want to provide a more explicit way of 1846 doing it? Howard will try to resolve this issue for the next 1847 meeting.]</i></p> 1848 1849<p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p> 1850 1851<p><b>Rationale:</b></p> 1852<p>The LWG believes that C99 compatibility would be enough 1853justification for this change even without other considerations. All 1854existing implementations already have the layout proposed here.</p> 1855<hr> 1856<a name="394"><h3>394. behavior of formatted output on failure</h3></a><p><b>Section:</b> 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Dec 2002</p> 1857<p> 1858There is a contradiction in Formatted output about what bit is 1859supposed to be set if the formatting fails. On sentence says it's 1860badbit and another that it's failbit. 1861</p> 1862<p> 186327.6.2.5.1, p1 says in the Common Requirements on Formatted output 1864functions: 1865</p><pre> ... If the generation fails, then the formatted output function 1866 does setstate(ios::failbit), which might throw an exception. 1867</pre> 1868<p></p> 1869<p> 187027.6.2.5.2, p1 goes on to say this about Arithmetic Inserters: 1871</p> 1872<p> 1873 ... The formatting conversion occurs as if it performed the 1874 following code fragment: 1875</p> 1876<p> 1877</p><pre> bool failed = 1878 use_facet<num_put<charT,ostreambuf_iterator<charT,traits> 1879 > > 1880 (getloc()).put(*this, *this, fill(), val). failed(); 1881 1882 ... If failed is true then does setstate(badbit) ... 1883</pre> 1884<p></p> 1885<p> 1886The original intent of the text, according to Jerry Schwarz (see 1887c++std-lib-10500), is captured in the following paragraph: 1888</p> 1889<p> 1890In general "badbit" should mean that the stream is unusable because 1891of some underlying failure, such as disk full or socket closure; 1892"failbit" should mean that the requested formatting wasn't possible 1893because of some inconsistency such as negative widths. So typically 1894if you clear badbit and try to output something else you'll fail 1895again, but if you clear failbit and try to output something else 1896you'll succeed. 1897</p> 1898<p> 1899In the case of the arithmetic inserters, since num_put cannot 1900report failure by any means other than exceptions (in response 1901to which the stream must set badbit, which prevents the kind of 1902recoverable error reporting mentioned above), the only other 1903detectable failure is if the iterator returned from num_put 1904returns true from failed(). 1905</p> 1906<p> 1907Since that can only happen (at least with the required iostream 1908specializations) under such conditions as the underlying failure 1909referred to above (e.g., disk full), setting badbit would seem 1910to be the appropriate response (indeed, it is required in 191127.6.2.5.2, p1). It follows that failbit can never be directly 1912set by the arithmetic (it can only be set by the sentry object 1913under some unspecified conditions). 1914</p> 1915<p> 1916The situation is different for other formatted output functions 1917which can fail as a result of the streambuf functions failing 1918(they may do so by means other than exceptions), and which are 1919then required to set failbit. 1920</p> 1921<p> 1922The contradiction, then, is that ostream::operator<<(int) will 1923set badbit if the disk is full, while operator<<(ostream&, 1924char) will set failbit under the same conditions. To make the behavior 1925consistent, the Common requirements sections for the Formatted output 1926functions should be changed as proposed below. 1927</p> 1928<p><b>Proposed resolution:</b></p> 1929 1930 1931<p><i>[Kona: There's agreement that this is a real issue. What we 1932 decided at Kona: 1. An error from the buffer (which can be detected 1933 either directly from streambuf's member functions or by examining a 1934 streambuf_iterator) should always result in badbit getting set. 1935 2. There should never be a circumstance where failbit gets set. 1936 That represents a formatting error, and there are no circumstances 1937 under which the output facets are specified as signaling a 1938 formatting error. (Even more so for string output that for numeric 1939 because there's nothing to format.) If we ever decide to make it 1940 possible for formatting errors to exist then the facets can signal 1941 the error directly, and that should go in clause 22, not clause 27. 1942 3. The phrase "if generation fails" is unclear and should be 1943 eliminated. It's not clear whether it's intended to mean a buffer 1944 error (e.g. a full disk), a formatting error, or something else. 1945 Most people thought it was supposed to refer to buffer errors; if 1946 so, we should say so. Martin will provide wording.]</i></p> 1947 1948<p><b>Rationale:</b></p> 1949 1950<hr> 1951<a name="396"><h3>396. what are characters zero and one</h3></a><p><b>Section:</b> 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p> 1952 <p> 195323.3.5.1, p6 [lib.bitset.cons] talks about a generic character 1954having the value of 0 or 1 but there is no definition of what 1955that means for charT other than char and wchar_t. And even for 1956those two types, the values 0 and 1 are not actually what is 1957intended -- the values '0' and '1' are. This, along with the 1958converse problem in the description of to_string() in 23.3.5.2, 1959p33, looks like a defect remotely related to DR 303. 1960 </p> 1961 <p> 1962http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303 1963 </p> 1964 <pre>23.3.5.1: 1965 -6- An element of the constructed string has value zero if the 1966 corresponding character in str, beginning at position pos, 1967 is 0. Otherwise, the element has the value one. 1968 </pre> 1969 <pre>23.3.5.2: 1970 -33- Effects: Constructs a string object of the appropriate 1971 type and initializes it to a string of length N characters. 1972 Each character is determined by the value of its 1973 corresponding bit position in *this. Character position N 1974 ?- 1 corresponds to bit position zero. Subsequent decreasing 1975 character positions correspond to increasing bit positions. 1976 Bit value zero becomes the character 0, bit value one becomes 1977 the character 1. 1978 </pre> 1979 <p> 1980Also note the typo in 23.3.5.1, p6: the object under construction 1981is a bitset, not a string. 1982 </p> 1983 <p><b>Proposed resolution:</b></p> 1984<p>Change the constructor's function declaration immediately before 198523.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> p3 to:</p> 1986<pre> template <class charT, class traits, class Allocator> 1987 explicit 1988 bitset(const basic_string<charT, traits, Allocator>& str, 1989 typename basic_string<charT, traits, Allocator>::size_type pos = 0, 1990 typename basic_string<charT, traits, Allocator>::size_type n = 1991 basic_string<charT, traits, Allocator>::npos, 1992 charT zero = charT('0'), charT one = charT('1')) 1993</pre> 1994<p>Change the first two sentences of 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> p6 to: "An 1995element of the constructed string has value 0 if the corresponding 1996character in <i>str</i>, beginning at position <i>pos</i>, 1997is <i>zero</i>. Otherwise, the element has the value 1.</p> 1998 1999<p>Change the text of the second sentence in 23.3.5.1, p5 to read: 2000 "The function then throws invalid_argument if any of the rlen 2001 characters in str beginning at position pos is other than <i>zero</i> 2002 or <i>one</i>. The function uses traits::eq() to compare the character 2003 values." 2004</p> 2005 2006<p>Change the declaration of the <tt>to_string</tt> member function 2007 immediately before 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> p33 to:</p> 2008<pre> template <class charT, class traits, class Allocator> 2009 basic_string<charT, traits, Allocator> 2010 to_string(charT zero = charT('0'), charT one = charT('1')) const; 2011</pre> 2012<p>Change the last sentence 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> p33 to: "Bit 2013 value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the 2014 character <tt><i>one</i></tt>.</p> 2015<p>Change 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> p8 to:</p> 2016<p><b>Returns</b>:</p> 2017<pre> os << x.template to_string<charT,traits,allocator<charT> >( 2018 use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('0'), 2019 use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('1')); 2020</pre> 2021<p><b>Rationale:</b></p> 2022<p>There is a real problem here: we need the character values of '0' 2023 and '1', and we have no way to get them since strings don't have 2024 imbued locales. In principle the "right" solution would be to 2025 provide an extra object, either a ctype facet or a full locale, 2026 which would be used to widen '0' and '1'. However, there was some 2027 discomfort about using such a heavyweight mechanism. The proposed 2028 resolution allows those users who care about this issue to get it 2029 right.</p> 2030<p>We fix the inserter to use the new arguments. Note that we already 2031 fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p> 2032 2033<hr> 2034<a name="397"><h3>397. ostream::sentry dtor throws exceptions</h3></a><p><b>Section:</b> 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p> 2035 <p> 203617.4.4.8, p3 prohibits library dtors from throwing exceptions. 2037 </p> 2038 <p> 203927.6.2.3, p4 says this about the ostream::sentry dtor: 2040 </p> 2041 <pre> -4- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception()) 2042 is true, calls os.flush(). 2043 </pre> 2044 <p> 204527.6.2.6, p7 that describes ostream::flush() says: 2046 </p> 2047 <pre> -7- If rdbuf() is not a null pointer, calls rdbuf()->pubsync(). 2048 If that function returns ?-1 calls setstate(badbit) (which 2049 may throw ios_base::failure (27.4.4.3)). 2050 </pre> 2051 <p> 2052That seems like a defect, since both pubsync() and setstate() can 2053throw an exception. 2054 </p> 2055 <p><b>Proposed resolution:</b></p> 2056<p><i>[ 2057The contradiction is real. Clause 17 says destructors may never 2058throw exceptions, and clause 27 specifies a destructor that does 2059throw. In principle we might change either one. We're leaning 2060toward changing clause 17: putting in an "unless otherwise specified" 2061clause, and then putting in a footnote saying the sentry destructor 2062is the only one that can throw. PJP suggests specifying that 2063sentry::~sentry() should internally catch any exceptions it might cause. 2064]</i></p> 2065<hr> 2066<a name="398"><h3>398. effects of end-of-file on unformatted input functions</h3></a><p><b>Section:</b> 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p> 2067 <p> 2068While reviewing unformatted input member functions of istream 2069for their behavior when they encounter end-of-file during input 2070I found that the requirements vary, sometimes unexpectedly, and 2071in more than one case even contradict established practice (GNU 2072libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC 20735.38, Rogue Wave libstd 3.1, and Classic Iostreams). 2074 </p> 2075 <p> 2076The following unformatted input member functions set eofbit if they 2077encounter an end-of-file (this is the expected behavior, and also 2078the behavior of all major implementations): 2079 </p> 2080 <p> 2081 </p><pre> basic_istream<charT, traits>& 2082 get (char_type*, streamsize, char_type); 2083 </pre> 2084 <p></p> 2085 <p> 2086 Also sets failbit if it fails to extract any characters. 2087 </p> 2088 <p> 2089 </p><pre> basic_istream<charT, traits>& 2090 get (char_type*, streamsize); 2091 </pre> 2092 <p></p> 2093 <p> 2094 Also sets failbit if it fails to extract any characters. 2095 </p> 2096 <p> 2097 </p><pre> basic_istream<charT, traits>& 2098 getline (char_type*, streamsize, char_type); 2099 </pre> 2100 <p></p> 2101 <p> 2102 Also sets failbit if it fails to extract any characters. 2103 </p> 2104 <p> 2105 </p><pre> basic_istream<charT, traits>& 2106 getline (char_type*, streamsize); 2107 </pre> 2108 <p></p> 2109 <p> 2110 Also sets failbit if it fails to extract any characters. 2111 </p> 2112 <p> 2113 </p><pre> basic_istream<charT, traits>& 2114 ignore (int, int_type); 2115 </pre> 2116 <p></p> 2117 <p> 2118 </p><pre> basic_istream<charT, traits>& 2119 read (char_type*, streamsize); 2120 </pre> 2121 <p></p> 2122 <p> 2123 Also sets failbit if it encounters end-of-file. 2124 </p> 2125 <p> 2126 </p><pre> streamsize readsome (char_type*, streamsize); 2127 </pre> 2128 <p></p> 2129 2130 <p> 2131The following unformated input member functions set failbit but 2132not eofbit if they encounter an end-of-file (I find this odd 2133since the functions make it impossible to distinguish a general 2134failure from a failure due to end-of-file; the requirement is 2135also in conflict with all major implementation which set both 2136eofbit and failbit): 2137 </p> 2138 <p> 2139 </p><pre> int_type get(); 2140 </pre> 2141 <p></p> 2142 <p> 2143 </p><pre> basic_istream<charT, traits>& 2144 get (char_type&); 2145 </pre> 2146 <p></p> 2147 <p> 2148These functions only set failbit of they extract no characters, 2149otherwise they don't set any bits, even on failure (I find this 2150inconsistency quite unexpected; the requirement is also in 2151conflict with all major implementations which set eofbit 2152whenever they encounter end-of-file): 2153 </p> 2154 <p> 2155 </p><pre> basic_istream<charT, traits>& 2156 get (basic_streambuf<charT, traits>&, char_type); 2157 </pre> 2158 <p></p> 2159 <p> 2160 </p><pre> basic_istream<charT, traits>& 2161 get (basic_streambuf<charT, traits>&); 2162 </pre> 2163 <p></p> 2164 <p> 2165This function sets no bits (all implementations except for 2166STLport and Classic Iostreams set eofbit when they encounter 2167end-of-file): 2168 </p> 2169 <p> 2170 </p><pre> int_type peek (); 2171 </pre> 2172 <p></p> 2173 <p><b>Proposed resolution:</b></p> 2174<p>Informally, what we want is a global statement of intent saying 2175 that eofbit gets set if we trip across EOF, and then we can take 2176 away the specific wording for individual functions. A full review 2177 is necessary. The wording currently in the standard is a mishmash, 2178 and changing it on an individual basis wouldn't make things better. 2179 Dietmar will do this work.</p> 2180<hr> 2181<a name="401"><h3>401. incorrect type casts in table 32 in lib.allocator.requirements</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 27 Feb 2003</p> 2182<p> 2183I think that in par2 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> the last two 2184lines of table 32 contain two incorrect type casts. The lines are ... 2185</p> 2186 2187<pre> a.construct(p,t) Effect: new((void*)p) T(t) 2188 a.destroy(p) Effect: ((T*)p)?->~T() 2189</pre> 2190 2191<p> 2192.... with the prerequisits coming from the preceding two paragraphs, especially 2193from table 31: 2194</p> 2195 2196<pre> alloc<T> a ;// an allocator for T 2197 alloc<T>::pointer p ;// random access iterator 2198 // (may be different from T*) 2199 alloc<T>::reference r = *p;// T& 2200 T const& t ; 2201</pre> 2202 2203<p> 2204For that two type casts ("(void*)p" and "(T*)p") to be well-formed 2205this would require then conversions to T* and void* for all 2206alloc<T>::pointer, so it would implicitely introduce extra 2207requirements for alloc<T>::pointer, additionally to the only 2208current requirement (being a random access iterator). 2209</p> 2210<p><b>Proposed resolution:</b></p> 2211<p> 2212"(void*)p" should be replaced with "(void*)&*p" and that 2213"((T*)p)?->" should be replaced with "(*p)." or with 2214"(&*p)->". 2215</p> 2216 2217<p> 2218Note: Actually I would prefer to replace "((T*)p)?->dtor_name" with 2219"p?->dtor_name", but AFAICS this is not possible cause of an omission 2220in 13.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/over.html#over.ref"> [over.ref]</a> (for which I have filed another DR on 29.11.2002). 2221</p> 2222 2223<p><i>[Kona: The LWG thinks this is somewhere on the border between 2224 Open and NAD. The intend is clear: <tt>construct</tt> constructs an 2225 object at the location <i>p</i>. It's reading too much into the 2226 description to think that literally calling <tt>new</tt> is 2227 required. Tweaking this description is low priority until we can do 2228 a thorough review of allocators, and, in particular, allocators with 2229 non-default pointer types.]</i></p> 2230 2231<hr> 2232<a name="408"><h3>408. Is vector<reverse_iterator<char*> > forbidden?</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 3 June 2003</p> 2233<p> 2234I've been discussing iterator semantics with Dave Abrahams, and a 2235surprise has popped up. I don't think this has been discussed before. 2236</p> 2237 2238<p> 223924.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> says that the only operation that can be performed on "singular" 2240iterator values is to assign a non-singular value to them. (It 2241doesn't say they can be destroyed, and that's probably a defect.) 2242Some implementations have taken this to imply that there is no need 2243to initialize the data member of a reverse_iterator<> in the default 2244constructor. As a result, code like 2245</p> 2246<blockquote> 2247 std::vector<std::reverse_iterator<char*> > v(7); 2248 v.reserve(1000); 2249</blockquote> 2250<p> 2251invokes undefined behavior, because it must default-initialize the 2252vector elements, and then copy them to other storage. Of course many 2253other vector operations on these adapters are also left undefined, 2254and which those are is not reliably deducible from the standard. 2255</p> 2256 2257<p> 2258I don't think that 24.1 was meant to make standard-library iterator 2259types unsafe. Rather, it was meant to restrict what operations may 2260be performed by functions which take general user- and standard 2261iterators as arguments, so that raw pointers would qualify as 2262iterators. However, this is not clear in the text, others have come 2263to the opposite conclusion. 2264</p> 2265 2266<p> 2267One question is whether the standard iterator adaptors have defined 2268copy semantics. Another is whether they have defined destructor 2269semantics: is 2270</p> 2271<blockquote> 2272 { std::vector<std::reverse_iterator<char*> > v(7); } 2273</blockquote> 2274<p> 2275undefined too? 2276</p> 2277 2278<p> 2279Note this is not a question of whether algorithms are allowed to 2280rely on copy semantics for arbitrary iterators, just whether the 2281types we actually supply support those operations. I believe the 2282resolution must be expressed in terms of the semantics of the 2283adapter's argument type. It should make clear that, e.g., the 2284reverse_iterator<T> constructor is actually required to execute 2285T(), and so copying is defined if the result of T() is copyable. 2286</p> 2287 2288<p> 2289Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default 2290constructor more precisely, has some relevance to this issue. 2291However, it is not the whole story. 2292</p> 2293 2294<p> 2295The issue was whether 2296</p> 2297<blockquote> 2298 reverse_iterator() { } 2299</blockquote> 2300<p> 2301is allowed, vs. 2302</p> 2303<blockquote> 2304 reverse_iterator() : current() { } 2305</blockquote> 2306 2307<p> 2308The difference is when T is char*, where the first leaves the member 2309uninitialized, and possibly equal to an existing pointer value, or 2310(on some targets) may result in a hardware trap when copied. 2311</p> 2312 2313<p> 23148.5 paragraph 5 seems to make clear that the second is required to 2315satisfy DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, at least for non-class Iterator argument 2316types. 2317</p> 2318 2319<p> 2320But that only takes care of reverse_iterator, and doesn't establish 2321a policy for all iterators. (The reverse iterator adapter was just 2322an example.) In particular, does my function 2323</p> 2324<blockquote> 2325 template <typename Iterator> 2326 void f() { std::vector<Iterator> v(7); } 2327</blockquote> 2328<p> 2329evoke undefined behavior for some conforming iterator definitions? 2330I think it does, now, because vector<> will destroy those singular 2331iterator values, and that's explicitly disallowed. 2332</p> 2333 2334<p> 233524.1 shouldn't give blanket permission to copy all singular iterators, 2336because then pointers wouldn't qualify as iterators. However, it 2337should allow copying of that subset of singular iterator values that 2338are default-initialized, and it should explicitly allow destroying any 2339iterator value, singular or not, default-initialized or not. 2340</p> 2341 2342<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p> 2343<p><b>Proposed resolution:</b></p> 2344 2345<p><i>[ 2346We don't want to require all singular iterators to be copyable, 2347because that is not the case for pointers. However, default 2348construction may be a special case. Issue: is it really default 2349construction we want to talk about, or is it something like value 2350initialization? We need to check with core to see whether default 2351constructed pointers are required to be copyable; if not, it would be 2352wrong to impose so strict a requirement for iterators. 2353]</i></p> 2354 2355<hr> 2356<a name="416"><h3>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3></a><p><b>Section:</b> 18.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.c.limits"> [lib.c.limits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> 2357 <p> 2358 2359Given two overloads of the function foo(), one taking an argument of type 2360int and the other taking a long, which one will the call foo(LONG_MAX) 2361resolve to? The expected answer should be foo(long), but whether that 2362is true depends on the #defintion of the LONG_MAX macro, specifically 2363its type. This issue is about the fact that the type of these macros 2364is not actually required to be the same as the the type each respective 2365limit. 2366<br> 2367 2368Section 18.2.2 of the C++ Standard does not specify the exact types of 2369the XXX_MIN and XXX_MAX macros #defined in the <climits> and <limits.h> 2370headers such as INT_MAX and LONG_MAX and instead defers to the C standard. 2371<br> 2372 2373Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of 2374these constants] shall be replaced by constant expressions suitable for use 2375in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, 2376the following shall be replaced by expressions that have the same type as 2377would an expression that is an object of the corresponding type converted 2378according to the integer promotions." 2379<br> 2380 2381The "corresponding type converted according to the integer promotions" for 2382LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long 2383converted to the first of the following set of types that can represent it: 2384int, long int, long long int. So on an implementation where (sizeof(long) 2385== sizeof(int)) this type is actually int, while on an implementation where 2386(sizeof(long) > sizeof(int)) holds this type will be long. 2387<br> 2388 2389This is not an issue in C since the type of the macro cannot be detected 2390by any conforming C program, but it presents a portability problem in C++ 2391where the actual type is easily detectable by overload resolution. 2392 2393 </p> 2394 <p><b>Proposed resolution:</b></p> 2395 2396<p><i>[Kona: the LWG does not believe this is a defect. The C macro 2397 definitions are what they are; we've got a better 2398 mechanism, <tt>std::numeric_limits</tt>, that is specified more 2399 precisely than the C limit macros. At most we should add a 2400 nonnormative note recommending that users who care about the exact 2401 types of limit quantities should use <limits> instead of 2402 <climits>.]</i></p> 2403 2404<hr> 2405<a name="417"><h3>417. what does ctype::do_widen() return on failure</h3></a><p><b>Section:</b> 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> 2406<p> 2407The Effects and Returns clauses of the do_widen() member function of 2408the ctype facet fail to specify the behavior of the function on failure. 2409That the function may not be able to simply cast the narrow character 2410argument to the type of the result since doing so may yield the wrong value 2411for some wchar_t encodings. Popular implementations of ctype<wchar_t> that 2412use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail 2413when the argument's MSB is set. There is no way for the the rest of locale 2414and iostream to reliably detect this failure. 2415</p> 2416<p><b>Proposed resolution:</b></p> 2417<p><i>[Kona: This is a real problem. Widening can fail. It's unclear 2418 what the solution should be. Returning WEOF works for the wchar_t 2419 specialization, but not in general. One option might be to add a 2420 default, like <i>narrow</i>. But that's an incompatible change. 2421 Using <i>traits::eof</i> might seem like a good idea, but facets 2422 don't have access to traits (a recurring problem). We could 2423 have <i>widen</i> throw an exception, but that's a scary option; 2424 existing library components aren't written with the assumption 2425 that <i>widen</i> can throw.]</i></p> 2426<hr> 2427<a name="418"><h3>418. exceptions thrown during iostream cleanup</h3></a><p><b>Section:</b> 27.4.2.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::Init"> [lib.ios::Init]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> 2428<p> 2429The dtor of the ios_base::Init object is supposed to call flush() on the 24306 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog. 2431This call may cause an exception to be thrown. 2432</p> 2433 2434<p> 243517.4.4.8, p3 prohibits all library destructors from throwing exceptions. 2436</p> 2437 2438<p> 2439The question is: What should this dtor do if one or more of these calls 2440to flush() ends up throwing an exception? This can happen quite easily 2441if one of the facets installed in the locale imbued in the iostream 2442object throws. 2443</p> 2444<p><b>Proposed resolution:</b></p> 2445<p><i>[Kona: We probably can't do much better than what we've got, so 2446 the LWG is leaning toward NAD. At the point where the standard 2447 stream objects are being cleaned up, the usual error reporting 2448 mechanism are all unavailable. And exception from flush at this 2449 point will definitely cause problems. A quality implementation 2450 might reasonably swallow the exception, or call abort, or do 2451 something even more drastic.]</i></p> 2452<hr> 2453<a name="419"><h3>419. istream extractors not setting failbit if eofbit is already set</h3></a><p><b>Section:</b> 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> 2454 <p> 2455 245627.6.1.1.2, p2 says that istream::sentry ctor prepares for input if is.good() 2457is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to 2458true if the stream state is good after any preparation. 27.6.1.2.1, p1 then 2459says that a formatted input function endeavors to obtain the requested input 2460if the sentry's operator bool() returns true. 2461 2462Given these requirements, no formatted extractor should ever set failbit if 2463the initial stream rdstate() == eofbit. That is contrary to the behavior of 2464all implementations I tested. The program below prints out 2465 2466eof = 1, fail = 0 2467eof = 1, fail = 1 2468 2469on all of them. 2470 </p> 2471<pre> 2472#include <sstream> 2473#include <cstdio> 2474 2475int main() 2476{ 2477 std::istringstream strm ("1"); 2478 2479 int i = 0; 2480 2481 strm >> i; 2482 2483 std::printf ("eof = %d, fail = %d\n", 2484 !!strm.eof (), !!strm.fail ()); 2485 2486 strm >> i; 2487 2488 std::printf ("eof = %d, fail = %d\n", 2489 !!strm.eof (), !!strm.fail ()); 2490} 2491 2492</pre> 2493 <p> 2494<br> 2495 2496Comments from Jerry Schwarz (c++std-lib-11373): 2497<br> 2498 2499Jerry Schwarz wrote: 2500<br> 2501 2502I don't know where (if anywhere) it says it in the standard, but the 2503formatted extractors are supposed to set failbit if they don't extract 2504any characters. If they didn't then simple loops like 2505<br> 2506 2507while (cin >> x); 2508<br> 2509 2510would loop forever. 2511<br> 2512 2513Further comments from Martin Sebor: 2514<br> 2515 2516The question is which part of the extraction should prevent this from happening 2517by setting failbit when eofbit is already set. It could either be the sentry 2518object or the extractor. It seems that most implementations have chosen to 2519set failbit in the sentry [...] so that's the text that will need to be 2520corrected. 2521 2522 </p> 2523<p> 2524Pre Berlin: This issue is related to 2525<a href="file:///Volumes/Data/lwg/lwg-active.html#342">342</a>. If the sentry 2526sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then 2527you can never seek away from the end of stream. 2528</p> 2529 2530 <p><b>Proposed resolution:</b></p> 2531<p>Kona: Possibly NAD. If eofbit is set then good() will return false. We 2532 then set <i>ok</i> to false. We believe that the sentry's 2533 constructor should always set failbit when <i>ok</i> is false, and 2534 we also think the standard already says that. Possibly it could be 2535 clearer.</p> 2536 2537<hr> 2538<a name="421"><h3>421. is basic_streambuf copy-constructible?</h3></a><p><b>Section:</b> 27.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> 2539<p> 2540The reflector thread starting with c++std-lib-11346 notes that the class 2541template basic_streambuf, along with basic_stringbuf and basic_filebuf, 2542is copy-constructible but that the semantics of the copy constructors 2543are not defined anywhere. Further, different implementations behave 2544differently in this respect: some prevent copy construction of objects 2545of these types by declaring their copy ctors and assignment operators 2546private, others exhibit undefined behavior, while others still give 2547these operations well-defined semantics. 2548</p> 2549 2550<p> 2551Note that this problem doesn't seem to be isolated to just the three 2552types mentioned above. A number of other types in the library section 2553of the standard provide a compiler-generated copy ctor and assignment 2554operator yet fail to specify their semantics. It's believed that the 2555only types for which this is actually a problem (i.e. types where the 2556compiler-generated default may be inappropriate and may not have been 2557intended) are locale facets. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>. 2558</p> 2559<p><b>Proposed resolution:</b></p> 2560<p> 256127.5.2 [lib.streambuf]: Add into the synopsis, public section, just above the destructor declaration: 2562</p> 2563 2564<blockquote> 2565<pre>basic_streambuf(const basic_streambuf& sb); 2566basic_streambuf& operator=(const basic_streambuf& sb); 2567</pre> 2568</blockquote> 2569 2570<p>Insert after 27.5.2.1, paragraph 2:</p> 2571<blockquote> 2572<pre>basic_streambuf(const basic_streambuf& sb); 2573</pre> 2574 2575<p>Constructs a copy of sb.</p> 2576<p>Postcondtions:</p> 2577<pre> eback() == sb.eback() 2578 gptr() == sb.gptr() 2579 egptr() == sb.egptr() 2580 pbase() == sb.pbase() 2581 pptr() == sb.pptr() 2582 epptr() == sb.epptr() 2583 getloc() == sb.getloc() 2584</pre> 2585 2586<pre>basic_streambuf& operator=(const basic_streambuf& sb); 2587</pre> 2588 2589<p>Assigns the data members of sb to this.</p> 2590 2591<p>Postcondtions:</p> 2592<pre> eback() == sb.eback() 2593 gptr() == sb.gptr() 2594 egptr() == sb.egptr() 2595 pbase() == sb.pbase() 2596 pptr() == sb.pptr() 2597 epptr() == sb.epptr() 2598 getloc() == sb.getloc() 2599</pre> 2600 2601<p>Returns: *this.</p> 2602</blockquote> 2603 2604<p>27.7.1 [lib.stringbuf]:</p> 2605 2606<b>Option A:</b> 2607 2608<blockquote> 2609<p>Insert into the basic_stringbuf synopsis in the private section:</p> 2610 2611<pre>basic_stringbuf(const basic_stringbuf&); // not defined 2612basic_stringbuf& operator=(const basic_stringbuf&); // not defined 2613</pre> 2614</blockquote> 2615 2616<b>Option B:</b> 2617 2618<blockquote> 2619<p>Insert into the basic_stringbuf synopsis in the public section:</p> 2620 2621<pre>basic_stringbuf(const basic_stringbuf& sb); 2622basic_stringbuf& operator=(const basic_stringbuf& sb); 2623</pre> 2624 2625<p>27.7.1.1, insert after paragraph 4:</p> 2626 2627<pre>basic_stringbuf(const basic_stringbuf& sb);</pre> 2628 2629<p> 2630Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with. 2631</p> 2632 2633<p>Postcondtions: </p> 2634<pre> str() == sb.str() 2635 gptr() - eback() == sb.gptr() - sb.eback() 2636 egptr() - eback() == sb.egptr() - sb.eback() 2637 pptr() - pbase() == sb.pptr() - sb.pbase() 2638 getloc() == sb.getloc() 2639</pre> 2640 2641<p> 2642Note: The only requirement on epptr() is that it point beyond the 2643initialized range if an output sequence exists. There is no requirement 2644that epptr() - pbase() == sb.epptr() - sb.pbase(). 2645</p> 2646 2647<pre>basic_stringbuf& operator=(const basic_stringbuf& sb);</pre> 2648<p>After assignment the basic_stringbuf has the same state as if it 2649were initially copy constructed from sb, except that the 2650basic_stringbuf is allowed to retain any excess capacity it might have, 2651which may in turn effect the value of epptr(). 2652</p> 2653</blockquote> 2654 2655<p>27.8.1.1 [lib.filebuf]</p> 2656 2657<p>Insert at the bottom of the basic_filebuf synopsis:</p> 2658 2659<blockquote> 2660<pre>private: 2661 basic_filebuf(const basic_filebuf&); // not defined 2662 basic_filebuf& operator=(const basic_filebuf&); // not defined 2663</pre> 2664</blockquote> 2665<p><i>[Kona: this is an issue for basic_streambuf itself and for its 2666 derived classes. We are leaning toward allowing basic_streambuf to 2667 be copyable, and specifying its precise semantics. (Probably the 2668 obvious: copying the buffer pointers.) We are less sure whether 2669 the streambuf derived classes should be copyable. Howard will 2670 write up a proposal.]</i></p> 2671 2672<p><i>[Sydney: Dietmar presented a new argument against basic_streambuf 2673 being copyable: it can lead to an encapsulation violation. Filebuf 2674 inherits from streambuf. Now suppose you inhert a my_hijacking_buf 2675 from streambuf. You can copy the streambuf portion of a filebuf to a 2676 my_hijacking_buf, giving you access to the pointers into the 2677 filebuf's internal buffer. Perhaps not a very strong argument, but 2678 it was strong enough to make people nervous. There was weak 2679 preference for having streambuf not be copyable. There was weak 2680 preference for having stringbuf not be copyable even if streambuf 2681 is. Move this issue to open for now. 2682]</i></p> 2683 2684<p><b>Rationale:</b></p> 2685<p> 268627.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor 2687and assignment operator are the same as currently implied by the lack 2688of declarations: public and simply copies the data members. This 2689resolution is not a change but a clarification of the current 2690standard. 2691</p> 2692 2693<p> 269427.7.1 [lib.stringbuf]: There are two reasonable options: A) Make 2695basic_stringbuf not copyable. This is likely the status-quo of 2696current implementations. B) Reasonable copy semantics of 2697basic_stringbuf can be defined and implemented. A copyable 2698basic_streambuf is arguably more useful than a non-copyable one. This 2699should be considered as new functionality and not the fixing of a 2700defect. If option B is chosen, ramifications from issue 432 are taken 2701into account. 2702</p> 2703 2704<p> 270527.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for 2706basic_filebuf. 2707</p> 2708 2709<hr> 2710<a name="422"><h3>422. explicit specializations of member functions of class templates</h3></a><p><b>Section:</b> 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> 2711<p> 2712It has been suggested that 17.4.3.1, p1 may or may not allow programs to 2713explicitly specialize members of standard templates on user-defined types. 2714The answer to the question might have an impact where library requirements 2715are given using the "as if" rule. I.e., if programs are allowed to specialize 2716member functions they will be able to detect an implementation's strict 2717conformance to Effects clauses that describe the behavior of the function 2718in terms of the other member function (the one explicitly specialized by 2719the program) by relying on the "as if" rule. 2720</p> 2721<p><b>Proposed resolution:</b></p> 2722 2723<p> 2724 Add the following sentence immediately after the text 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>, p1: 2725</p> 2726 2727<blockquote> 2728 The behavior of a program that declares explicit specializations 2729 of any members of class templates or explicit specializations of 2730 any member templates of classes or class templates defined in 2731 this library is undefined. 2732</blockquote> 2733 2734 2735<p><i>[Kona: straw poll was 6-1 that user programs should not be 2736 allowed to specialize individual member functions of standard 2737 library class templates, and that doing so invokes undefined 2738 behavior. Post-Kona: Martin provided wording.]</i></p> 2739 2740<p><i>[Sydney: The LWG agrees that the standard shouldn't permit users 2741to specialize individual member functions unless they specialize the 2742whole class, but we're not sure these words say what we want them to; 2743they could be read as prohibiting the specialization of any standard 2744library class templates. We need to consult with CWG to make sure we 2745use the right wording.]</i></p> 2746 2747<hr> 2748<a name="423"></a><h3><a name="423">423. effects of negative streamsize in iostreams</a></h3><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> 2749 2750<p> 2751A third party test suite tries to exercise istream::ignore(N) with 2752a negative value of N and expects that the implementation will treat 2753N as if it were 0. Our implementation asserts that (N >= 0) holds and 2754aborts the test. 2755</p> 2756 2757<p> 2758I can't find anything in section 27 that prohibits such values but I don't 2759see what the effects of such calls should be, either (this applies to 2760a number of unformatted input functions as well as some member functions 2761of the basic_streambuf template). 2762</p> 2763<p><b>Proposed resolution:</b></p> 2764<p> 2765I propose that we add to each function in clause 27 that takes an argument, 2766say N, of type streamsize a Requires clause saying that "N >= 0." The intent 2767is to allow negative streamsize values in calls to precision() and width() 2768but disallow it in calls to streambuf::sgetn(), istream::ignore(), or 2769ostream::write(). 2770</p> 2771 2772<p><i>[Kona: The LWG agreed that this is probably what we want. However, we 2773 need a review to find all places where functions in clause 27 take 2774 arguments of type streamsize that shouldn't be allowed to go 2775 negative. Martin will do that review.]</i></p> 2776 2777<hr> 2778<a name="424"><h3>424. normative notes</h3></a><p><b>Section:</b> 17.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.summary"> [lib.structure.summary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> 2779 2780<p> 2781The text in 17.3.1.1, p1 says: 2782<br> 2783 2784"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other 2785paragraphs are normative." 2786<br> 2787 2788The library section makes heavy use of paragraphs labeled "Notes(s)," 2789some of which are clearly intended to be normative (see list 1), while 2790some others are not (see list 2). There are also those where the intent 2791is not so clear (see list 3). 2792<br> 2793 2794List 1 -- Examples of (presumably) normative Notes: 2795<br> 2796 279720.4.1.1, p3, 20.4.1.1, p10, 21.3.1, p11, 22.1.1.2, p11, 23.2.1.3, p2, 279825.3.7, p3, 26.2.6, p14a, 27.5.2.4.3, p7. 2799<br> 2800 2801List 2 -- Examples of (presumably) informative Notes: 2802<br> 2803 280418.4.1.3, p3, 21.3.5.6, p14, 22.2.1.5.2, p3, 25.1.1, p4, 26.2.5, p1, 280527.4.2.5, p6. 2806<br> 2807 2808List 3 -- Examples of Notes that are not clearly either normative 2809or informative: 2810<br> 2811 281222.1.1.2, p8, 22.1.1.5, p6, 27.5.2.4.5, p4. 2813<br> 2814 2815None of these lists is meant to be exhaustive. 2816</p> 2817 2818<p><b>Proposed resolution:</b></p> 2819 2820<p><i>[Definitely a real problem. The big problem is there's material 2821 that doesn't quite fit any of the named paragraph categories 2822 (e.g. <b>Effects</b>). Either we need a new kind of named 2823 paragraph, or we need to put more material in unnamed paragraphs 2824 jsut after the signature. We need to talk to the Project Editor 2825 about how to do this. 2826]</i></p> 2827 2828<hr> 2829<a name="427"><h3>427. stage 2 and rationale of DR 221</h3></a><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> 2830<p> 2831The requirements specified in Stage 2 and reiterated in the rationale 2832of DR 221 (and echoed again in DR 303) specify that num_get<charT>:: 2833do_get() compares characters on the stream against the widened elements 2834of "012...abc...ABCX+-" 2835</p> 2836 2837<p> 2838An implementation is required to allow programs to instantiate the num_get 2839template on any charT that satisfies the requirements on a user-defined 2840character type. These requirements do not include the ability of the 2841character type to be equality comparable (the char_traits template must 2842be used to perform tests for equality). Hence, the num_get template cannot 2843be implemented to support any arbitrary character type. The num_get template 2844must either make the assumption that the character type is equality-comparable 2845(as some popular implementations do), or it may use char_traits<charT> to do 2846the comparisons (some other popular implementations do that). This diversity 2847of approaches makes it difficult to write portable programs that attempt to 2848instantiate the num_get template on user-defined types. 2849</p> 2850<p><b>Proposed resolution:</b></p> 2851<p><i>[Kona: the heart of the problem is that we're theoretically 2852 supposed to use traits classes for all fundamental character 2853 operations like assignment and comparison, but facets don't have 2854 traits parameters. This is a fundamental design flaw and it 2855 appears all over the place, not just in this one place. It's not 2856 clear what the correct solution is, but a thorough review of facets 2857 and traits is in order. The LWG considered and rejected the 2858 possibility of changing numeric facets to use narrowing instead of 2859 widening. This may be a good idea for other reasons (see issue 2860 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#459">459</a>), but it doesn't solve the problem raised by this 2861 issue. Whether we use widen or narrow the <tt>num_get</tt> facet 2862 still has no idea which traits class the user wants to use for 2863 the comparison, because only streams, not facets, are passed traits 2864 classes. The standard does not require that two different 2865 traits classes with the same <tt>char_type</tt> must necessarily 2866 have the same behavior.]</i></p> 2867 2868<p>Informally, one possibility: require that some of the basic 2869character operations, such as <tt>eq</tt>, <tt>lt</tt>, 2870and <tt>assign</tt>, must behave the same way for all traits classes 2871with the same <tt>char_type</tt>. If we accept that limitation on 2872traits classes, then the facet could reasonably be required to 2873use <tt>char_traits<charT></tt></p>. 2874 2875<hr> 2876<a name="430"><h3>430. valarray subset operations</h3></a><p><b>Section:</b> 26.5.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.sub"> [lib.valarray.sub]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> 2877<p> 2878The standard fails to specify the behavior of valarray::operator[](slice) 2879and other valarray subset operations when they are passed an "invalid" 2880slice object, i.e., either a slice that doesn't make sense at all (e.g., 2881slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray 2882object (e.g., slice (2, 1, 1) for a valarray of size 1). 2883</p> 2884<p><b>Proposed resolution:</b></p> 2885<p><i>[Kona: the LWG believes that invalid slices should invoke 2886 undefined behavior. Valarrays are supposed to be designed for high 2887 performance, so we don't want to require specific checking. We 2888 need wording to express this decision.]</i></p> 2889<hr> 2890<a name="431"><h3>431. Swapping containers with unequal allocators</h3></a><p><b>Section:</b> 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>, 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Sep 2003</p> 2891<p>Clause 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 says that implementations 2892 are permitted to supply containers that are unable to cope with 2893 allocator instances and that container implementations may assume 2894 that all instances of an allocator type compare equal. We gave 2895 implementers this latitude as a temporary hack, and eventually we 2896 want to get rid of it. What happens when we're dealing with 2897 allocators that <i>don't</i> compare equal? 2898</p> 2899 2900<p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both 2901 objects of type <tt>vector<int, my_alloc></tt> and that 2902 <tt>v1.get_allocator() != v2.get_allocator()</tt>. What happens if 2903 we write <tt>v1.swap(v2)</tt>? Informally, three possibilities:</p> 2904 2905<p>1. This operation is illegal. Perhaps we could say that an 2906 implementation is required to check and to throw an exception, or 2907 perhaps we could say it's undefined behavior.</p> 2908<p>2. The operation performs a slow swap (i.e. using three 2909 invocations of <tt>operator=</tt>, leaving each allocator with its 2910 original container. This would be an O(N) operation.</p> 2911<p>3. The operation swaps both the vectors' contents and their 2912 allocators. This would be an O(1) operation. That is:</p> 2913 <blockquote> 2914 <pre> my_alloc a1(...); 2915 my_alloc a2(...); 2916 assert(a1 != a2); 2917 2918 vector<int, my_alloc> v1(a1); 2919 vector<int, my_alloc> v2(a2); 2920 assert(a1 == v1.get_allocator()); 2921 assert(a2 == v2.get_allocator()); 2922 2923 v1.swap(v2); 2924 assert(a1 == v2.get_allocator()); 2925 assert(a2 == v1.get_allocator()); 2926 </pre> 2927 </blockquote> 2928 2929<p><b>Proposed resolution:</b></p> 2930 2931<p><i>[Kona: This is part of a general problem. We need a paper 2932 saying how to deal with unequal allocators in general.]</i></p> 2933 2934<p><i>[pre-Sydney: Howard argues for option 3 in n1599.]</i></p> 2935 2936<hr> 2937<a name="446"><h3>446. Iterator equality between different containers</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>, 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andy Koenig <b>Date:</b> 16 Dec 2003</p> 2938<p> 2939What requirements does the standard place on equality comparisons between 2940iterators that refer to elements of different containers. For example, if 2941v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true? 2942Is it allowed to throw an exception? 2943</p> 2944 2945<p> 2946The standard appears to be silent on both questions. 2947</p> 2948<p><b>Proposed resolution:</b></p> 2949 2950<p><i>[Sydney: The intention is that comparing two iterators from 2951different containers is undefined, but it's not clear if we say that, 2952or even whether it's something we should be saying in clause 23 or in 2953clause 24. Intuitively we might want to say that equality is defined 2954only if one iterator is reachable from another, but figuring out how 2955to say it in any sensible way is a bit tricky: reachability is defined 2956in terms of equality, so we can't also define equality in terms of 2957reachability. 2958]</i></p> 2959 2960<hr> 2961<a name="454"><h3>454. basic_filebuf::open should accept wchar_t names</h3></a><p><b>Section:</b> 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> 2962<pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode); 2963</pre> 2964 2965<p>should be supplemented with the overload:</p> 2966 2967<pre> basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode); 2968</pre> 2969 2970<p> 2971Depending on the operating system, one of these forms is fundamental and 2972the other requires an implementation-defined mapping to determine the 2973actual filename. 2974</p> 2975 2976<p><i>[Sydney: Yes, we want to allow wchar_t filenames. Bill will 2977 provide wording.]</i></p> 2978 2979<p><b>Proposed resolution:</b></p> 2980 2981<p>Change from:</p> 2982<blockquote> 2983<pre>basic_filebuf<charT,traits>* open( 2984 const char* s, 2985 ios_base::openmode mode ); 2986</pre> 2987 2988<p> 2989Effects: If is_open() != false, returns a null pointer. 2990Otherwise, initializes the filebuf as required. It then 2991opens a file, if possible, whose name is the NTBS s ("as if" 2992by calling std::fopen(s,modstr)).</p> 2993</blockquote> 2994 2995<p>to:</p> 2996 2997<blockquote> 2998<pre>basic_filebuf<charT,traits>* open( 2999 const char* s, 3000 ios_base::openmode mode ); 3001 3002basic_filebuf<charT,traits>* open( 3003 const wchar_t* ws, 3004 ios_base::openmode mode ); 3005</pre> 3006 3007<p> 3008Effects: If is_open() != false, returns a null pointer. 3009Otherwise, initializes the filebuf as required. It then 3010opens a file, if possible, whose name is the NTBS s ("as if" 3011by calling std::fopen(s,modstr)). 3012For the second signature, the NTBS s is determined from the 3013WCBS ws in an implementation-defined manner. 3014</p> 3015 3016<p> 3017(NOTE: For a system that "naturally" represents a filename 3018as a WCBS, the NTBS s in the first signature may instead 3019be mapped to a WCBS; if so, it follows the same mapping 3020rules as the first argument to open.) 3021</p> 3022</blockquote> 3023 3024<p><b>Rationale:</b></p> 3025<p> 3026Slightly controversial, but by a 7-1 straw poll the LWG agreed to move 3027this to Ready. The controversy was because the mapping between wide 3028names and files in a filesystem is implementation defined. The 3029counterargument, which most but not all LWG members accepted, is that 3030the mapping between narrow files names and files is also 3031implemenation defined.</p> 3032 3033<p><i>[Lillehammer: Moved back to "open" status, at Beman's urging. 3034(1) Why just basic_filebuf, instead of also basic_fstream (and 3035possibly other things too). (2) Why not also constructors that take 3036std::basic_string? (3) We might want to wait until we see Beman's 3037filesystem library; we might decide that it obviates this.]</i></p> 3038 3039<hr> 3040<a name="456"><h3>456. Traditional C header files are overspecified</h3></a><p><b>Section:</b> 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> 3041 3042<p>The C++ Standard effectively requires that the traditional C headers 3043(of the form <xxx.h>) be defined in terms of the newer C++ 3044headers (of the form <cxxx>). Clauses 17.4.1.2/4 and D.5 combine 3045to require that:</p> 3046 3047<ul> 3048 <li>Including the header <cxxx> declares a C name in namespace std.</li> 3049 3050 <li> Including the header <xxx.h> declares a C name in namespace std 3051 (effectively by including <cxxx>), then imports it into the global 3052 namespace with an individual using declaration.</li> 3053</ul> 3054 3055<p> 3056The rules were left in this form despited repeated and heated objections 3057from several compiler vendors. The C headers are often beyond the direct 3058control of C++ implementors. In some organizations, it's all they can do 3059to get a few #ifdef __cplusplus tests added. Third-party library vendors 3060can perhaps wrap the C headers. But neither of these approaches supports 3061the drastic restructuring required by the C++ Standard. As a result, it is 3062still widespread practice to ignore this conformance requirement, nearly 3063seven years after the committee last debated this topic. Instead, what is 3064often implemented is: 3065</p> 3066 3067<ul> 3068 <li> Including the header <xxx.h> declares a C name in the 3069 global namespace.</li> 3070 3071 <li> Including the header <cxxx> declares a C name in the 3072 global namespace (effectively by including <xxx.h>), then 3073 imports it into namespace std with an individual using declaration.</li> 3074</ul> 3075 3076<p> 3077The practical benefit for implementors with the second approach is that 3078they can use existing C library headers, as they are pretty much obliged 3079to do. The practical cost for programmers facing a mix of implementations 3080is that they have to assume weaker rules:</p> 3081 3082<ul> 3083 <li> If you want to assuredly declare a C name in the global 3084 namespace, include <xxx.h>. You may or may not also get the 3085 declaration in namespace std.</li> 3086 3087 <li> If you want to assuredly declare a C name in namespace std, 3088 include <cxxx.h>. You may or may not also get the declaration in 3089 the global namespace.</li> 3090</ul> 3091 3092<p> 3093There also exists the <i>possibility</i> of subtle differences due to 3094Koenig lookup, but there are so few non-builtin types defined in the C 3095headers that I've yet to see an example of any real problems in this 3096area. 3097</p> 3098 3099<p> 3100It is worth observing that the rate at which programmers fall afoul of 3101these differences has remained small, at least as measured by newsgroup 3102postings and our own bug reports. (By an overwhelming margin, the 3103commonest problem is still that programmers include <string> and can't 3104understand why the typename string isn't defined -- this a decade after 3105the committee invented namespace std, nominally for the benefit of all 3106programmers.) 3107</p> 3108 3109<p> 3110We should accept the fact that we made a serious mistake and rectify it, 3111however belatedly, by explicitly allowing either of the two schemes for 3112declaring C names in headers. 3113</p> 3114 3115<p><i>[Sydney: This issue has been debated many times, and will 3116 certainly have to be discussed in full committee before any action 3117 can be taken. However, the preliminary sentiment of the LWG was in 3118 favor of the change. (6 yes, 0 no, 2 abstain) Robert Klarer 3119 suggests that we might also want to undeprecate the 3120 C-style <tt>.h</tt> headers.]</i></p> 3121 3122<p><b>Proposed resolution:</b></p> 3123<hr> 3124<a name="458"><h3>458. 24.1.5 contains unintented limitation for operator-</h3></a><p><b>Section:</b> 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Daniel Frey <b>Date:</b> 27 Feb 2004</p> 3125<p> 3126In 24.1.5 [lib.random.access.iterators], table 76 the operational 3127semantics for the expression "r -= n" are defined as "return r += -n". 3128This means, that the expression -n must be valid, which is not the case 3129for unsigned types. 3130</p> 3131 3132<p><i>[ 3133Sydney: Possibly not a real problem, since difference type is required 3134to be a signed integer type. However, the wording in the standard may 3135be less clear than we would like. 3136]</i></p> 3137 3138<p><b>Proposed resolution:</b></p> 3139<p> 3140To remove this limitation, I suggest to change the 3141operational semantics for this column to: 3142</p> 3143<code> 3144 { Distance m = n; 3145 if (m >= 0) 3146 while (m--) --r; 3147 else 3148 while (m++) ++r; 3149 return r; } 3150</code> 3151 3152<hr> 3153<a name="459"><h3>459. Requirement for widening in stage 2 is overspecification</h3></a><p><b>Section:</b> 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 16 Mar 2004</p> 3154<p>When parsing strings of wide-character digits, the standard 3155 requires the library to widen narrow-character "atoms" and compare 3156 the widened atoms against the characters that are being parsed. 3157 Simply narrowing the wide characters would be far simpler, and 3158 probably more efficient. The two choices are equivalent except in 3159 convoluted test cases, and many implementations already ignore the 3160 standard and use narrow instead of widen.</p> 3161 3162<p> 3163First, I disagree that using narrow() instead of widen() would 3164necessarily have unfortunate performance implications. A possible 3165implementation of narrow() that allows num_get to be implemented 3166in a much simpler and arguably comparably efficient way as calling 3167widen() allows, i.e. without making a virtual call to do_narrow every 3168time, is as follows: 3169</p> 3170 3171<pre> inline char ctype<wchar_t>::narrow (wchar_t wc, char dflt) const 3172 { 3173 const unsigned wi = unsigned (wc); 3174 3175 if (wi > UCHAR_MAX) 3176 return typeid (*this) == typeid (ctype<wchar_t>) ? 3177 dflt : do_narrow (wc, dflt); 3178 3179 if (narrow_ [wi] < 0) { 3180 const char nc = do_narrow (wc, dflt); 3181 if (nc == dflt) 3182 return dflt; 3183 narrow_ [wi] = nc; 3184 } 3185 3186 return char (narrow_ [wi]); 3187 } 3188</pre> 3189 3190<p> 3191Second, I don't think the change proposed in the issue (i.e., to use 3192narrow() instead of widen() during Stage 2) would be at all 3193drastic. Existing implementations with the exception of libstdc++ 3194currently already use narrow() so the impact of the change on programs 3195would presumably be isolated to just a single implementation. Further, 3196since narrow() is not required to translate alternate wide digit 3197representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> to 3198their narrow equivalents (i.e., the portable source characters '0' 3199through '9'), the change does not necessarily imply that these 3200alternate digits would be treated as ordinary digits and accepted as 3201part of numbers during parsing. In fact, the requirement 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>, p13 forbids narrow() to translate an alternate 3202digit character, wc, to an ordinary digit in the basic source 3203character set unless the expression 3204(ctype<charT>::is(ctype_base::digit, wc) == true) holds. This in 3205turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and 32065.2.1, respectively) for charT of either char or wchar_t. 3207</p> 3208 3209<p><i>[Sydney: To a large extent this is a nonproblem. As long as 3210you're only trafficking in char and wchar_t we're only dealing with a 3211stable character set, so you don't really need either 'widen' or 3212'narrow': can just use literals. Finally, it's not even clear whether 3213widen-vs-narrow is the right question; arguably we should be using 3214codecvt instead.]</i></p> 3215 3216<p><b>Proposed resolution:</b></p> 3217<p>Change stage 2 so that implementations are permitted to use either 3218technique to perform the comparison:</p> 3219<ol> 3220 <li> call widen on the atoms and compare (either by using 3221 operator== or char_traits<charT>::eq) the input with 3222 the widened atoms, or</li> 3223 <li> call narrow on the input and compare the narrow input 3224 with the atoms</li> 3225 <li> do (1) or (2) only if charT is not char or wchar_t, 3226 respectively; i.e., avoid calling widen or narrow 3227 if it the source and destination types are the same</li> 3228</ol> 3229<hr> 3230<a name="462"><h3>462. Destroying objects with static storage duration</h3></a><p><b>Section:</b> 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.start.term"> [basic.start.term]</a>, 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.cstdint"> [lib.cstdint]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 23 Mar 2004</p> 3231<p> 32323.6.3 Termination spells out in detail the interleaving of static 3233destructor calls and calls to functions registered with atexit. To 3234match this behavior requires intimate cooperation between the code 3235that calls destructors and the exit/atexit machinery. The former 3236is tied tightly to the compiler; the latter is a primitive mechanism 3237inherited from C that traditionally has nothing to do with static 3238construction and destruction. The benefits of intermixing destructor 3239calls with atexit handler calls is questionable at best, and <i>very</i> 3240difficult to get right, particularly when mixing third-party C++ 3241libraries with different third-party C++ compilers and C libraries 3242supplied by still other parties. 3243</p> 3244 3245<p> 3246I believe the right thing to do is defer all static destruction 3247until after all atexit handlers are called. This is a change in 3248behavior, but one that is likely visible only to perverse test 3249suites. At the very least, we should <i>permit</i> deferred destruction 3250even if we don't require it. 3251</p> 3252<p><b>Proposed resolution:</b></p> 3253 3254<p><i>[If this is to be changed, it should probably be changed by CWG. 3255 At this point, however, the LWG is leaning toward NAD. Implementing 3256 what the standard says is hard work, but it's not impossible and 3257 most vendors went through that pain years ago. Changing this 3258 behavior would be a user-visible change, and would break at least 3259 one real application.]</i></p> 3260 3261<p> 3262</p> 3263<hr> 3264<a name="463"><h3>463. auto_ptr usability issues</h3></a><p><b>Section:</b> 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Rani Sharoni <b>Date:</b> 7 Dec 2003</p> 3265 3266<p> 3267TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>() 3268member of auto_ptr (20.4.5.3/4) obsolete. 3269</p> 3270 3271<p> 3272The sole purpose of this obsolete conversion member is to enable copy 3273initialization base from r-value derived (or any convertible types like 3274cv-types) case: 3275</p> 3276<pre>#include <memory> 3277using std::auto_ptr; 3278 3279struct B {}; 3280struct D : B {}; 3281 3282auto_ptr<D> source(); 3283int sink(auto_ptr<B>); 3284int x1 = sink( source() ); // #1 EDG - no suitable copy constructor 3285</pre> 3286 3287<p> 3288The excellent analysis of conversion operations that was given in the final 3289auto_ptr proposal 3290(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf) 3291explicitly specifies this case analysis (case 4). DR #84 makes the analysis 3292wrong and actually comes to forbid the loophole that was exploited by the 3293auto_ptr designers. 3294</p> 3295 3296<p> 3297I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that 3298ever allowed this case. This is probably because it requires 3 user defined 3299conversions and in fact current compilers conform to DR #84. 3300</p> 3301 3302<p> 3303I was surprised to discover that the obsolete conversion member actually has 3304negative impact of the copy initialization base from l-value derived 3305case:</p> 3306<pre>auto_ptr<D> dp; 3307int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies 3308</pre> 3309 3310<p> 3311I'm sure that the original intention was allowing this initialization using 3312the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but 3313since in this copy initialization it's merely user defined conversion (UDC) 3314and the obsolete conversion member is UDC with the same rank (for the early 3315overloading stage) there is an ambiguity between them. 3316</p> 3317 3318<p> 3319Removing the obsolete member will have impact on code that explicitly 3320invokes it: 3321</p> 3322<pre>int y = sink(source().operator auto_ptr<B>()); 3323</pre> 3324 3325<p> 3326IMHO no one ever wrote such awkward code and the reasonable workaround for 3327#1 is: 3328</p> 3329<pre>int y = sink( auto_ptr<B>(source()) ); 3330</pre> 3331 3332<p> 3333I was even more surprised to find out that after removing the obsolete 3334conversion member the initialization was still ill-formed: 3335int x3 = sink(dp); // #3 EDG - no suitable copy constructor 3336</p> 3337 3338<p> 3339This copy initialization semantically requires copy constructor which means 3340that both template conversion constructor and the auto_ptr_ref conversion 3341member (20.4.5.3/3) are required which is what was explicitly forbidden in 3342DR #84. This is a bit amusing case in which removing ambiguity results with 3343no candidates. 3344</p> 3345 3346<p> 3347I also found exception safety issue with auto_ptr related to auto_ptr_ref: 3348</p> 3349<pre>int f(auto_ptr<B>, std::string); 3350auto_ptr<B> source2(); 3351 3352// string constructor throws while auto_ptr_ref 3353// "holds" the pointer 3354int x4 = f(source2(), "xyz"); // #4 3355</pre> 3356 3357<p> 3358The theoretic execution sequence that will cause a leak: 3359</p> 3360<ol> 3361<li>call auto_ptr<B>::operator auto_ptr_ref<B>()</li> 3362<li>call string::string(char const*) and throw</li> 3363</ol> 3364 3365<p> 3366According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member 3367returns auto_ptr_ref<Y> that holds *this and this is another defect since 3368the type of *this is auto_ptr<X> where X might be different from Y. Several 3369library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which 3370is much more reasonable. Other vendor implemented auto_ptr_ref as 3371defectively required and it results with awkward and catastrophic code: 3372int oops = sink(auto_ptr<B>(source())); // warning recursive on all control 3373paths 3374</p> 3375 3376<p> 3377Dave Abrahams noticed that there is no specification saying that 3378auto_ptr_ref copy constructor can't throw. 3379</p> 3380 3381<p> 3382My proposal comes to solve all the above issues and significantly simplify 3383auto_ptr implementation. One of the fundamental requirements from auto_ptr 3384is that it can be constructed in an intuitive manner (i.e. like ordinary 3385pointers) but with strict ownership semantics which yield that source 3386auto_ptr in initialization must be non-const. My idea is to add additional 3387constructor template with sole propose to generate ill-formed, diagnostic 3388required, instance for const auto_ptr arguments during instantiation of 3389declaration. This special constructor will not be instantiated for other 3390types which is achievable using 14.8.2/2 (SFINAE). Having this constructor 3391in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&) 3392legitimate since the actual argument can't be const yet non const r-value 3393are acceptable. 3394</p> 3395 3396<p> 3397This implementation technique makes the "private auxiliary class" 3398auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG, 3399GCC and VC) consume the new implementation as expected and allow all 3400intuitive initialization and assignment cases while rejecting illegal cases 3401that involve const auto_ptr arguments. 3402</p> 3403 3404<p>The proposed auto_ptr interface:</p> 3405 3406<pre>namespace std { 3407 template<class X> class auto_ptr { 3408 public: 3409 typedef X element_type; 3410 3411 // 20.4.5.1 construct/copy/destroy: 3412 explicit auto_ptr(X* p=0) throw(); 3413 auto_ptr(auto_ptr&) throw(); 3414 template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); 3415 auto_ptr& operator=(auto_ptr&) throw(); 3416 template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw(); 3417 ~auto_ptr() throw(); 3418 3419 // 20.4.5.2 members: 3420 X& operator*() const throw(); 3421 X* operator->() const throw(); 3422 X* get() const throw(); 3423 X* release() throw(); 3424 void reset(X* p=0) throw(); 3425 3426 private: 3427 template<class U> 3428 auto_ptr(U& rhs, typename 3429unspecified_error_on_const_auto_ptr<U>::type = 0); 3430 }; 3431} 3432</pre> 3433 3434<p> 3435One compliant technique to implement the unspecified_error_on_const_auto_ptr 3436helper class is using additional private auto_ptr member class template like 3437the following: 3438</p> 3439<pre>template<typename T> struct unspecified_error_on_const_auto_ptr; 3440 3441template<typename T> 3442struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const> 3443{ typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; }; 3444</pre> 3445 3446<p> 3447There are other techniques to implement this helper class that might work 3448better for different compliers (i.e. better diagnostics) and therefore I 3449suggest defining its semantic behavior without mandating any specific 3450implementation. IMO, and I didn't found any compiler that thinks otherwise, 345114.7.1/5 doesn't theoretically defeat the suggested technique but I suggest 3452verifying this with core language experts. 3453</p> 3454 3455<p><b>Further changes in standard text:</b></p> 3456<p>Remove section 20.4.5.3</p> 3457 3458<p>Change 20.4.5/2 to read something like: 3459Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified 3460ill-formed declaration that will require unspecified diagnostic.</p> 3461 3462<p>Change 20.4.5.1/4,5,6 to read:</p> 3463 3464<pre>template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();</pre> 3465<p> 4 Requires: Y* can be implicitly converted to X*.</p> 3466<p> 5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().</p> 3467<p> 6 Postconditions: *this holds the pointer returned from a.release().</p> 3468 3469<p>Change 20.4.5.1/10</p> 3470<pre>template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw(); 3471</pre> 3472<p> 347310 Requires: Y* can be implicitly converted to X*. The expression delete 3474get() is well formed. 3475</p> 3476 3477<p>LWG TC DR #127 is obsolete.</p> 3478 3479<p> 3480Notice that the copy constructor and copy assignment operator should remain 3481as before and accept non-const auto_ptr& since they have effect on the form 3482of the implicitly declared copy constructor and copy assignment operator of 3483class that contains auto_ptr as member per 12.8/5,10: 3484</p> 3485<pre>struct X { 3486 // implicit X(X&) 3487 // implicit X& operator=(X&) 3488 auto_ptr<D> aptr_; 3489}; 3490</pre> 3491 3492<p> 3493In most cases this indicates about sloppy programming but preserves the 3494current auto_ptr behavior. 3495</p> 3496 3497<p> 3498Dave Abrahams encouraged me to suggest fallback implementation in case that 3499my suggestion that involves removing of auto_ptr_ref will not be accepted. 3500In this case removing the obsolete conversion member to auto_ptr<Y> and 350120.4.5.3/4,5 is still required in order to eliminate ambiguity in legal 3502cases. The two constructors that I suggested will co exist with the current 3503members but will make auto_ptr_ref obsolete in initialization contexts. 3504auto_ptr_ref will be effective in assignment contexts as suggested in DR 3505#127 and I can't see any serious exception safety issues in those cases 3506(although it's possible to synthesize such). auto_ptr_ref<X> semantics will 3507have to be revised to say that it strictly holds pointer of type X and not 3508reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is 3509constructed from auto_ptr<X> in which X is different from Y (i.e. assignment 3510from r-value derived to base). 3511</p> 3512 3513<p><b>Proposed resolution:</b></p> 3514<p><i>[Redmond: punt for the moment. We haven't decided yet whether we 3515 want to fix auto_ptr for C++-0x, or remove it and replace it with 3516 move_ptr and unique_ptr.]</i></p> 3517<hr> 3518<a name="466"><h3>466. basic_string ctor should prevent null pointer error</h3></a><p><b>Section:</b> 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Daniel Frey <b>Date:</b> 10 Jun 2004</p> 3519<p> 3520Today, my colleagues and me wasted a lot of time. After some time, I 3521found the problem. It could be reduced to the following short example: 3522</p> 3523 3524<pre> #include <string> 3525 int main() { std::string( 0 ); } 3526</pre> 3527 3528<p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and 3529Comeau online) compile the above without errors or warnings! The 3530programs (at least for the GCC) resulted in a SEGV.</p> 3531 3532<p>I know that the standard explicitly states that the ctor of string 3533requires a char* which is not zero. STLs could easily detect the above 3534case with a private ctor for basic_string which takes a single 'int' 3535argument. This would catch the above code at compile time and would not 3536ambiguate any other legal ctors.</p> 3537 3538<p><b>Proposed resolution:</b></p> 3539<p><i>[Redmond: No great enthusiasm for doing this. If we do, 3540 however, we want to do it for all places that take <tt>charT*</tt> 3541 pointers, not just the single-argument constructor. The other 3542 question is whether we want to catch this at compile time (in which 3543 case we catch the error of a literal 0, but not an expression whose 3544 value is a null pointer), at run time, or both.]</i></p> 3545 3546<hr> 3547<a name="470"><h3>470. accessing containers from their elements' special functions</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p> 3548 3549<p> 3550The standard doesn't prohibit the destructors (or any other special 3551functions) of containers' elements invoked from a member function 3552of the container from "recursively" calling the same (or any other) 3553member function on the same container object, potentially while the 3554container is in an intermediate state, or even changing the state 3555of the container object while it is being modified. This may result 3556in some surprising (i.e., undefined) behavior. 3557</p> 3558 3559<p>Read email thread starting with c++std-lib-13637 for more.</p> 3560 3561<p><b>Proposed resolution:</b></p> 3562 3563<p>Add to Container Requirements the following new paragraph:</p> 3564 3565<pre> Unless otherwise specified, the behavior of a program that 3566 invokes a container member function f from a member function 3567 g of the container's value_type on a container object c that 3568 called g from its mutating member function h, is undefined. 3569 I.e., if v is an element of c, directly or indirectly calling 3570 c.h() from v.g() called from c.f(), is undefined. 3571</pre> 3572 3573<p><i>[Redmond: This is a real issue, but it's probably a clause 17 3574 issue, not clause 23. We get the same issue, for example, if we 3575 try to destroy a stream from one of the stream's callback functions.]</i></p> 3576 3577 3578<hr> 3579<a name="471"><h3>471. result of what() implementation-defined</h3></a><p><b>Section:</b> 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p> 3580 3581<p>[lib.exception] specifies the following:</p> 3582<pre> exception (const exception&) throw(); 3583 exception& operator= (const exception&) throw(); 3584 3585 -4- Effects: Copies an exception object. 3586 -5- Notes: The effects of calling what() after assignment 3587 are implementation-defined. 3588</pre> 3589 3590<p> 3591First, does the Note only apply to the assignment operator? If so, 3592what are the effects of calling what() on a copy of an object? Is 3593the returned pointer supposed to point to an identical copy of 3594the NTBS returned by what() called on the original object or not? 3595</p> 3596 3597<p> 3598Second, is this Note intended to extend to all the derived classes 3599in section 19? I.e., does the standard provide any guarantee for 3600the effects of what() called on a copy of any of the derived class 3601described in section 19? 3602</p> 3603 3604<p> 3605Finally, if the answer to the first question is no, I believe it 3606constitutes a defect since throwing an exception object typically 3607implies invoking the copy ctor on the object. If the answer is yes, 3608then I believe the standard ought to be clarified to spell out 3609exactly what the effects are on the copy (i.e., after the copy 3610ctor was called). 3611</p> 3612 3613<p><i>[Redmond: Yes, this is fuzzy. The issue of derived classes is 3614 fuzzy too.]</i></p> 3615 3616<p><b>Proposed resolution:</b></p> 3617<hr> 3618<a name="473"><h3>473. underspecified ctype calls</h3></a><p><b>Section:</b> 22.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype"> [lib.locale.ctype]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 1 Jul 2004</p> 3619<p> 3620Most ctype member functions come in two forms: one that operates 3621on a single character at a time and another form that operates 3622on a range of characters. Both forms are typically described by 3623a single Effects and/or Returns clause. 3624</p> 3625<p> 3626The Returns clause of each of the single-character non-virtual forms 3627suggests that the function calls the corresponding single character 3628virtual function, and that the array form calls the corresponding 3629virtual array form. Neither of the two forms of each virtual member 3630function is required to be implemented in terms of the other. 3631</p> 3632<p> 3633There are three problems: 3634</p> 3635<p> 36361. One is that while the standard does suggest that each non-virtual 3637member function calls the corresponding form of the virtual function, 3638it doesn't actually explicitly require it. 3639</p> 3640<p> 3641Implementations that cache results from some of the virtual member 3642functions for some or all values of their arguments might want to 3643call the array form from the non-array form the first time to fill 3644the cache and avoid any or most subsequent virtual calls. Programs 3645that rely on each form of the virtual function being called from 3646the corresponding non-virtual function will see unexpected behavior 3647when using such implementations. 3648</p> 3649<p> 36502. The second problem is that either form of each of the virtual 3651functions can be overridden by a user-defined function in a derived 3652class to return a value that is different from the one produced by 3653the virtual function of the alternate form that has not been 3654overriden. 3655</p> 3656<p> 3657Thus, it might be possible for, say, ctype::widen(c) to return one 3658value, while for ctype::widen(&c, &c + 1, &wc) to set 3659wc to another value. This is almost certainly not intended. Both 3660forms of every function should be required to return the same result 3661for the same character, otherwise the same program using an 3662implementation that calls one form of the functions will behave 3663differently than when using another implementation that calls the 3664other form of the function "under the hood." 3665</p> 3666<p> 36673. The last problem is that the standard text fails to specify whether 3668one form of any of the virtual functions is permitted to be implemented 3669in terms of the other form or not, and if so, whether it is required 3670or permitted to call the overridden virtual function or not. 3671</p> 3672<p> 3673Thus, a program that overrides one of the virtual functions so that 3674it calls the other form which then calls the base member might end 3675up in an infinite loop if the called form of the base implementation 3676of the function in turn calls the other form. 3677</p> 3678<p><b>Proposed resolution:</b></p> 3679 3680<p> 3681Lillehammer: Part of this isn't a real problem. We already talk about 3682caching. 22.1.1/6 But part is a real problem. ctype virtuals may call 3683each other, so users don't know which ones to override to avoid avoid 3684infinite loops.</p> 3685 3686<p>This is a problem for all facet virtuals, not just ctype virtuals, 3687so we probably want a blanket statement in clause 22 for all 3688facets. The LWG is leaning toward a blanket prohibition, that a 3689facet's virtuals may never call each other. We might want to do that 3690in clause 27 too, for that matter. A review is necessary. Bill will 3691provide wording.</p> 3692<hr> 3693<a name="479"><h3>479. Container requirements and placement new</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 1 Aug 2004</p> 3694<p>Nothing in the standard appears to make this program ill-formed:</p> 3695 3696<pre> struct C { 3697 void* operator new( size_t s ) { return ::operator new( s ); } 3698 // NOTE: this hides in-place and nothrow new 3699 }; 3700 3701 int main() { 3702 vector<C> v; 3703 v.push_back( C() ); 3704 } 3705</pre> 3706 3707<p>Is that intentional? We should clarify whether or not we intended 3708 to require containers to support types that define their own special 3709 versions of <tt>operator new</tt>.</p> 3710 3711<p><i>[ 3712Lillehammer: A container will definitely never use this overridden 3713operator new, but whether it will fail to compile is unclear from the 3714standard. Are containers supposed to use qualified or unqualified 3715placement new? 20.4.1.1 is somewhat relevant, but the standard 3716doesn't make it completely clear whether containers have to use 3717Allocator::construct(). If containers don't use it, the details of how 3718containers use placement new are unspecified. That is the real bug, 3719but it needs to be fixed as part of the allocator overhaul. Weak 3720support that the eventual solution should make this code well formed. 3721]</i></p> 3722 3723<p><b>Proposed resolution:</b></p> 3724<hr> 3725<a name="482"><h3>482. Swapping pairs</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>, 25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 14 Sep 2004</p> 3726<p>(Based on recent comp.std.c++ discussion)</p> 3727 3728<p>Pair (and tuple) should specialize std::swap to work in terms of 3729std::swap on their components. For example, there's no obvious reason 3730why swapping two objects of type pair<vector<int>, 3731list<double> > should not take O(1).</p> 3732<p><b>Proposed resolution:</b></p> 3733 3734 3735<p><i>[Lillehammer: We agree it should be swappable. Howard will 3736 provide wording.]</i></p> 3737 3738<hr> 3739<a name="484"><h3>484. Convertible to T</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 16 Sep 2004</p> 3740<p>From comp.std.c++:</p> 3741 3742<p> 3743I note that given an input iterator a for type T, 3744then *a only has to be "convertable to T", not actually of type T. 3745</p> 3746 3747<p>Firstly, I can't seem to find an exact definition of "convertable to T". 3748While I assume it is the obvious definition (an implicit conversion), I 3749can't find an exact definition. Is there one?</p> 3750 3751<p>Slightly more worryingly, there doesn't seem to be any restriction on 3752the this type, other than it is "convertable to T". Consider two input 3753iterators a and b. I would personally assume that most people would 3754expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that 3755the standard requires that, and that whatever type *a is (call it U) 3756could have == defined on it with totally different symantics and still 3757be a valid inputer iterator.</p> 3758 3759<p>Is this a correct reading? When using input iterators should I write 3760T(*a) all over the place to be sure that the object i'm using is the 3761class I expect?</p> 3762 3763<p>This is especially a nuisance for operations that are defined to be 3764 "convertible to bool". (This is probably allowed so that 3765 implementations could return say an int and avoid an unnessary 3766 conversion. However all implementations I have seen simply return a 3767 bool anyway. Typical implemtations of STL algorithms just write 3768 things like <tt>while(a!=b && *a!=0)</tt>. But strictly 3769 speaking, there are lots of types that are convertible to T but 3770 that also overload the appropriate operators so this doesn't behave 3771 as expected.</p> 3772 3773<p>If we want to make code like this legal (which most people seem to 3774 expect), then we'll need to tighten up what we mean by "convertible 3775 to T".</p> 3776 3777<p><b>Proposed resolution:</b></p> 3778<p><i>[Lillehammer: The first part is NAD, since "convertible" is 3779 well-defined in core. The second part is basically about pathological 3780 overloads. It's a minor problem but a real one. So leave open for 3781 now, hope we solve it as part of iterator redesign.]</i></p> 3782<hr> 3783<a name="485"><h3>485. output iterator insufficently constrained</h3></a><p><b>Section:</b> 24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 13 Oct 2004</p> 3784<p> 3785The note on 24.1.2 Output iterators insufficently limits what can be 3786performed on output iterators. While it requires that each iterator is 3787progressed through only once and that each iterator is written to only 3788once, it does not require the following things:</p> 3789 3790<p>Note: Here it is assumed that x is an output iterator of type X which 3791has not yet been assigned to.</p> 3792 3793<p>a) That each value of the output iterator is written to: 3794The standard allows: 3795++x; ++x; ++x; 3796</p> 3797 3798<p> 3799b) That assignments to the output iterator are made in order 3800X a(x); ++a; *a=1; *x=2; is allowed 3801</p> 3802 3803<p> 3804c) Chains of output iterators cannot be constructed: 3805X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current 3806wording (I believe) x,a,b,c could be written to in any order. 3807</p> 3808 3809<p>I do not believe this was the intension of the standard?</p> 3810<p><b>Proposed resolution:</b></p> 3811<p><i>[Lillehammer: Real issue. There are lots of constraints we 3812 intended but didn't specify. Should be solved as part of iterator 3813 redesign.]</i></p> 3814<hr> 3815<a name="488"><h3>488. rotate throws away useful information</h3></a><p><b>Section:</b> 25.2.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.rotate"> [lib.alg.rotate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 22 Nov 2004</p> 3816<p> 3817rotate takes 3 iterators: first, middle and last which point into a 3818sequence, and rearranges the sequence such that the subrange [middle, 3819last) is now at the beginning of the sequence and the subrange [first, 3820middle) follows. The return type is void. 3821</p> 3822 3823<p> 3824In many use cases of rotate, the client needs to know where the 3825subrange [first, middle) starts after the rotate is performed. This 3826might look like: 3827</p> 3828<pre> rotate(first, middle, last); 3829 Iterator i = advance(first, distance(middle, last)); 3830</pre> 3831 3832<p> 3833Unless the iterators are random access, the computation to find the 3834start of the subrange [first, middle) has linear complexity. However, 3835it is not difficult for rotate to return this information with 3836negligible additional computation expense. So the client could code: 3837</p> 3838<pre> Iterator i = rotate(first, middle, last); 3839</pre> 3840 3841<p> 3842and the resulting program becomes significantly more efficient. 3843</p> 3844 3845<p> 3846While the backwards compatibility hit with this change is not zero, it 3847is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is 3848a significant benefit to the change. 3849</p> 3850 3851<p><b>Proposed resolution:</b></p> 3852<p>In 25p2, change:</p> 3853<pre> template<class ForwardIterator> 3854 void rotate(ForwardIterator first, ForwardIterator middle, 3855 ForwardIterator last); 3856</pre> 3857 3858<p>to:</p> 3859 3860<pre> template<class ForwardIterator> 3861 ForwardIterator rotate(ForwardIterator first, ForwardIterator middle, 3862 ForwardIterator last); 3863</pre> 3864 3865<p>In 25.2.10, change:</p> 3866 3867<pre> template<class ForwardIterator> 3868 void rotate(ForwardIterator first, ForwardIterator middle, 3869 ForwardIterator last); 3870</pre> 3871 3872<p>to:</p> 3873 3874<pre> template<class ForwardIterator> 3875 ForwardIterator rotate(ForwardIterator first, ForwardIterator middle, 3876 ForwardIterator last); 3877</pre> 3878 3879<p>In 25.2.10 insert a new paragraph after p1:</p> 3880 3881<blockquote> 3882<p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p> 3883</blockquote> 3884 3885<p><i>[ 3886The LWG agrees with this idea, but has one quibble: we want to make 3887sure not to give the impression that the function "advance" is 3888actually called, just that the nth iterator is returned. (Calling 3889advance is observable behavior, since users can specialize it for 3890their own iterators.) Howard will provide wording. 3891]</i></p> 3892 3893<p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p> 3894 3895<hr> 3896<a name="492"><h3>492. Invalid iterator arithmetic expressions</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a>, 24 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterators"> [lib.iterators]</a>, 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p> 3897<p>Various clauses other than clause 25 make use of iterator arithmetic not 3898supported by the iterator category in question. 3899Algorithms in clause 25 are exceptional because of 25 [lib.algorithms], 3900paragraph 9, but this paragraph does not provide semantics to the 3901expression "iterator - n", where n denotes a value of a distance type 3902between iterators.</p> 3903 3904<p>1) Examples of current wording:</p> 3905 3906<p>Current wording outside clause 25:</p> 3907 3908<p> 390923.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)", 3910"(last - first)" 391123.3.1.1 [lib.map.cons], paragraph 4: "last - first" 391223.3.2.1 [lib.multimap.cons], paragraph 4: "last - first" 391323.3.3.1 [lib.set.cons], paragraph 4: "last - first" 391423.3.4.1 [lib.multiset.cons], paragraph 4: "last - first" 391524.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)" 3916</p> 3917 3918<p> 3919[Important note: The list is not complete, just an illustration. The 3920same issue might well apply to other paragraphs not listed here.]</p> 3921 3922<p>None of these expressions is valid for the corresponding iterator 3923category.</p> 3924 3925<p>Current wording in clause 25:</p> 3926 3927<p> 392825.1.1 [lib.alg.foreach], paragraph 1: "last - 1" 392925.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 - 3930(last2-first2))" 393125.2.8 [lib.alg.unique], paragraph 1: "(i - 1)" 393225.2.8 [lib.alg.unique], paragraph 5: "(i - 1)" 3933</p> 3934 3935<p> 3936However, current wording of 25 [lib.algorithms], paragraph 9 covers 3937neither of these four cases:</p> 3938 3939<p>Current wording of 25 [lib.algorithms], paragraph 9:</p> 3940 3941<p> 3942"In the description of the algorithms operator + and - are used for some 3943of the iterator categories for which they do not have to be defined. In 3944these cases the semantics of a+n is the same as that of</p> 3945<pre>{X tmp = a; 3946advance(tmp, n); 3947return tmp; 3948} 3949</pre> 3950<p>and that of b-a is the same as of return distance(a, b)"</p> 3951 3952<p> 3953This paragrpah does not take the expression "iterator - n" into account, 3954where n denotes a value of a distance type between two iterators [Note: 3955According to current wording, the expression "iterator - n" would be 3956resolved as equivalent to "return distance(n, iterator)"]. Even if the 3957expression "iterator - n" were to be reinterpreted as equivalent to 3958"iterator + -n" [Note: This would imply that "a" and "b" were 3959interpreted implicitly as values of iterator types, and "n" as value of 3960a distance type], then 24.3.4/2 interfers because it says: "Requires: n 3961may be negative only for random access and bidirectional iterators.", 3962and none of the paragraphs quoted above requires the iterators on which 3963the algorithms operate to be of random access or bidirectional category. 3964</p> 3965 3966<p>2) Description of intended behavior:</p> 3967 3968<p> 3969For the rest of this Defect Report, it is assumed that the expression 3970"iterator1 + n" and "iterator1 - iterator2" has the semantics as 3971described in current 25 [lib.algorithms], paragraph 9, but applying to 3972all clauses. The expression "iterator1 - n" is equivalent to an 3973result-iterator for which the expression "result-iterator + n" yields an 3974iterator denoting the same position as iterator1 does. The terms 3975"iterator1", "iterator2" and "result-iterator" shall denote the value of 3976an iterator type, and the term "n" shall denote a value of a distance 3977type between two iterators.</p> 3978 3979<p> 3980All implementations known to the author of this Defect Report comply 3981with these assumptions. 3982No impact on current code is expected.</p> 3983 3984<p>3) Proposed fixes:</p> 3985 3986 3987<p>Change 25 [lib.algorithms], paragraph 9 to:</p> 3988 3989<p> 3990"In the description of the algorithms operator + and - are used for some 3991of the iterator categories for which they do not have to be defined. In 3992this paragraph, a and b denote values of an iterator type, and n denotes 3993a value of a distance type between two iterators. In these cases the 3994semantics of a+n is the same as that of</p> 3995<pre>{X tmp = a; 3996advance(tmp, n); 3997return tmp; 3998} 3999</pre> 4000<p>,the semantics of a-n denotes the value of an iterator i for which the 4001following condition holds: 4002advance(i, n) == a, 4003and that of b-a is the same as of 4004return distance(a, b)". 4005</p> 4006 4007<p>Comments to the new wording:</p> 4008 4009<p> 4010a) The wording " In this paragraph, a and b denote values of an iterator 4011type, and n denotes a value of a distance type between two iterators." 4012was added so the expressions "b-a" and "a-n" are distinguished regarding 4013the types of the values on which they operate. 4014b) The wording ",the semantics of a-n denotes the value of an iterator i 4015for which the following condition holds: advance(i, n) == a" was added 4016to cover the expression 'iterator - n'. The wording "advance(i, n) == a" 4017was used to avoid a dependency on the semantics of a+n, as the wording 4018"i + n == a" would have implied. However, such a dependency might well 4019be deserved. 4020c) DR 225 is not considered in the new wording. 4021</p> 4022 4023<p> 4024Proposed fixes regarding invalid iterator arithmetic expressions outside 4025clause 25:</p> 4026 4027<p> 4028Either 4029a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above) 4030before any current invalid iterator arithmetic expression. In that case, 4031the first sentence of 25 [lib.algorithms], paragraph 9, need also to be 4032modified and could read: "For the rest of this International Standard, 4033...." / "In the description of the following clauses including this 4034...." / "In the description of the text below ..." etc. - anyways 4035substituting the wording "algorithms", which is a straight reference to 4036clause 25. 4037In that case, 25 [lib.algorithms] paragraph 9 will certainly become 4038obsolete. 4039Alternatively, 4040b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms], 4041paragraph 9, to the beginning of each clause containing invalid iterator 4042arithmetic expressions. 4043Alternatively, 4044c) Fix each paragraph (both current wording and possible resolutions of 4045DRs) containing invalid iterator arithmetic expressions separately. 4046</p> 4047 4048<p>5) References to other DRs:</p> 4049 4050<p> 4051See DR 225. 4052See DR 237. The resolution could then also read "Linear in last - 4053first". 4054</p> 4055<p><b>Proposed resolution:</b></p> 4056 4057<p><i>[Lillehammer: Minor issue, but real. We have a blanket statement 4058about this in 25/11. But (a) it should be in 17, not 25; and (b) it's 4059not quite broad enough, because there are some arithmetic expressions 4060it doesn't cover. Bill will provide wording.]</i></p> 4061 4062<hr> 4063<a name="498"><h3>498. Requirements for partition() and stable_partition() too strong</h3></a><p><b>Section:</b> 25.2.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.partitions"> [lib.alg.partitions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 4 May 2005</p> 4064<p> 4065Problem: 4066The iterator requirements for partition() and stable_partition() [25.2.12] 4067are listed as BidirectionalIterator, however, there are efficient algorithms 4068for these functions that only require ForwardIterator that have been known 4069since before the standard existed. The SGI implementation includes these (see 4070<a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a> 4071and 4072<a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>). 4073</p> 4074<p><b>Proposed resolution:</b></p> 4075<p> 4076Change 25.2.12 from </p> 4077<blockquote><pre>template<class BidirectionalIterator, class Predicate> 4078BidirectionalIterator partition(BidirectionalIterato r first, 4079 BidirectionalIterator last, 4080 Predicate pred); 4081</pre></blockquote> 4082<p>to </p> 4083<blockquote><pre>template<class ForwardIterator, class Predicate> 4084ForwardIterator partition(ForwardIterator first, 4085 ForwardIterator last, 4086 Predicate pred); 4087</pre></blockquote> 4088<p>Change the complexity from </p> 4089 4090<blockquote><p> 4091At most (last - first)/2 swaps are done. Exactly (last - first) 4092applications of the predicate are done. 4093</p></blockquote> 4094 4095<p>to </p> 4096 4097<blockquote><p> 4098If ForwardIterator is a bidirectional_iterator, at most (last - first)/2 4099swaps are done; otherwise at most (last - first) swaps are done. Exactly 4100(last - first) applications of the predicate are done. 4101</p></blockquote> 4102 4103<p><b>Rationale:</b></p> 4104Partition is a "foundation" algorithm useful in many contexts (like sorting 4105as just one example) - my motivation for extending it to include forward 4106iterators is slist - without this extension you can't partition an slist 4107(without writing your own partition). Holes like this in the standard 4108library weaken the argument for generic programming (ideally I'd be able 4109to provide a library that would refine std::partition() to other concepts 4110without fear of conflicting with other libraries doing the same - but 4111that is a digression). I consider the fact that partition isn't defined 4112to work for ForwardIterator a minor embarrassment. 4113 4114<p><i>[Mont Tremblant: Moved to Open, request motivation and use cases 4115by next meeting. Sean provided further rationale by post-meeting 4116mailing.]</i></p> 4117 4118<hr> 4119<a name="502"><h3>502. Proposition: Clarification of the interaction between a facet and an iterator</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 7 Jun 2005</p> 4120<p> 4121Motivation: 4122</p> 4123 4124<p> 4125This requirement seems obvious to me, it is the essence of code modularity. 4126I have complained to Mr. Plauger that the Dinkumware library does not 4127observe this principle but he objected that this behaviour is not covered in 4128the standard. 4129</p> 4130<p><b>Proposed resolution:</b></p> 4131<p> 4132Append the following point to 22.1.1.1.1: 4133</p> 4134 4135<p> 41366. The implementation of a facet of Table 52 parametrized with an 4137InputIterator/OutputIterator should use that iterator only as character 4138source/sink respectively. 4139For a *_get facet, it means that the value received depends only on the 4140sequence of input characters and not on how they are accessed. 4141For a *_put facet, it means that the sequence of characters output depends 4142only on the value to be formatted and not of how the characters are stored. 4143</p> 4144 4145<p><i>[ 4146Berlin: Moved to Open, Need to clean up this area to make it clear 4147locales don't have to contain open ended sets of facets. Jack, Howard, 4148Bill. 4149]</i></p> 4150<hr> 4151<a name="503"><h3>503. more on locales</h3></a><p><b>Section:</b> 22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 20 Jun 2005</p> 4152<p> 4153a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table 415451" to refer to the facet *objects* associated with a locale. And we 4155almost certainly mean just those associated with the default or "C" 4156locale. Otherwise, you can't switch to a locale that enforces a different 4157mapping between narrow and wide characters, or that defines additional 4158uppercase characters. 4159</p> 4160 4161<p> 4162b) 22.2.1.5 para. 3 (codecvt) has the same issues. 4163</p> 4164 4165<p> 4166c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of 4167a homing sequence for the basic character set, which might very well need 4168one. 4169</p> 4170 4171<p> 4172d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping 4173between wide and narrow characters be taken as one-for-one. 4174</p> 4175 4176<p> 4177e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as 4178I can tell. The muddle is, as before, calling Table 51 a list of 4179instantiations. But the constraint it applies seems to me to cover 4180*all* defined uses of num_get/put, so why bother to say so? 4181</p> 4182 4183<p> 4184f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations 4185return '.' or L'.'.) Presumably this means "as appropriate for the 4186character type. But given the vague definition of "required" earlier, 4187this overrules *any* change of decimal point for non "C" locales. 4188Surely we don't want to do that. 4189</p> 4190 4191<p> 4192g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations 4193return ',' or L','.) As above, this probably means "as appropriate for the 4194character type. But this overrules the "C" locale, which requires *no* 4195character ('\0') for the thousands separator. Even if we agree that we 4196don't mean to block changes in decimal point or thousands separator, 4197we should also eliminate this clear incompatibility with C. 4198</p> 4199 4200<p> 4201h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations 4202return the empty string, indicating no grouping." Same considerations 4203as for do_decimal_point. 4204</p> 4205 4206<p> 4207i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table 420851". Same bad jargon. 4209</p> 4210 4211<p> 4212j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required 4213in Table 51". Same bad jargon. 4214</p> 4215 4216<p> 4217k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous 4218as num_get/put. 4219</p> 4220 4221<p> 4222l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous 4223as num_get/put. 4224</p> 4225 4226<p> 4227m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required 4228in Table 51 ... return an object of type pattern initialized to 4229{symbol, sign, none, value}." This once again *overrides* the "C" 4230locale, as well as any other locale." 4231</p> 4232 4233<p> 42343) We constrain the use_facet calls that can be made by num_get/put, 4235so why don't we do the same for money_get/put? Or for any of the 4236other facets, for that matter? 4237</p> 4238 4239<p> 42404) As an almost aside, we spell out when a facet needs to use the ctype 4241facet, but several also need to use a codecvt facet and we don't say so. 4242</p> 4243<p><b>Proposed resolution:</b></p> 4244<p> 4245</p> 4246<p><i>[ 4247Berlin: Bill to provide wording. 4248]</i></p> 4249<hr> 4250<a name="515"><h3>515. Random number engine traits</h3></a><p><b>Section:</b> TR1 5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.synopsis"> [tr.rand.synopsis]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> 4251<p> 4252To accompany the concept of a pseudo-random number engine as defined in Table 17, 4253we propose and recommend an adjunct template, engine_traits, to be declared in 4254[tr.rand.synopsis] as: 4255</p> 4256<blockquote><pre>template< class PSRE > 4257class engine_traits; 4258</pre></blockquote> 4259<p> 4260This template�s primary purpose would be as an aid to generic programming involving 4261pseudo-random number engines. Given only the facilities described in tr1, it would 4262be very difficult to produce any algorithms involving the notion of a generic engine. 4263The intent of this proposal is to provide, via engine_traits<>, sufficient 4264descriptive information to allow an algorithm to employ a pseudo-random number engine 4265without regard to its exact type, i.e., as a template parameter. 4266</p> 4267<p> 4268For example, today it is not possible to write an efficient generic function that 4269requires any specific number of random bits. More specifically, consider a 4270cryptographic application that internally needs 256 bits of randomness per call: 4271</p> 4272<blockquote><pre>template< class Eng, class InIter, class OutIter > 4273void crypto( Eng& e, InIter in, OutIter out ); 4274</pre></blockquote> 4275<p> 4276Without knowning the number of bits of randomness produced per call to a provided 4277engine, the algorithm has no means of determining how many times to call the engine. 4278</p> 4279<p> 4280In a new section [tr.rand.eng.traits], we proposed to define the engine_traits 4281template as: 4282</p> 4283<blockquote><pre>template< class PSRE > 4284class engine_traits 4285{ 4286 static std::size_t bits_of_randomness = 0u; 4287 static std::string name() { return "unknown_engine"; } 4288 // TODO: other traits here 4289}; 4290</pre></blockquote> 4291<p> 4292Further, each engine described in [tr.rand.engine] would be accompanied by a 4293complete specialization of this new engine_traits template. 4294</p> 4295<p><b>Proposed resolution:</b></p> 4296<p> 4297 4298</p> 4299 4300<p><i>[ 4301Berlin: Walter: While useful for implementation per TR1, N1932 has no need for this 4302feature. 4303]</i></p> 4304 4305<hr> 4306<a name="518"><h3>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3></a><p><b>Section:</b> TR1 6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.hash"> [tr.hash]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 3 Jul 2005</p> 4307<p> 4308Issue 371 deals with stability of multiset/multimap under insert and erase 4309(i.e. do they preserve the relative order in ranges of equal elements). 4310The same issue applies to unordered_multiset and unordered_multimap. 4311</p> 4312<p><b>Proposed resolution:</b></p> 4313<p><i>[ 4314Moved to open (from review): There is no resolution. 4315]</i></p> 4316 4317<p> 4318</p> 4319<hr> 4320<a name="522"><h3>522. Tuple doesn't define swap</h3></a><p><b>Section:</b> TR1 6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple"> [tr.tuple]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andy Koenig <b>Date:</b> 3 Jul 2005</p> 4321<p> 4322Tuple doesn't define swap(). It should. 4323</p> 4324<p><i>[ 4325Berlin: Doug to provide wording. 4326]</i></p> 4327 4328<p><b>Proposed resolution:</b></p> 4329<hr> 4330<a name="523"><h3>523. regex case-insensitive character ranges are unimplementable as specified</h3></a><p><b>Section:</b> TR1 7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.re"> [tr.re]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Eric Niebler <b>Date:</b> 1 Jul 2005</p> 4331<p> 4332A problem with TR1 regex is currently being discussed on the Boost 4333developers list. It involves the handling of case-insensitive matching 4334of character ranges such as [Z-a]. The proper behavior (according to the 4335ECMAScript standard) is unimplementable given the current specification 4336of the TR1 regex_traits<> class template. John Maddock, the author of 4337the TR1 regex proposal, agrees there is a problem. The full discussion 4338can be found at http://lists.boost.org/boost/2005/06/28850.php (first 4339message copied below). We don't have any recommendations as yet. 4340</p> 4341<p> 4342-- Begin original message -- 4343</p> 4344<p> 4345The situation of interest is described in the ECMAScript specification 4346(ECMA-262), section 15.10.2.15: 4347</p> 4348<p> 4349"Even if the pattern ignores case, the case of the two ends of a range 4350is significant in determining which characters belong to the range. 4351Thus, for example, the pattern /[E-F]/i matches only the letters E, F, 4352e, and f, while the pattern /[E-f]/i matches all upper and lower-case 4353ASCII letters as well as the symbols [, \, ], ^, _, and `." 4354</p> 4355<p> 4356A more interesting case is what should happen when doing a 4357case-insentitive match on a range such as [Z-a]. It should match z, Z, 4358a, A and the symbols [, \, ], ^, _, and `. This is not what happens with 4359Boost.Regex (it throws an exception from the regex constructor). 4360</p> 4361<p> 4362The tough pill to swallow is that, given the specification in TR1, I 4363don't think there is any effective way to handle this situation. 4364According to the spec, case-insensitivity is handled with 4365regex_traits<>::translate_nocase(CharT) -- two characters are equivalent 4366if they compare equal after both are sent through the translate_nocase 4367function. But I don't see any way of using this translation function to 4368make character ranges case-insensitive. Consider the difficulty of 4369detecting whether "z" is in the range [Z-a]. Applying the transformation 4370to "z" has no effect (it is essentially std::tolower). And we're not 4371allowed to apply the transformation to the ends of the range, because as 4372ECMA-262 says, "the case of the two ends of a range is significant." 4373</p> 4374<p> 4375So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix 4376is to redefine translate_nocase to return a string_type containing all 4377the characters that should compare equal to the specified character. But 4378this function is hard to implement for Unicode, and it doesn't play nice 4379with the existing ctype facet. What a mess! 4380</p> 4381<p> 4382-- End original message -- 4383</p> 4384 4385<p><i>[ 4386John Maddock adds: 4387]</i></p> 4388 4389<p> 4390One small correction, I have since found that ICU's regex package does 4391implement this correctly, using a similar mechanism to the current 4392TR1.Regex. 4393</p> 4394<p> 4395Given an expression [c1-c2] that is compiled as case insensitive it: 4396</p> 4397<p> 4398Enumerates every character in the range c1 to c2 and converts it to it's 4399case folded equivalent. That case folded character is then used a key to a 4400table of equivalence classes, and each member of the class is added to the 4401list of possible matches supported by the character-class. This second step 4402isn't possible with our current traits class design, but isn't necessary if 4403the input text is also converted to a case-folded equivalent on the fly. 4404</p> 4405<p> 4406ICU applies similar brute force mechanisms to character classes such as 4407[[:lower:]] and [[:word:]], however these are at least cached, so the impact 4408is less noticeable in this case. 4409</p> 4410<p> 4411Quick and dirty performance comparisons show that expressions such as 4412"[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times 4413slower than a "normal" expression). For an application that uses a lot of 4414regexes this could have a noticeable performance impact. ICU also has an 4415advantage in that it knows the range of valid characters codes: code points 4416outside that range are assumed not to require enumeration, as they can not 4417be part of any equivalence class. I presume that if we want the TR1.Regex 4418to work with arbitrarily large character sets enumeration really does become 4419impractical. 4420</p> 4421<p> 4422Finally note that Unicode has: 4423</p> 4424<p> 4425Three cases (upper, lower and title). 4426One to many, and many to one case transformations. 4427Character that have context sensitive case translations - for example an 4428uppercase sigma has two different lowercase forms - the form chosen depends 4429on context(is it end of a word or not), a caseless match for an upper case 4430sigma should match either of the lower case forms, which is why case folding 4431is often approximated by tolower(toupper(c)). 4432</p> 4433<p> 4434Probably we need some way to enumerate character equivalence classes, 4435including digraphs (either as a result or an input), and some way to tell 4436whether the next character pair is a valid digraph in the current locale. 4437</p> 4438<p> 4439Hoping this doesn't make this even more complex that it was already, 4440</p> 4441 4442<p><i>[ 4443Portland: Alisdair: Detect as invalid, throw an exception. 4444Pete: Possible general problem with case insensitive ranges. 4445]</i></p> 4446 4447<p><b>Proposed resolution:</b></p> 4448<hr> 4449<a name="524"><h3>524. regex named character classes and case-insensitivity don't mix</h3></a><p><b>Section:</b> TR1 7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.re"> [tr.re]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Eric Niebler <b>Date:</b> 1 Jul 2005</p> 4450<p> 4451This defect is also being discussed on the Boost developers list. The 4452full discussion can be found here: 4453http://lists.boost.org/boost/2005/07/29546.php 4454</p> 4455<p> 4456-- Begin original message -- 4457</p> 4458<p> 4459Also, I may have found another issue, closely related to the one under 4460discussion. It regards case-insensitive matching of named character 4461classes. The regex_traits<> provides two functions for working with 4462named char classes: lookup_classname and isctype. To match a char class 4463such as [[:alpha:]], you pass "alpha" to lookup_classname and get a 4464bitmask. Later, you pass a char and the bitmask to isctype and get a 4465bool yes/no answer. 4466</p> 4467<p> 4468But how does case-insensitivity work in this scenario? Suppose we're 4469doing a case-insensitive match on [[:lower:]]. It should behave as if it 4470were [[:lower:][:upper:]], right? But there doesn't seem to be enough 4471smarts in the regex_traits interface to do this. 4472</p> 4473<p> 4474Imagine I write a traits class which recognizes [[:fubar:]], and the 4475"fubar" char class happens to be case-sensitive. How is the regex engine 4476to know that? And how should it do a case-insensitive match of a 4477character against the [[:fubar:]] char class? John, can you confirm this 4478is a legitimate problem? 4479</p> 4480<p> 4481I see two options: 4482</p> 4483<p> 44841) Add a bool icase parameter to lookup_classname. Then, 4485lookup_classname( "upper", true ) will know to return lower|upper 4486instead of just upper. 4487</p> 4488<p> 44892) Add a isctype_nocase function 4490</p> 4491<p> 4492I prefer (1) because the extra computation happens at the time the 4493pattern is compiled rather than when it is executed. 4494</p> 4495<p> 4496-- End original message -- 4497</p> 4498 4499<p> 4500For what it's worth, John has also expressed his preference for option 4501(1) above. 4502</p> 4503<p><b>Proposed resolution:</b></p> 4504<hr> 4505<a name="525"><h3>525. type traits definitions not clear</h3></a><p><b>Section:</b> TR1 4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.meta.unary"> [tr.meta.unary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 11 Jul 2005</p> 4506<p> 4507It is not completely clear how the primary type traits deal with 4508cv-qualified types. And several of the secondary type traits 4509seem to be lacking a definition. 4510</p> 4511 4512<p><i>[ 4513Berlin: Howard to provide wording. 4514]</i></p> 4515<p><b>Proposed resolution:</b></p> 4516<hr> 4517<a name="526"><h3>526. Is it undefined if a function in the standard changes in parameters?</h3></a><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 14 Sep 2005</p> 4518<p> 4519Problem: There are a number of places in the C++ standard library where 4520it is possible to write what appear to be sensible ways of calling 4521functions, but which can cause problems in some (or all) 4522implementations, as they cause the values given to the function to be 4523changed in a way not specified in standard (and therefore not coded to 4524correctly work). These fall into two similar categories. 4525</p> 4526 4527<p> 45281) Parameters taken by const reference can be changed during execution 4529of the function 4530</p> 4531 4532<p> 4533Examples: 4534</p> 4535 4536<p> 4537Given std::vector<int> v: 4538</p> 4539<p> 4540v.insert(v.begin(), v[2]); 4541</p> 4542<p> 4543v[2] can be changed by moving elements of vector 4544</p> 4545 4546 4547<p> 4548Given std::list<int> l: 4549</p> 4550<p> 4551l.remove(*l.begin()); 4552</p> 4553<p> 4554Will delete the first element, and then continue trying to access it. 4555This is particularily vicious, as it will appear to work in almost all 4556cases. 4557</p> 4558 4559<p> 45602) A range is given which changes during the execution of the function: 4561Similarly, 4562</p> 4563 4564<p> 4565v.insert(v.begin(), v.begin()+4, v.begin()+6); 4566</p> 4567 4568<p> 4569This kind of problem has been partly covered in some cases. For example 4570std::copy(first, last, result) states that result cannot be in the range 4571[first, last). However, does this cover the case where result is a 4572reverse_iterator built from some iterator in the range [first, last)? 4573Also, std::copy would still break if result was reverse_iterator(last + 45741), yet this is not forbidden by the standard 4575</p> 4576 4577<p> 4578Solution: 4579</p> 4580 4581<p> 4582One option would be to try to more carefully limit the requirements of 4583each function. There are many functions which would have to be checked. 4584However as has been shown in the std::copy case, this may be difficult. 4585A simpler, more global option would be to somewhere insert text similar to: 4586</p> 4587 4588<p> 4589If the execution of any function would change either any values passed 4590by reference or any value in any range passed to a function in a way not 4591defined in the definition of that function, the result is undefined. 4592</p> 4593 4594<p> 4595Such code would have to at least cover chapters 23 and 25 (the sections 4596I read through carefully). I can see no harm on applying it to much of 4597the rest of the standard. 4598</p> 4599 4600<p> 4601Some existing parts of the standard could be improved to fit with this, 4602for example the requires for 25.2.1 (Copy) could be adjusted to: 4603</p> 4604 4605<p> 4606Requires: For each non-negative integer n < (last - first), assigning to 4607*(result + n) must not alter any value in the range [first + n, last). 4608</p> 4609 4610<p> 4611However, this may add excessive complication. 4612</p> 4613 4614<p> 4615One other benefit of clearly introducing this text is that it would 4616allow a number of small optimisations, such as caching values passed 4617by const reference. 4618</p> 4619 4620<p> 4621Matt Austern adds that this issue also exists for the <tt>insert</tt> and 4622<tt>erase</tt> members of the ordered and unordered associative containers. 4623</p> 4624 4625<p><i>[ 4626Berlin: Lots of controversey over how this should be solved. Lots of confusion 4627as to whether we're talking about self referencing iterators or references. 4628Needs a good survey as to the cases where this matters, for which 4629implementations, and how expensive it is to fix each case. 4630]</i></p> 4631 4632<p><b>Proposed resolution:</b></p> 4633<p> 4634</p> 4635<hr> 4636<a name="527"></a><h3><a name="527">527. tr1::bind has lost its Throws clause</a></h3><p><b>Section:</b> TR1 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind.bind"> [tr.func.bind.bind]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 01 Oct 2005</p> 4637<p> 4638The original bind proposal gives the guarantee that tr1::bind(f, t1, 4639..., tN) does not throw when the copy constructors of f, t1, ..., tN 4640don't. 4641</p> 4642 4643<p> 4644This guarantee is not present in the final version of TR1. 4645</p> 4646 4647<p> 4648I'm pretty certain that we never removed it on purpose. Editorial omission? :-) 4649</p> 4650 4651<p><i>[ 4652Berlin: not quite editorial, needs proposed wording. 4653]</i></p> 4654 4655<p><b>Proposed resolution:</b></p> 4656<p> 4657In 20.5.10.1.3 [lib.func.bind.bind] ([tr.func.bind.bind]), add a new paragraph after p2: 4658</p> 4659<blockquote> 4660<i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt> 4661throws an exception. 4662</blockquote> 4663 4664<p> 4665Add a new paragraph after p4: 4666</p> 4667<blockquote> 4668<i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt> 4669throws an exception. 4670</blockquote> 4671<hr> 4672<a name="528"><h3>528. TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)</h3></a><p><b>Section:</b> TR1 6.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.unord.unord"> [tr.unord.unord]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 12 Oct 2005</p> 4673<p> 4674while implementing the resolution of issue 6.19 I'm noticing the 4675following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and 4676unordered_multiset: 4677</p> 4678 4679<blockquote> 4680 "The iterator and const_iterator types are both const types. It is 4681unspecified whether they are the same type" 4682</blockquote> 4683 4684<p> 4685Now, according to the resolution of 6.19, we have overloads of insert 4686with hint and erase (single and range) both for iterator and 4687const_iterator, which, AFAICS, can be meaningful at the same time *only* 4688if iterator and const_iterator *are* in fact different types. 4689</p> 4690<p> 4691Then, iterator and const_iterator are *required* to be different types? 4692Or that is an unintended consequence? Maybe the overloads for plain 4693iterators should be added only to unordered_map and unordered_multimap? 4694Or, of course, I'm missing something? 4695</p> 4696 4697<p><b>Proposed resolution:</b></p> 4698<p> 4699Add to 6.3.4.3p2 (and 6.3.4.5p2): 4700</p> 4701<p> 47022 ... The iterator and const_iterator types are both <del>const</del> 4703<ins>constant</ins> iterator types. 4704It is unspecified whether they are the same type. 4705</p> 4706 4707<p> 4708Add a new subsection to 17.4.4 [lib.conforming]: 4709</p> 4710 4711<blockquote> 4712<p> 4713An implementation shall not supply an overloaded function 4714 signature specified in any library clause if such a signature 4715 would be inherently ambiguous during overload resolution 4716 due to two library types referring to the same type. 4717</p> 4718<p> 4719 [Note: For example, this occurs when a container's iterator 4720 and const_iterator types are the same. -- end note] 4721</p> 4722</blockquote> 4723 4724<p><i>[ 4725Post-Berlin: Beman supplied wording. 4726]</i></p> 4727 4728<hr> 4729<a name="529"><h3>529. The standard encourages redundant and confusing preconditions</h3></a><p><b>Section:</b> 17.4.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.required"> [lib.res.on.required]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 25 Oct 2005</p> 4730<p> 473117.4.3.8/1 says: 4732</p> 4733 4734<blockquote> 4735Violation of the preconditions specified in a function's 4736Required behavior: paragraph results in undefined behavior unless the 4737function's Throws: paragraph specifies throwing an exception when the 4738precondition is violated. 4739</blockquote> 4740 4741<p> 4742This implies that a precondition violation can lead to defined 4743behavior. That conflicts with the only reasonable definition of 4744precondition: that a violation leads to undefined behavior. Any other 4745definition muddies the waters when it comes to analyzing program 4746correctness, because precondition violations may be routinely done in 4747correct code (e.g. you can use std::vector::at with the full 4748expectation that you'll get an exception when your index is out of 4749range, catch the exception, and continue). Not only is it a bad 4750example to set, but it encourages needless complication and redundancy 4751in the standard. For example: 4752</p> 4753 4754<blockquote><pre> 21 Strings library 4755 21.3.3 basic_string capacity 4756 4757 void resize(size_type n, charT c); 4758 4759 5 Requires: n <= max_size() 4760 6 Throws: length_error if n > max_size(). 4761 7 Effects: Alters the length of the string designated by *this as follows: 4762</pre></blockquote> 4763 4764<p> 4765The Requires clause is entirely redundant and can be dropped. We 4766could make that simplifying change (and many others like it) even 4767without changing 17.4.3.8/1; the wording there just seems to encourage 4768the redundant and error-prone Requires: clause. 4769</p> 4770 4771<p><b>Proposed resolution:</b></p> 4772<p> 47731. Change 17.4.3.8/1 to read: 4774</p> 4775 4776<blockquote> 4777Violation of the preconditions specified in a function's 4778<i>Required behavior:</i> paragraph results in undefined behavior 4779<del>unless the function's <i>Throws:</i> paragraph specifies throwing 4780an exception when the precondition is violated</del>. 4781</blockquote> 4782 4783<p> 47842. Go through and remove redundant Requires: clauses. Specifics to be 4785 provided by Dave A. 4786</p> 4787 4788<p><i>[ 4789Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution. 4790]</i></p> 4791 4792<hr> 4793<a name="531"><h3>531. array forms of unformatted input functions</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 23 Nov 2005</p> 4794<p> 4795The array forms of unformatted input functions don't seem to have well-defined 4796semantics for zero-element arrays in a couple of cases. The affected ones 4797(<tt>istream::get()</tt> and <tt>istream::getline()</tt>) are supposed to 4798terminate when <tt>(n - 1)</tt> characters are stored, which obviously can 4799never be true when <tt>(n == 0)</tt> holds to start with. See 4800c++std-lib-16071. 4801</p> 4802<p><b>Proposed resolution:</b></p> 4803<p> 4804I suggest changing 27.6.1.3, p7 (<tt>istream::get()</tt>), bullet 1 to read: 4805</p> 4806 <p> 4807 </p><ul> 4808 <li> 4809 <tt>(n < 1)</tt> is true or <tt>(n - 1)</tt> characters 4810 are stored; 4811 </li> 4812 </ul> 4813 <p></p> 4814<p> 4815Change 27.6.1.3, p9: 4816</p> 4817 4818<blockquote> 4819If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which 4820may throw <tt>ios_base::failure</tt> (27.4.4.3)). In any case, <ins>if <tt>(n 4821> 0)</tt> is true</ins> it then stores a null character into the next 4822successive location of the array. 4823</blockquote> 4824 4825 <p> 4826 4827and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to: 4828 4829 </p> 4830 <p> 4831 </p><ul> 4832 <li> 4833 <tt>(n < 1)</tt> is true or <tt>(n - 1)</tt> characters 4834 are stored (in which case the function calls 4835 <tt>setstate(failbit)</tt>). 4836 </li> 4837 </ul> 4838 <p></p> 4839 4840 <p> 4841 4842In addition, to clarify that <tt>istream::getline()</tt> must not store the 4843terminating NUL character unless the the array has non-zero size, Robert 4844Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read: 4845 4846 </p> 4847 <p> 4848 </p><blockquote> 4849 4850In any case, provided <tt>(n > 0)</tt> is true, it then stores a null character 4851(using charT()) into the next successive location of the array. 4852 4853 </blockquote> 4854 <p></p> 4855 4856<p><i>[ 4857post-Redmond: Pete noticed that the current resolution for <tt>get</tt> requires 4858writing to out of bounds memory when <tt>n == 0</tt>. Martin provided fix. 4859]</i></p> 4860 4861<hr> 4862<a name="532"><h3>532. Tuple comparison</h3></a><p><b>Section:</b> TR1 6.1.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple.rel"> [tr.tuple.rel]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 29 Nov 2005</p> 4863<p> 4864Where possible, tuple comparison operators <,<=,=>, and > ought to be 4865defined in terms of std::less rather than operator<, in order to 4866support comparison of tuples of pointers. 4867</p> 4868<p><b>Proposed resolution:</b></p> 4869<p> 4870change 6.1.3.5/5 from: 4871</p> 4872 4873<blockquote> 4874 Returns: The result of a lexicographical comparison between t and 4875 u. The result is defined as: (bool)(get<0>(t) < get<0>(u)) || 4876 (!(bool)(get<0>(u) < get<0>(t)) && ttail < utail), where rtail for 4877 some tuple r is a tuple containing all but the first element of 4878 r. For any two zero-length tuples e and f, e < f returns false. 4879</blockquote> 4880 4881<p> 4882to: 4883</p> 4884 4885<blockquote> 4886<p> 4887 Returns: The result of a lexicographical comparison between t and 4888 u. For any two zero-length tuples e and f, e < f returns false. 4889 Otherwise, the result is defined as: cmp( get<0>(t), get<0>(u)) || 4890 (!cmp(get<0>(u), get<0>(t)) && ttail < utail), where rtail for some 4891 tuple r is a tuple containing all but the first element of r, and 4892 cmp(x,y) is an unspecified function template defined as follows. 4893</p> 4894<p> 4895 Where T is the type of x and U is the type of y: 4896</p> 4897 4898<p> 4899 if T and U are pointer types and T is convertible to U, returns 4900 less<U>()(x,y) 4901</p> 4902 4903<p> 4904 otherwise, if T and U are pointer types, returns less<T>()(x,y) 4905</p> 4906 4907<p> 4908 otherwise, returns (bool)(x < y) 4909</p> 4910</blockquote> 4911 4912<p><i>[ 4913Berlin: This issue is much bigger than just tuple (pair, containers, 4914algorithms). Dietmar will survey and work up proposed wording. 4915]</i></p> 4916 4917<hr> 4918<a name="534"><h3>534. Missing basic_string members</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 16 Nov 2005</p> 4919<p> 4920OK, we all know std::basic_string is bloated and already has way too 4921many members. However, I propose it is missing 3 useful members that 4922are often expected by users believing it is a close approximation of the 4923container concept. All 3 are listed in table 71 as 'optional' 4924</p> 4925 4926<p> 4927i/ pop_back. 4928</p> 4929 4930<p> 4931This is the one I feel most strongly about, as I only just discovered it 4932was missing as we are switching to a more conforming standard library 4933<g> 4934</p> 4935 4936<p> 4937I find it particularly inconsistent to support push_back, but not 4938pop_back. 4939</p> 4940 4941<p> 4942ii/ back. 4943</p> 4944 4945<p> 4946There are certainly cases where I want to examine the last character of 4947a string before deciding to append, or to trim trailing path separators 4948from directory names etc. *rbegin() somehow feels inelegant. 4949</p> 4950 4951<p> 4952iii/ front 4953</p> 4954 4955<p> 4956This one I don't feel strongly about, but if I can get the first two, 4957this one feels that it should be added as a 'me too' for consistency. 4958</p> 4959 4960<p> 4961I believe this would be similarly useful to the data() member recently 4962added to vector, or at() member added to the maps. 4963</p> 4964<p><b>Proposed resolution:</b></p> 4965<p> 4966Add the following members to definition of class template basic_string, 21.3p7 4967</p> 4968<blockquote><pre>void pop_back () 4969 4970const charT & front() const 4971charT & front() 4972 4973const charT & back() const 4974charT & back() 4975</pre></blockquote> 4976<p> 4977Add the following paragraphs to basic_string description 4978</p> 4979 4980<p> 498121.3.4p5 4982</p> 4983<blockquote> 4984<pre>const charT & front() const 4985charT & front() 4986</pre> 4987<p> 4988<i>Precondition:</i> <tt>!empty()</tt> 4989</p> 4990<p> 4991<i>Effects:</i> Equivalent to <tt>operator[](0)</tt>. 4992</p> 4993</blockquote> 4994 4995<p> 499621.3.4p6 4997</p> 4998<blockquote> 4999<pre>const charT & back() const 5000charT & back() 5001</pre> 5002<p> 5003<i>Precondition:</i> <tt>!empty()</tt> 5004</p> 5005<p> 5006<i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>. 5007</p> 5008</blockquote> 5009 5010<p> 501121.3.5.5p10 5012</p> 5013<blockquote> 5014<pre>void pop_back () 5015</pre> 5016<p> 5017<i>Precondition:</i> <tt>!empty()</tt> 5018</p> 5019<p> 5020<i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>. 5021</p> 5022</blockquote> 5023 5024<p> 5025Update Table 71: (optional sequence operations) 5026Add basic_string to the list of containers for the following operations. 5027</p> 5028<blockquote><pre>a.front() 5029a.back() 5030a.push_back() 5031a.pop_back() 5032a[n] 5033</pre></blockquote> 5034 5035<p><i>[ 5036Berlin: Has support. Alisdair provided wording. 5037]</i></p> 5038<hr> 5039<a name="536"><h3>536. Container iterator constructor and explicit convertibility</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Joaqu�n M L�pez Mu�oz <b>Date:</b> 17 Dec 2005</p> 5040<p> 5041The iterator constructor X(i,j) for containers as defined in 23.1.1 and 504223.2.2 does only require that i and j be input iterators but 5043nothing is said about their associated value_type. There are three 5044sensible 5045options: 5046</p> 5047<ol> 5048<li>iterator's value_type is exactly X::value_type (modulo cv).</li> 5049<li>iterator's value_type is *implicitly* convertible to X::value_type.</li> 5050<li>iterator's value_type is *explicitly* convertible to X::value_type.</li> 5051</ol> 5052<p> 5053The issue has practical implications, and stdlib vendors have 5054taken divergent approaches to it: Dinkumware follows 2, 5055libstdc++ follows 3. 5056</p> 5057<p> 5058The same problem applies to the definition of insert(p,i,j) for 5059sequences and insert(i,j) for associative contianers, as well as 5060assign. 5061</p> 5062 5063<p><i>[ 5064The following added by Howard and the example code was originally written by 5065Dietmar. 5066]</i></p> 5067<p> 5068Valid code below? 5069</p> 5070 5071<blockquote><pre>#include <vector> 5072#include <iterator> 5073#include <iostream> 5074 5075struct foo 5076{ 5077 explicit foo(int) {} 5078}; 5079 5080int main() 5081{ 5082 std::vector<int> v_int; 5083 std::vector<foo> v_foo1(v_int.begin(), v_int.end()); 5084 std::vector<foo> v_foo2((std::istream_iterator<int>(std::cin)), 5085 std::istream_iterator<int>()); 5086} 5087</pre></blockquote> 5088 5089<p><b>Proposed resolution:</b></p> 5090<p> 5091</p> 5092<p><i>[ 5093Berlin: Some support, not universal, for respecting the explicit qualifier. 5094]</i></p> 5095<hr> 5096<a name="539"><h3>539. partial_sum and adjacent_difference should mention requirements</h3></a><p><b>Section:</b> 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand"> [lib.rand]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 6 Feb 2006</p> 5097<p> 5098There are some problems in the definition of partial_sum and 5099adjacent_difference in 26.4 [lib.numeric.ops] 5100</p> 5101 5102<p> 5103Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not 5104parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply 5105specifies the effects clause as; 5106</p> 5107 5108<blockquote> 5109Assigns to every element referred to by iterator <tt>i</tt> in the range 5110<tt>[result,result + (last - first))</tt> a value correspondingly equal to 5111<blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result ))) 5112</pre></blockquote> 5113</blockquote> 5114 5115<p> 5116And similarly for BinaryOperation. Using just this definition, it seems 5117logical to expect that: 5118</p> 5119 5120 5121<blockquote><pre>char i_array[4] = { 100, 100, 100, 100 }; 5122int o_array[4]; 5123 5124std::partial_sum(i_array, i_array+4, o_array); 5125</pre></blockquote> 5126 5127<p> 5128Is equivalent to 5129</p> 5130 5131<blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 }; 5132</pre></blockquote> 5133 5134<p> 5135i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>, 5136<tt>int</tt>. 5137</p> 5138 5139<p> 5140Yet all implementations I have tested produce 100, -56, 44, -112, 5141because they are using an accumulator of the <tt>InputIterator</tt>'s 5142<tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>. 5143</p> 5144 5145<p> 5146The issue becomes more noticeable when the result of the expression <tt>*i + 5147*(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the 5148<tt>value_type</tt>. In a contrived example: 5149</p> 5150 5151<blockquote><pre>enum not_int { x = 1, y = 2 }; 5152... 5153not_int e_array[4] = { x, x, y, y }; 5154std::partial_sum(e_array, e_array+4, o_array); 5155</pre></blockquote> 5156 5157<p> 5158Is it the intent that the operations happen in the <tt>input type</tt>, or in 5159the <tt>result type</tt>? 5160</p> 5161 5162<p> 5163If the intent is that operations happen in the <tt>result type</tt>, something 5164like this should be added to the "Requires" clause of 26.4.3/4 5165[lib.partial.sum]: 5166</p> 5167 5168<blockquote> 5169The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the 5170requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> 5171(23.1) types. 5172</blockquote> 5173 5174<p> 5175(As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2 5176[lib.inner.product].) 5177</p> 5178 5179<p> 5180The "auto initializer" feature proposed in 5181<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a> 5182is not required to 5183implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be 5184obtained by using the <tt>std::plus<></tt> function object. 5185</p> 5186 5187<p> 5188If the intent is that operations happen in the <tt>input type</tt>, then 5189something like this should be added instead; 5190</p> 5191 5192<blockquote> 5193The type of *first shall meet the requirements of 5194<tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types. 5195The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be 5196convertible to this type. 5197</blockquote> 5198 5199<p> 5200The 'widening' behaviour can then be obtained by writing a custom proxy 5201iterator, which is somewhat involved. 5202</p> 5203 5204<p> 5205In both cases, the semantics should probably be clarified. 5206</p> 5207 5208<p> 520926.4.4 [lib.adjacent.difference] is similarly underspecified, although 5210all implementations seem to perform operations in the 'result' type: 5211</p> 5212 5213<blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 }; 5214int o_array[4]; 5215 5216std::adjacent_difference(i_array, i_array+4, o_array); 5217</pre></blockquote> 5218 5219<p> 5220o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255. 5221</p> 5222 5223<p> 5224In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the 5225<tt>value_type</tt>; it can be brought in line with the rest of 26.4 5226[lib.numeric.ops] by adding the following to 26.4.4/2 5227[lib.adjacent.difference]: 5228</p> 5229 5230<blockquote> 5231The type of <tt>*first</tt> shall meet the requirements of 5232<tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types." 5233</blockquote> 5234 5235<p><b>Proposed resolution:</b></p> 5236<p> 5237</p> 5238<p><i>[ 5239Berlin: Giving output iterator's value_types very controversial. Suggestion of 5240adding signatures to allow user to specify "accumulator". 5241]</i></p> 5242<hr> 5243<a name="542"><h3>542. shared_ptr observers</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Oct 2005</p> 5244<p> 5245Peter Dimov wrote: 5246To: C++ libraries mailing list 5247Message c++std-lib-15614 5248[...] 5249The intent is for both use_count() and unique() to work in a threaded environment. 5250They are intrinsically prone to race conditions, but they never return garbage. 5251</p> 5252 5253<p> 5254This is a crucial piece of information that I really wish were 5255captured in the text. Having this in a non-normative note would 5256have made everything crystal clear to me and probably stopped 5257me from ever starting this discussion :) Instead, the sentence 5258in p12 "use only for debugging and testing purposes, not for 5259production code" very strongly suggests that implementations 5260can and even are encouraged to return garbage (when threads 5261are involved) for performance reasons. 5262</p> 5263<p> 5264How about adding an informative note along these lines: 5265</p> 5266<blockquote> 5267 Note: Implementations are encouraged to provide well-defined 5268 behavior for use_count() and unique() even in the presence of 5269 multiple threads. 5270</blockquote> 5271<p> 5272I don't necessarily insist on the exact wording, just that we 5273capture the intent. 5274</p> 5275<p><b>Proposed resolution:</b></p> 5276<p> 5277</p> 5278<hr> 5279<a name="543"><h3>543. valarray slice default constructor</h3></a><p><b>Section:</b> 26.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.members"> [lib.complex.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 3 Nov 2005</p> 5280<p> 5281If one explicitly constructs a slice or glice with the default 5282constructor, does the standard require this slice to have any usable 5283state? It says "creates a slice which specifies no elements", which 5284could be interpreted two ways: 5285</p> 5286<ol> 5287<li>There are no elements to which the slice refers (i.e. undefined).</li> 5288<li>The slice specifies an array with no elements in it (i.e. defined).</li> 5289</ol> 5290<p> 5291Here is a bit of code to illustrate: 5292</p> 5293<blockquote><pre>#include <iostream> 5294#include <valarray> 5295 5296int main() 5297{ 5298 std::valarray<int> v(10); 5299 std::valarray<int> v2 = v[std::slice()]; 5300 std::cout << "v[slice()].size() = " << v2.size() << '\n'; 5301} 5302</pre></blockquote> 5303 5304<p> 5305Is the behavior undefined? Or should the output be: 5306</p> 5307 5308<blockquote> 5309v[slice()].size() = 0 5310</blockquote> 5311 5312<p> 5313There is a similar question and wording for gslice at 26.3.6.1p1. 5314</p> 5315<p><b>Proposed resolution:</b></p> 5316<p> 5317Change 26.5.4.1 [cons.slice]: 5318</p> 5319 5320<blockquote> 53211 - <del>The default constructor for <tt>slice</tt> creates a <tt>slice</tt> 5322which specifies no elements.</del> <ins>The default constructor is equivalent to 5323<tt>slice(0, 0, 0)</tt>.</ins> A default constructor is provided only to permit 5324the declaration of arrays of slices. The constructor with arguments for a slice 5325takes a start, length, and stride parameter. 5326</blockquote> 5327 5328<p> 5329Change 26.3.6.1 [gslice.cons]: 5330</p> 5331 5332<blockquote> 53331 - <del>The default constructor creates a <tt>gslice</tt> which specifies no 5334elements.</del> <ins>The default constructor is equivalent to <tt>gslice(0, 5335valarray<size_t>(), valarray<size_t>())</tt>.</ins> The constructor 5336with arguments builds a <tt>gslice</tt> based on a specification of start, 5337lengths, and strides, as explained in the previous section. 5338</blockquote> 5339 5340<hr> 5341<a name="545"><h3>545. When is a deleter deleted?</h3></a><p><b>Section:</b> TR1 2.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared.dest"> [tr.util.smartptr.shared.dest]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 10 Jan 2006</p> 5342<p> 5343The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if 5344any, is destroyed. In principle there are two possibilities: it is destroyed 5345unconditionally whenever ~shared_ptr is executed (which, from an implementation 5346standpoint, means that the deleter is copied whenever the shared_ptr is copied), 5347or it is destroyed immediately after the owned pointer is destroyed (which, from 5348an implementation standpoint, means that the deleter object is shared between 5349instances). We should say which it is. 5350</p> 5351<p><b>Proposed resolution:</b></p> 5352<p> 5353Add after the first sentence of [lib.util.smartptr.getdeleter]/1: 5354</p> 5355<blockquote> 5356<p> 5357The returned pointer remains valid as long as there exists a <tt>shared_ptr</tt> instance 5358that owns <tt><i>d</i></tt>. 5359</p> 5360<p> 5361[<i>Note:</i> it is unspecified whether the pointer remains valid longer than that. 5362This can happen if the implementation doesn't destroy the deleter until all 5363<tt>weak_ptr</tt> instances in the ownership group are destroyed. <i>-- end note</i>] 5364</p> 5365</blockquote> 5366<hr> 5367<a name="546"><h3>546. _Longlong and _ULonglong are integer types</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 10 Jan 2006</p> 5368<p> 5369The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99]. 5370The rest of the TR should use that type. I believe this affects two places. 5371First, the random number requirements, 5.1.1/10-11, lists all of the types with 5372which template parameters named IntType and UIntType may be instantiated. 5373_Longlong (or "long long", assuming it is added to C++0x) should be added to the 5374IntType list, and UIntType (again, or "unsigned long long") should be added to 5375the UIntType list. Second, 6.3.2 lists the types for which hash<> is 5376required to be instantiable. _Longlong and _Ulonglong should be added to that 5377list, so that people may use long long as a hash key. 5378</p> 5379<p><b>Proposed resolution:</b></p> 5380<p> 5381</p> 5382<hr> 5383<a name="547"><h3>547. division should be floating-point, not integer</h3></a><p><b>Section:</b> TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 10 Jan 2006</p> 5384<p> 5385Paragraph 10 describes how a variate generator uses numbers produced by an 5386engine to pass to a generator. The sentence that concerns me is: "Otherwise, if 5387the value for engine_value_type::result_type is true and the value for 5388Distribution::input_type is false [i.e. if the engine produces integers and the 5389engine wants floating-point values], then the numbers in s_eng are divided by 5390engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the 5391engine is producing integers, both the numerator and the denominator are 5392integers and we'll be doing integer division, which I don't think is what we 5393want. Shouldn't we be performing a conversion to a floating-point type first? 5394</p> 5395<p><b>Proposed resolution:</b></p> 5396<p> 5397</p> 5398<hr> 5399<a name="548"><h3>548. May random_device block?</h3></a><p><b>Section:</b> TR1 5.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.device"> [tr.rand.device]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 10 Jan 2006</p> 5400<p> 5401Class random_device "produces non-deterministic random numbers", using some 5402external source of entropy. In most real-world systems, the amount of available 5403entropy is limited. Suppose that entropy has been exhausted. What is an 5404implementation permitted to do? In particular, is it permitted to block 5405indefinitely until more random bits are available, or is the implementation 5406required to detect failure immediately? This is not an academic question. On 5407Linux a straightforward implementation would read from /dev/random, and "When 5408the entropy pool is empty, reads to /dev/random will block until additional 5409environmental noise is gathered." Programmers need to know whether random_device 5410is permitted to (or possibly even required to?) behave the same way. 5411</p> 5412 5413<p><i>[ 5414Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin 5415may block? 5416]</i></p> 5417 5418<p><b>Proposed resolution:</b></p> 5419<p> 5420</p> 5421<hr> 5422<a name="550"><h3>550. What should the return type of pow(float,int) be?</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 12 Jan 2006</p> 5423<p> 5424Assuming we adopt the 5425<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C 5426compatibility package from C99</a> what should be the return type of the 5427following signature be: 5428</p> 5429<blockquote><pre>? pow(float, int); 5430</pre></blockquote> 5431<p> 5432C++03 says that the return type should be <tt>float</tt>. 5433<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf"> 5434TR1</a> and C90/99 say the return type should be <tt>double</tt>. This can put 5435clients into a situation where C++03 provides answers that are not as high 5436quality as C90/C99/TR1. For example: 5437</p> 5438<blockquote><pre>#include <math.h> 5439 5440int main() 5441{ 5442 float x = 2080703.375F; 5443 double y = pow(x, 2); 5444} 5445</pre></blockquote> 5446<p> 5447Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest: 5448</p> 5449 5450<blockquote><pre>y = 4329326534736.390625 5451</pre></blockquote> 5452 5453<p> 5454which is exactly right. While C++98/C++03 demands: 5455</p> 5456 5457<blockquote><pre>y = 4329326510080. 5458</pre></blockquote> 5459 5460<p> 5461which is only approximately right. 5462</p> 5463 5464<p> 5465I recommend that C++0X adopt the mixed mode arithmetic already adopted by 5466Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be 5467<tt>double</tt>. 5468</p> 5469 5470<p><b>Proposed resolution:</b></p> 5471<p> 5472</p> 5473<hr> 5474<a name="551"></a><h3><a name="551">551. <ccomplex></a></h3><p><b>Section:</b> TR1 8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.ccmplx"> [tr.c99.ccmplx]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 23 Jan 2006</p> 5475<p> 5476Previously xxx.h was parsable by C++. But in the case of C99's <complex.h> 5477it isn't. Otherwise we could model it just like <string.h>, <cstring>, <string>: 5478</p> 5479 5480<ul> 5481<li><string> : C++ API in namespace std</li> 5482<li><cstring> : C API in namespace std</li> 5483<li><string.h> : C API in global namespace</li> 5484</ul> 5485 5486<p> 5487In the case of C's complex, the C API won't compile in C++. So we have: 5488</p> 5489 5490<ul> 5491<li><complex> : C++ API in namespace std</li> 5492<li><ccomplex> : ?</li> 5493<li><complex.h> : ?</li> 5494</ul> 5495 5496<p> 5497The ? can't refer to the C API. TR1 currently says: 5498</p> 5499 5500<ul> 5501<li><complex> : C++ API in namespace std</li> 5502<li><ccomplex> : C++ API in namespace std</li> 5503<li><complex.h> : C++ API in global namespace</li> 5504</ul> 5505 5506<p><b>Proposed resolution:</b></p> 5507<p> 5508Change 26.3.11 [cmplxh]: 5509</p> 5510 5511<blockquote> 5512<p> 5513The header behaves as if it includes the header 5514<tt><ccomplex></tt><ins>.</ins><del>, and provides sufficient using 5515declarations to declare in the global namespace all function and type names 5516declared or defined in the neader <tt><complex></tt>.</del> 5517<ins>[<i>Note:</i> <tt><complex.h></tt> does not promote any interface 5518into the global namespace as there is no C interface to promote. <i>--end 5519note</i>]</ins> 5520</p> 5521</blockquote> 5522 5523<hr> 5524<a name="552"><h3>552. random_shuffle and its generator</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 25 Jan 2006</p> 5525<p> 5526...is specified to shuffle its range by calling swap but not how 5527(or even that) it's supposed to use the RandomNumberGenerator 5528argument passed to it. 5529</p> 5530<p> 5531Shouldn't we require that the generator object actually be used 5532by the algorithm to obtain a series of random numbers and specify 5533how many times its operator() should be invoked by the algorithm? 5534</p> 5535<p><b>Proposed resolution:</b></p> 5536<p> 5537</p> 5538<hr> 5539<a name="553"><h3>553. very minor editorial change intptr_t / uintptr_t</h3></a><p><b>Section:</b> TR1 8.22.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.cstdint.syn"> [tr.c99.cstdint.syn]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 30 Jan 2006</p> 5540<p> 5541In the synopsis, some types are identified as optional: int8_t, int16_t, 5542and so on, consistently with C99, indeed. 5543</p> 5544<p> 5545On the other hand, intptr_t and uintptr_t, are not marked as such and 5546probably should, consistently with C99, 7.18.1.4. 5547</p> 5548<p><b>Proposed resolution:</b></p> 5549<p> 5550</p> 5551<hr> 5552<a name="556"><h3>556. is Compare a BinaryPredicate?</h3></a><p><b>Section:</b> 25.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.sorting"> [lib.alg.sorting]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Feb 2006</p> 5553<p> 5554In 25, p8 we allow BinaryPredicates to return a type that's convertible 5555to bool but need not actually be bool. That allows predicates to return 5556things like proxies and requires that implementations be careful about 5557what kinds of expressions they use the result of the predicate in (e.g., 5558the expression in if (!pred(a, b)) need not be well-formed since the 5559negation operator may be inaccessible or return a type that's not 5560convertible to bool). 5561</p> 5562<p> 5563Here's the text for reference: 5564</p> 5565<blockquote> 5566 ...if an algorithm takes BinaryPredicate binary_pred as its argument 5567 and first1 and first2 as its iterator arguments, it should work 5568 correctly in the construct if (binary_pred(*first1, first2)){...}. 5569</blockquote> 5570 5571<p> 5572In 25.3, p2 we require that the Compare function object return true 5573of false, which would seem to preclude such proxies. The relevant text 5574is here: 5575</p> 5576<blockquote> 5577 Compare is used as a function object which returns true if the first 5578 argument is less than the second, and false otherwise... 5579</blockquote> 5580<p><b>Proposed resolution:</b></p> 5581<p> 5582I think we could fix this by rewording 25.3, p2 to read somthing like: 5583</p> 5584<blockquote> 5585-2- <tt>Compare</tt> is <del>used as a function object which returns 5586<tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The 5587return value of the function call operator applied to an object of type 5588<tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt> 5589if the first argument of the call</ins> is less than the second, and 5590<tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for 5591algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt> 5592will not apply any non-constant function through the dereferenced iterator. 5593</blockquote> 5594<hr> 5595<a name="557"><h3>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3></a><p><b>Section:</b> TR1 8.11.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.cinttypes.syn"> [tr.c99.cinttypes.syn]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 6 Feb 2006</p> 5596<p> 5597I'm seeing a problem with such overloads: when, _Longlong == intmax_t == 5598long long we end up, essentially, with the same arguments and different 5599return types (lldiv_t and imaxdiv_t, respectively). Similar issue with 5600abs(_Longlong) and abs(intmax_t), of course. 5601</p> 5602<p> 5603Comparing sections 8.25 and 8.11, I see an important difference, 5604however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong 5605types (rightfully, because not moved over directly from C99), whereas 5606there is no equivalent in 8.11: the abs and div overloads for intmax_t 5607types appear only in the synopsis and are not described anywhere, in 5608particular no mention in 8.11.2 (at variance with 8.25.2). 5609</p> 5610<p> 5611I'm wondering whether we really, really, want div and abs for intmax_t... 5612</p> 5613<p><b>Proposed resolution:</b></p> 5614<p> 5615Change the <tt><cstdint></tt> synopsis in 8.11.1: 5616</p> 5617<blockquote><pre>... 5618intmax_t imaxabs(intmax_t i); 5619<del>intmax_t abs(intmax_t i);</del> 5620 5621imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); 5622<del>imaxdiv_t div(intmax_t numer, intmax_t denom);</del> 5623... 5624</pre></blockquote> 5625 5626<p><i>[ 5627Portland: no consensus. 5628]</i></p> 5629 5630<hr> 5631<a name="559"><h3>559. numeric_limits<const T></h3></a><p><b>Section:</b> 18.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.limits"> [lib.support.limits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 19 Feb 2006</p> 5632 <p> 5633 563418.2.1, p2 requires implementations to provide specializations of the 5635<code>numeric_limits</code> template for each scalar type. While this 5636could be interepreted to include cv-qualified forms of such types such 5637an interepretation is not reflected in the synopsis of the 5638<code><limits></code> header. 5639 5640 </p> 5641 <p> 5642 5643The absence of specializations of the template on cv-qualified forms 5644of fundamental types makes <code>numeric_limits</code> difficult to 5645use in generic code where the constness (or volatility) of a type is 5646not always immediately apparent. In such contexts, the primary 5647template ends up being instantiated instead of the provided 5648specialization, typically yielding unexpected behavior. 5649 5650 </p> 5651<p><b>Proposed resolution:</b></p> 5652 <p> 5653 5654Require that specializations of <code>numeric_limits</code> on 5655cv-qualified fundamental types have the same semantics as those on the 5656unqualifed forms of the same types. 5657 5658 </p> 5659 <p> 5660 5661Add to the synopsis of the <code><limits></code> header, 5662immediately below the declaration of the primary template, the 5663following: 5664 5665</p><pre> 5666template <class T> class numeric_limits<const T>; 5667template <class T> class numeric_limits<volatile T>; 5668template <class T> class numeric_limits<const volatile T>; 5669 5670</pre> 5671 5672 <p></p> 5673 <p> 5674 5675Add a new paragraph to the end of 18.2.1.1, with the following 5676text: 5677 5678 </p> 5679 <p> 5680 5681-new-para- The value of each member of a <code>numeric_limits</code> 5682specialization on a cv-qualified T is equal to the value of the same 5683member of <code>numeric_limits<T></code>. 5684 5685 </p> 5686 5687<p><i>[ 5688Portland: Martin will clarify that user-defined types get cv-specializations 5689automatically. 5690]</i></p> 5691 5692<hr> 5693<a name="560"><h3>560. User-defined allocators without default constructor</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Sergey P. Derevyago <b>Date:</b> 17 Feb 2006</p> 5694<h4>1. The essence of the problem.</h4> 5695<p> 5696User-defined allocators without default constructor are not explicitly 5697supported by the standard but they can be supported just like std::vector 5698supports elements without default constructor. 5699</p> 5700<p> 5701As a result, there exist implementations that work well with such allocators 5702and implementations that don't. 5703</p> 5704 5705<h4>2. The cause of the problem.</h4> 5706<p> 57071) The standard doesn't explicitly state this intent but it should. In 5708particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator 5709instances that compare non-equal. So it can similarly state the intent w.r.t. 5710the user-defined allocators without default constructor. 5711</p> 5712<p> 57132) Some container operations are obviously underspecified. In particular, 571421.3.7.1p2 tells: 5715</p> 5716<blockquote> 5717<pre>template<class charT, class traits, class Allocator> 5718 basic_string<charT,traits,Allocator> operator+( 5719 const charT* lhs, 5720 const basic_string<charT,traits,Allocator>& rhs 5721 ); 5722</pre> 5723Returns: <tt>basic_string<charT,traits,Allocator>(lhs) + rhs</tt>. 5724</blockquote> 5725<p> 5726That leads to the basic_string<charT,traits,Allocator>(lhs, Allocator()) call. 5727Obviously, the right requirement is: 5728</p> 5729<blockquote> 5730Returns: <tt>basic_string<charT,traits,Allocator>(lhs, rhs.get_allocator()) + rhs</tt>. 5731</blockquote> 5732<p> 5733It seems like a lot of DRs can be submitted on this "Absent call to 5734get_allocator()" topic. 5735</p> 5736 5737<h4>3. Proposed actions.</h4> 5738<p> 57391) Explicitly state the intent to allow for user-defined allocators without 5740default constructor in 20.1.5 Allocator requirements. 5741</p> 5742<p> 57432) Correct all the places, where a correct allocator object is available 5744through the get_allocator() call but default Allocator() gets passed instead. 5745</p> 5746<h4>4. Code sample.</h4> 5747<p> 5748Let's suppose that the following memory pool is available: 5749</p> 5750<blockquote><pre>class mem_pool { 5751 // ... 5752 void* allocate(size_t size); 5753 void deallocate(void* ptr, size_t size); 5754}; 5755</pre></blockquote> 5756<p> 5757So the following allocator can be implemented via this pool: 5758</p> 5759<blockquote><pre>class stl_allocator { 5760 mem_pool& pool; 5761 5762 public: 5763 explicit stl_allocator(mem_pool& mp) : pool(mp) {} 5764 stl_allocator(const stl_allocator& sa) : pool(sa.pool) {} 5765 template <class U> 5766 stl_allocator(const stl_allocator<U>& sa) : pool(sa.get_pool()) {} 5767 ~stl_allocator() {} 5768 5769 pointer allocate(size_type n, std::allocator<void>::const_pointer = 0) 5770 { 5771 return (n!=0) ? static_cast<pointer>(pool.allocate(n*sizeof(T))) : 0; 5772 } 5773 5774 void deallocate(pointer p, size_type n) 5775 { 5776 if (n!=0) pool.deallocate(p, n*sizeof(T)); 5777 } 5778 5779 // ... 5780}; 5781</pre></blockquote> 5782<p> 5783Then the following code works well on some implementations and doesn't work on 5784another: 5785</p> 5786<blockquote><pre>typedef basic_string<char, char_traits<char>, stl_allocator<char> > 5787 tl_string; 5788mem_pool mp; 5789tl_string s1("abc", stl_allocator<int>(mp)); 5790printf("(%s)\n", ("def"+s1).c_str()); 5791</pre></blockquote> 5792<p> 5793In particular, on some implementations the code can't be compiled without 5794default stl_allocator() constructor. 5795</p> 5796<p> 5797The obvious way to solve the compile-time problems is to intentionally define 5798a NULL pointer dereferencing default constructor 5799</p> 5800<blockquote><pre>stl_allocator() : pool(*static_cast<mem_pool*>(0)) {} 5801</pre></blockquote> 5802<p> 5803in a hope that it will not be called. The problem is that it really gets 5804called by operator+(const char*, const string&) under the current 21.3.7.1p2 5805wording. 5806</p> 5807<p><b>Proposed resolution:</b></p> 5808<p> 5809</p> 5810<hr> 5811<a name="561"><h3>561. inserter overly generic</h3></a><p><b>Section:</b> 24.4.2.6.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.inserter"> [lib.inserter]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 21 Feb 2006</p> 5812<p> 5813The declaration of <tt>std::inserter</tt> is: 5814</p> 5815 5816<blockquote><pre>template <class Container, class Iterator> 5817insert_iterator<Container> 5818inserter(Container& x, Iterator i); 5819</pre></blockquote> 5820 5821<p> 5822The template parameter <tt>Iterator</tt> in this function is completely unrelated 5823to the template parameter <tt>Container</tt> when it doesn't need to be. This 5824causes the code to be overly generic. That is, any type at all can be deduced 5825as <tt>Iterator</tt>, whether or not it makes sense. Now the same is true of 5826<tt>Container</tt>. However, for every free (unconstrained) template parameter 5827one has in a signature, the opportunity for a mistaken binding grows geometrically. 5828</p> 5829 5830<p> 5831It would be much better if <tt>inserter</tt> had the following signature instead: 5832</p> 5833 5834<blockquote><pre>template <class Container> 5835insert_iterator<Container> 5836inserter(Container& x, typename Container::iterator i); 5837</pre></blockquote> 5838 5839<p> 5840Now there is only one free template parameter. And the second argument to 5841<tt>inserter</tt> must be implicitly convertible to the container's iterator, 5842else the call will not be a viable overload (allowing other functions in the 5843overload set to take precedence). Furthermore, the first parameter must have a 5844nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt> 5845is not viable. Contrast this with the current situation 5846where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those 5847types need not be anything closely related to containers or iterators. 5848</p> 5849 5850<p> 5851This can adversely impact well written code. Consider: 5852</p> 5853 5854<blockquote><pre>#include <iterator> 5855#include <string> 5856 5857namespace my 5858{ 5859 5860template <class String> 5861struct my_type {}; 5862 5863struct my_container 5864{ 5865template <class String> 5866void push_back(const my_type<String>&); 5867}; 5868 5869template <class String> 5870void inserter(const my_type<String>& m, my_container& c) {c.push_back(m);} 5871 5872} // my 5873 5874int main() 5875{ 5876 my::my_container c; 5877 my::my_type<std::string> m; 5878 inserter(m, c); 5879} 5880</pre></blockquote> 5881 5882<p> 5883Today this code fails because the call to <tt>inserter</tt> binds to 5884<tt>std::inserter</tt> instead of to <tt>my::inserter</tt>. However with the 5885proposed change <tt>std::inserter</tt> will no longer be a viable function which 5886leaves only <tt>my::inserter</tt> in the overload resolution set. Everything 5887works as the client intends. 5888</p> 5889 5890<p> 5891To make matters a little more insidious, the above example works today if you 5892simply change the first argument to an rvalue: 5893</p> 5894 5895<blockquote><pre> inserter(my::my_type(), c); 5896</pre></blockquote> 5897 5898<p> 5899It will also work if instantiated with some string type other than 5900<tt>std::string</tt> (or any other <tt>std</tt> type). It will also work if 5901<tt><iterator></tt> happens to not get included. 5902</p> 5903 5904<p> 5905And it will fail again for such inocuous reaons as <tt>my_type</tt> or 5906<tt>my_container</tt> privately deriving from any <tt>std</tt> type. 5907</p> 5908 5909<p> 5910It seems unfortunate that such simple changes in the client's code can result 5911in such radically differing behavior. 5912</p> 5913 5914<p><b>Proposed resolution:</b></p> 5915<p> 5916Change 24.2: 5917</p> 5918 5919<blockquote> 5920<b>24.2 Header</b> <tt><iterator></tt> <b>synopsis</b> 5921<blockquote><pre>... 5922template <class Container<del>, class Iterator</del>> 5923 insert_iterator<Container> inserter(Container& x, <del>Iterator</del> <ins>typename Container::iterator</ins> i); 5924... 5925</pre></blockquote> 5926</blockquote> 5927 5928<p> 5929Change 24.4.2.5: 5930</p> 5931 5932<blockquote> 5933<b>24.4.2.5 Class template</b> <tt>insert_iterator</tt> 5934<blockquote><pre>... 5935template <class Container<del>, class Iterator</del>> 5936 insert_iterator<Container> inserter(Container& x, <del>Iterator</del> <ins>typename Container::iterator</ins> i); 5937... 5938</pre></blockquote> 5939</blockquote> 5940 5941<p> 5942Change 24.4.2.6.5: 5943</p> 5944 5945<blockquote> 5946<p> 5947<b>24.4.2.6.5</b> <tt>inserter</tt> 5948</p> 5949<pre>template <class Container<del>, class Inserter</del>> 5950 insert_iterator<Container> inserter(Container& x, <del>Inserter</del> <ins>typename Container::iterator</ins> i); 5951</pre> 5952<blockquote> 5953-1- <i>Returns:</i> <tt>insert_iterator<Container>(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>. 5954</blockquote> 5955</blockquote> 5956 5957<hr> 5958<a name="562"><h3>562. stringbuf ctor inefficient</h3></a><p><b>Section:</b> 27.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 23 Feb 2006</p> 5959 <p> 5960 5961For better efficiency, the requirement on the stringbuf ctor that 5962takes a string argument should be loosened up to let it set 5963<code>epptr()</code> beyond just one past the last initialized 5964character just like <code>overflow()</code> has been changed to be 5965allowed to do (see issue 432). That way the first call to 5966<code>sputc()</code> on an object won't necessarily cause a call to 5967<code>overflow</code>. The corresponding change should be made to the 5968string overload of the <code>str()</code> member function. 5969 5970 </p> 5971<p><b>Proposed resolution:</b></p> 5972 <p> 5973 5974Change 27.7.1.1, p3 of the Working Draft, N1804, as follows: 5975 5976 </p> 5977 5978<blockquote> 5979<pre>explicit basic_stringbuf(const basic_string<charT,traits,Allocator>& <i>s<del>tr</del></i>, 5980 ios_base::openmode <i>which</i> = ios_base::in | ios_base::out); 5981</pre> 5982 5983<p> 5984-3- <i>Effects:</i> Constructs an object of class <tt>basic_stringbuf</tt>, 5985initializing the base class with <tt>basic_streambuf()</tt> 5986(27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>. 5987Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of 5988<i>str</i> into the <tt>basic_stringbuf</tt> underlying character 5989sequence. If <tt><i>which</i> & ios_base::out</tt> is true, initializes the 5990output sequence such that <tt>pbase()</tt> points to the first underlying 5991character, <tt>epptr()</tt> points one past the last underlying character, and 5992<tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> & ios_base::ate</tt> 5993is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If 5994<tt>which & ios_base::in</tt> is true, initializes the input sequence such 5995that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying 5996character and <tt>egptr()</tt> points one past the last underlying character.</del> 5997</p> 5998</blockquote> 5999 6000 <p> 6001 6002Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to 6003read: 6004 6005 </p> 6006<blockquote> 6007<p> 6008-2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the 6009<tt>basic_stringbuf</tt> underlying character sequence <ins>and 6010initializes the input and output sequences according to <tt><i>mode</i></tt></ins>. 6011<del>If 6012<tt><i>mode</i> & ios_base::out</tt> is true, initializes the output 6013sequence such that <tt>pbase()</tt> points to the first underlying character, 6014<tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt> 6015is equal to <tt>epptr()</tt> if <tt><i>mode</i> & ios_base::in</tt> 6016is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If 6017<tt>mode & ios_base::in</tt> is true, initializes the input sequence 6018such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying 6019character and <tt>egptr()</tt> points one past the last underlying character.</del> 6020</p> 6021 6022 <p> 6023 6024<ins>-3- <i>Postconditions:</i> If <code>mode & ios_base::out</code> is true, 6025<code>pbase()</code> points to the first underlying character and 6026<code>(epptr() >= pbase() + s.size())</code> holds; in addition, if 6027<code>mode & ios_base::in</code> is true, <code>(pptr() == pbase() 6028+ s.data())</code> holds, otherwise <code>(pptr() == pbase())</code> 6029is true. If <code>mode & ios_base::in</code> is true, 6030<code>eback()</code> points to the first underlying character, and 6031<code>(gptr() == eback())</code> and <code>(egptr() == eback() + 6032s.size())</code> hold.</ins> 6033 6034 </p> 6035</blockquote> 6036<hr> 6037<a name="563"><h3>563. stringbuf seeking from end</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 23 Feb 2006</p> 6038<p> 6039According to Table 92 (unchanged by issue 432), when <code>(way == 6040end)</code> the <code>newoff</code> value in out mode is computed as 6041the difference between <code>epptr()</code> and <code>pbase()</code>. 6042</p> 6043 <p> 6044 6045This value isn't meaningful unless the value of <code>epptr()</code> 6046can be precisely controlled by a program. That used to be possible 6047until we accepted the resolution of issue 432, but since then the 6048requirements on <code>overflow()</code> have been relaxed to allow it 6049to make more than 1 write position available (i.e., by setting 6050<code>epptr()</code> to some unspecified value past 6051<code>pptr()</code>). So after the first call to 6052<code>overflow()</code> positioning the output sequence relative to 6053end will have unspecified results. 6054 6055 </p> 6056 <p> 6057 6058In addition, in <code>in|out</code> mode, since <code>(egptr() == 6059epptr())</code> need not hold, there are two different possible values 6060for <code>newoff</code>: <code>epptr() - pbase()</code> and 6061<code>egptr() - eback()</code>. 6062 6063 </p> 6064<p><b>Proposed resolution:</b></p> 6065 <p> 6066 6067Change the <code>newoff</code> column in the last row of Table 94 to 6068read: 6069 6070 </p> 6071<blockquote> 6072 6073the <del>end</del> <ins>high mark</ins> pointer minus the beginning 6074pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>). 6075 6076</blockquote> 6077<hr> 6078<a name="564"><h3>564. stringbuf seekpos underspecified</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 23 Feb 2006</p> 6079<p> 6080The effects of the <code>seekpos()</code> member function of 6081<code>basic_stringbuf</code> simply say that the function positions 6082the input and/or output sequences but fail to spell out exactly 6083how. This is in contrast to the detail in which <code>seekoff()</code> 6084is described. 6085</p> 6086<p><b>Proposed resolution:</b></p> 6087 <p> 6088 6089Change 27.7.1.3, p13 to read: 6090 6091 </p> 6092<blockquote> 6093<p> 6094-13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg, 6095<i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences, 6096if possible, to correspond to the stream position stored in <tt><i>sp</i></tt> 6097(as described below).</del> 6098</p> 6099<ul> 6100<li><del>If <tt>(<i>which</i> & ios_base::in) != 0</tt>, positions the input sequence.</del></li> 6101<li><del>If <tt>(<i>which</i> & ios_base::out) != 0</tt>, positions the output sequence.</del></li> 6102<li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function 6103positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt> 6104has not been obtained by a previous successful call to one of the positioning 6105functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>) 6106the effect is undefined.</del></li> 6107</ul> 6108</blockquote> 6109<hr> 6110<a name="565"><h3>565. xsputn inefficient</h3></a><p><b>Section:</b> 27.5.2.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.put"> [lib.streambuf.virt.put]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 23 Feb 2006</p> 6111 <p> 6112 6113<tt>streambuf::xsputn()</tt> is specified to have the effect of 6114"writing up to <tt>n</tt> characters to the output sequence as if by 6115repeated calls to <tt>sputc(c)</tt>." 6116 6117 </p> 6118 <p> 6119 6120Since <tt>sputc()</tt> is required to call <tt>overflow()</tt> when 6121<tt>(pptr() == epptr())</tt> is true, strictly speaking 6122<tt>xsputn()</tt> should do the same. However, doing so would be 6123suboptimal in some interesting cases, such as in unbuffered mode or 6124when the buffer is <tt>basic_stringbuf</tt>. 6125 6126 </p> 6127 <p> 6128 6129Assuming calling <tt>overflow()</tt> is not really intended to be 6130required and the wording is simply meant to describe the general 6131effect of appending to the end of the sequence it would be worthwhile 6132to mention in <tt>xsputn()</tt> that the function is not actually 6133required to cause a call to <tt>overflow()</tt>. 6134 6135 </p> 6136<p><b>Proposed resolution:</b></p> 6137 <p> 6138 6139Add the following sentence to the <tt>xsputn()</tt> Effects clause in 614027.5.2.4.5, p1 (N1804): 6141 6142 </p> 6143 <blockquote> 6144 <p> 6145-1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output 6146sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters 6147written are obtained from successive elements of the array whose first element 6148is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt> 6149characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return 6150<tt>traits::eof()</tt>. <ins>It is uspecified whether the function calls 6151<tt>overflow()</tt> when <tt>(pptr() == epptr())</tt> becomes true or whether 6152it achieves the same effects by other means.</ins> 6153 </p> 6154 </blockquote> 6155 <p> 6156 6157In addition, I suggest to add a footnote to this function with the 6158same text as Footnote 292 to make it extra clear that derived classes 6159are permitted to override <tt>xsputn()</tt> for efficiency. 6160 6161 </p> 6162<hr> 6163<a name="566"><h3>566. array forms of unformatted input function undefined for zero-element arrays</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 23 Feb 2006</p> 6164 <p> 6165 6166The array forms of unformatted input functions don't have well-defined 6167semantics for zero-element arrays in a couple of cases. The affected 6168ones (<tt>istream::get()</tt> and <tt>getline()</tt>) are supposed to 6169terminate when <tt>(n - 1)</tt> characters are stored, which obviously 6170can never be true when <tt>(n == 0)</tt> to start with. 6171 6172 </p> 6173<p><b>Proposed resolution:</b></p> 6174 <p> 6175 6176I propose the following changes (references are relative to the 6177Working Draft (document N1804). 6178 6179 </p> 6180 <p> 6181 6182Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows: 6183 6184 </p> 6185 <blockquote> 6186 <p> 6187 6188<ins>if <tt>(n < 1)</tt> is true or </ins> <tt>(n - 1)</tt> 6189characters are stored; 6190 6191 </p> 6192 </blockquote> 6193 <p> 6194 6195Similarly, change 27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet 61963 as follows: 6197 6198 </p> 6199 <blockquote> 6200 <p> 6201 6202<ins><tt>(n < 1)</tt> is true or </ins><tt>(n - 1)</tt> characters 6203are stored (in which case the function calls 6204<tt>setstate(failbit)</tt>). 6205 6206 </p> 6207 </blockquote> 6208 <p> 6209 6210Finally, change p21 as follows: 6211 6212 </p> 6213 <blockquote> 6214 <p> 6215 6216In any case, <ins>provided <tt>(n > 0)</tt> is true, </ins>it then 6217stores a null character (using charT()) into the next successive 6218location of the array. 6219 6220 </p> 6221 </blockquote> 6222<hr> 6223<a name="567"><h3>567. streambuf inserter and extractor should be unformatted</h3></a><p><b>Section:</b> 27.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 25 Feb 2006</p> 6224 <p> 6225 6226Issue 60 explicitly made the extractor and inserter operators that 6227take a <tt>basic_streambuf*</tt> argument formatted input and output 6228functions, respectively. I believe that's wrong, certainly in the 6229case of the extractor, since formatted functions begin by extracting 6230and discarding whitespace. The extractor should not discard any 6231characters. 6232 6233 </p> 6234<p><b>Proposed resolution:</b></p> 6235 <p> 6236 6237I propose to change each operator to behave as unformatted input and 6238output function, respectively. The changes below are relative to the 6239working draft document number N1804. 6240 6241 </p> 6242 <p> 6243 6244Specifically, change 27.6.1.2.3, p14 as follows: 6245 6246 </p> 6247 6248 <p> 6249 </p><blockquote> 6250 6251<i>Effects</i>: Behaves as a<ins>n un</ins>formatted input function 6252(as described in <del>27.6.1.2.1</del><ins>27.6.1.3, paragraph 62531</ins>). 6254 6255 </blockquote> 6256 <p></p> 6257 <p> 6258 6259And change 27.6.2.5.3, p7 as follows: 6260 6261 </p> 6262 6263 <p> 6264 </p><blockquote> 6265 6266<i>Effects</i>: Behaves as a<ins>n un</ins>formatted output function 6267(as described in <del>27.6.2.5.1</del><ins>27.6.2.6, paragraph 62681</ins>). 6269 6270 </blockquote> 6271 <p></p> 6272<hr> 6273<a name="568"><h3>568. log2 overloads missing</h3></a><p><b>Section:</b> TR1 8.16.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.cmath.over"> [tr.c99.cmath.over]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 7 Mar 2006</p> 6274<p> 6275<tt>log2</tt> is missing from the list of "additional overloads" in 8.16.4p1. 6276</p> 6277<p><b>Proposed resolution:</b></p> 6278<p> 6279Add <tt>log2</tt> to the list of functions in 8.16.4p1. 6280</p> 6281<hr> 6282<a name="570"><h3>570. Request adding additional explicit specializations of char_traits</h3></a><p><b>Section:</b> 21.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits"> [lib.char.traits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Jack Reeves <b>Date:</b> 6 Apr 2006</p> 6283<p> 6284Currently, the Standard Library specifies only a declaration for template class 6285char_traits<> and requires the implementation provide two explicit 6286specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard 6287should require explicit specializations for all built-in character types, i.e. 6288char, wchar_t, unsigned char, and signed char. 6289</p> 6290<p> 6291I have put together a paper (N1985) that describes this in more detail and 6292includes all the necessary wording. 6293</p> 6294<p><b>Proposed resolution:</b></p> 6295<p> 6296</p> 6297<hr> 6298<a name="571"><h3>571. Update C90 references to C99?</h3></a><p><b>Section:</b> 1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.refs"> [intro.refs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 8 Apr 2006</p> 6299<p> 63001.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC 63019899:1990, Programming languages - C. Should that be changed to ISO/IEC 63029899:1999? 6303</p> 6304<p> 6305What impact does this have on the library? 6306</p> 6307<p><b>Proposed resolution:</b></p> 6308<p> 6309In 1.2/1 [intro.refs] of the WP, change: 6310</p> 6311<blockquote> 6312<ul> 6313<li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i> 6314</li> 6315</ul> 6316</blockquote> 6317 6318<hr> 6319<a name="572"><h3>572. Oops, we gave 507 WP status</h3></a><p><b>Section:</b> TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 11 Apr 2006</p> 6320<p> 6321In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot: 6322variate_generator has been eliminated. Then in full committee we voted to give 6323this issue WP status (mistakenly). 6324</p> 6325<p><b>Proposed resolution:</b></p> 6326<p> 6327Strike the proposed resolution of issue 507. 6328</p> 6329<p><i>[ 6330post-Portland: Howard recommends NAD. The proposed resolution of 507 no longer 6331exists in the current WD. 6332]</i></p> 6333<hr> 6334<a name="573"><h3>573. C++0x file positioning should handle modern file sizes</h3></a><p><b>Section:</b> 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 12 Apr 2006</p> 6335<p> 6336There are two deficiencies related to file sizes: 6337</p> 6338<ol> 6339<li>It doesn't appear that the Standard Library is specified in 6340 a way that handles modern file sizes, which are often too 6341 large to be represented by an unsigned long.</li> 6342 6343<li>The std::fpos class does not currently have the ability to 6344 set/get file positions.</li> 6345</ol> 6346<p> 6347The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by: 6348</p> 6349<ol type="A"> 6350<li>Defining fpos_t be long long, which is large enough to 6351 represent any file position likely in the foreseeable future.</li> 6352 6353<li>Adding member functions to class fpos. For example, 6354<blockquote><pre>fpos_t seekpos() const; 6355</pre></blockquote> 6356</li> 6357</ol> 6358<p> 6359Because there are so many types relating to file positions and offsets (fpos_t, 6360fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and 6361perhaps more), it is difficult to know if the Dinkumware extensions are 6362sufficient. But they seem a useful starting place for discussions, and they do 6363represent existing practice. 6364</p> 6365 6366<p><b>Proposed resolution:</b></p> 6367<p> 6368</p> 6369<hr> 6370<a name="574"><h3>574. DR 369 Contradicts Text</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 18 Apr 2006</p> 6371<p> 6372lib.iostream.objects requires that the standard stream objects are never 6373destroyed, and it requires that they be destroyed. 6374</p> 6375<p> 6376DR 369 adds words to say that we really mean for ios_base::Init objects to force 6377construction of standard stream objects. It ends, though, with the phrase "these 6378stream objects shall be destroyed after the destruction of dynamically ...". 6379However, the rule for destruction is stated in the standard: "The objects are 6380not destroyed during program execution." 6381</p> 6382<p><b>Proposed resolution:</b></p> 6383<p> 6384</p> 6385<hr> 6386<a name="575"><h3>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3></a><p><b>Section:</b> 20.6.6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.util.smartptr.shared.dest"> [lib.util.smartptr.shared.dest]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 23 Apr 2006</p> 6387<p> 6388[tr.util.smartptr.shared.dest] says in its second bullet: 6389</p> 6390 6391<p> 6392"If *this shares ownership with another shared_ptr instance (use_count() > 1), 6393decrements that instance's use count." 6394</p> 6395 6396<p> 6397The problem with this formulation is that it presupposes the existence of an 6398"use count" variable that can be decremented and that is part of the state of a 6399shared_ptr instance (because of the "that instance's use count".) 6400</p> 6401 6402<p> 6403This is contrary to the spirit of the rest of the specification that carefully 6404avoids to require an use count variable. Instead, use_count() is specified to 6405return a value, a number of instances. 6406</p> 6407 6408<p> 6409In multithreaded code, the usual implicit assumption is that a shared variable 6410should not be accessed by more than one thread without explicit synchronization, 6411and by introducing the concept of an "use count" variable, the current wording 6412implies that two shared_ptr instances that share ownership cannot be destroyed 6413simultaneously. 6414</p> 6415 6416<p> 6417In addition, if we allow the interpretation that an use count variable is part 6418of shared_ptr's state, this would lead to other undesirable consequences WRT 6419multiple threads. For example, 6420</p> 6421 6422<blockquote><pre>p1 = p2; 6423</pre></blockquote> 6424 6425<p> 6426would now visibly modify the state of p2, a "write" operation, requiring a lock. 6427</p> 6428<p><b>Proposed resolution:</b></p> 6429<p> 6430Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to: 6431</p> 6432 6433<blockquote><p> 6434</p><ul> 6435<li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another 6436<tt>shared_ptr</tt> instance (<tt>use_count() > 1</tt>)</ins>, there are no side effects.</li> 6437<li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance 6438(<tt>use_count() > 1</tt>), decrements that instance's use count.</del></li> 6439</ul> 6440<p></p></blockquote> 6441 6442<p> 6443Add the following paragraph after [lib.util.smartptr.shared.dest]/1: 6444</p> 6445 6446<blockquote><p> 6447[<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in 6448<tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership 6449with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value 6450after <tt>*this</tt> is destroyed. <i>--end note</i>] 6451</p></blockquote> 6452<hr> 6453<a name="576"><h3>576. find_first_of is overconstrained</h3></a><p><b>Section:</b> 25.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Doug Gregor <b>Date:</b> 25 Apr 2006</p> 6454<p> 6455In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to 6456find_first_of are specified to require Forward Iterators, as follows: 6457</p> 6458 6459<blockquote><pre>template<class ForwardIterator1, class ForwardIterator2> 6460 ForwardIterator1 6461 find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, 6462 ForwardIterator2 first2, ForwardIterator2 last2); 6463template<class ForwardIterator1, class ForwardIterator2, 6464 class BinaryPredicate> 6465ForwardIterator1 6466 find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, 6467 ForwardIterator2 first2, ForwardIterator2 last2, 6468 BinaryPredicate pred); 6469</pre></blockquote> 6470 6471<p> 6472However, ForwardIterator1 need not actually be a Forward Iterator; an Input 6473Iterator suffices, because we do not need the multi-pass property of the Forward 6474Iterator or a true reference. 6475</p> 6476<p><b>Proposed resolution:</b></p> 6477<p> 6478Change the declarations of <tt>find_first_of</tt> to: 6479</p> 6480 6481<blockquote><pre>template<class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2> 6482 <del>ForwardIterator1</del><ins>InputIterator1</ins> 6483 find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1, 6484 ForwardIterator2 first2, ForwardIterator2 last2); 6485template<class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2, 6486 class BinaryPredicate> 6487<del>ForwardIterator1</del><ins>InputIterator1</ins> 6488 find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1, 6489 ForwardIterator2 first2, ForwardIterator2 last2, 6490 BinaryPredicate pred); 6491</pre></blockquote> 6492 6493<hr> 6494<a name="577"><h3>577. upper_bound(first, last, ...) cannot return last</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 3 May 2006</p> 6495<p> 6496ISO/IEC 14882:2003 says: 6497</p> 6498 6499<blockquote> 6500<p> 650125.3.3.2 upper_bound 6502</p> 6503<p> 6504<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range 6505<tt>[<i>first</i>, <i>last</i>)</tt> such that 6506for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding 6507conditions hold: <tt>!(value < *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>. 6508</p> 6509</blockquote> 6510 6511<p> 6512From the description above, upper_bound cannot return last, since it's 6513not in the interval [first, last). This seems to be a typo, because if 6514value is greater than or equal to any other values in the range, or if 6515the range is empty, returning last seems to be the intended behaviour. 6516The corresponding interval for lower_bound is also [first, last]. 6517</p> 6518<p><b>Proposed resolution:</b></p> 6519<p> 6520Change [lib.upper.bound]: 6521</p> 6522 6523<blockquote> 6524<p> 6525<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range 6526<tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that 6527for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding 6528conditions hold: <tt>!(value < *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>. 6529</p> 6530</blockquote> 6531 6532<hr> 6533<a name="578"><h3>578. purpose of hint to allocator::allocate()</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 17 May 2006</p> 6534 <p> 6535 6536The description of the allocator member function 6537<code>allocate()</code> requires that the <i>hint</i> argument be 6538either 0 or a value previously returned from <code>allocate()</code>. 6539Footnote 227 further suggests that containers may pass the address of 6540an adjacent element as this argument. 6541 6542 </p> 6543 <p> 6544 6545I believe that either the footnote is wrong or the normative 6546requirement that the argument be a value previously returned from a 6547call to <code>allocate()</code> is wrong. The latter is supported by 6548the resolution to issue 20-004 proposed in c++std-lib-3736 by Nathan 6549Myers. In addition, the <i>hint</i> is an ordinary void* and not the 6550<code>pointer</code> type returned by <code>allocate()</code>, with 6551the two types potentially being incompatible and the requirement 6552impossible to satisfy. 6553 6554 </p> 6555 <p> 6556 6557See also c++std-lib-14323 for some more context on where this came up 6558(again). 6559 6560 </p> 6561 <p><b>Proposed resolution:</b></p> 6562 <p> 6563 6564Remove the requirement in 20.6.1.1, p4 that the hint be a value 6565previously returned from <code>allocate()</code>. Specifically, change 6566the paragraph as follows: 6567 6568 </p> 6569 <p> 6570 6571<i>Requires</i>: <i>hint</i> <ins>is </ins>either 0 or <del>previously 6572obtained from member <code>allocate</code> and not yet passed to 6573member <code>deallocate</code></del><ins> the address of a byte in 6574memory (1.7)</ins>. 6575 6576 </p> 6577 <hr> 6578<a name="579"><h3>579. erase(iterator) for unordered containers should not return an iterator</h3></a><p><b>Section:</b> 23.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.unord.req"> [lib.unord.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Joaqu�n M L�pez Mu�oz <b>Date:</b> 13 Jun 2006</p> 6579<p> 6580See 6581<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a> 6582for full discussion. 6583</p> 6584<p><b>Proposed resolution:</b></p> 6585<p> 6586Option 1: 6587</p> 6588 6589<p> 6590The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an 6591iterator. This is, however, in contrast with the equivalent requirements for other 6592standard containers. 6593</p> 6594 6595<p> 6596Option 2: 6597</p> 6598 6599<p> 6600<tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested: 6601the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so 6602that 6603</p> 6604 6605<blockquote><pre>iterator q1=a.erase(q); 6606</pre></blockquote> 6607 6608<p> 6609works as expected, while 6610</p> 6611 6612<blockquote><pre>a.erase(q); 6613</pre></blockquote> 6614 6615<p> 6616does not ever invoke the conversion-to-iterator operator, thus avoiding the associated 6617computation. To allow this technique, some sections of TR1 along the line "return value 6618is an iterator..." should be changed to "return value is an unspecified object implicitly 6619convertible to an iterator..." Although this trick is expected to work transparently, it can 6620have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic 6621code. 6622</p> 6623 6624<hr> 6625<a name="580"><h3>580. unused allocator members</h3></a><p><b>Section:</b> 20.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 14 June 2006</p> 6626 <p> 6627 6628C++ Standard Library templates that take an allocator as an argument 6629are required to call the <code>allocate()</code> and 6630<code>deallocate()</code> members of the allocator object to obtain 6631storage. However, they do not appear to be required to call any other 6632allocator members such as <code>construct()</code>, 6633<code>destroy()</code>, <code>address()</code>, and 6634<code>max_size()</code>. This makes these allocator members less than 6635useful in portable programs. 6636 6637 </p> 6638 <p><b>Proposed resolution:</b></p> 6639 <p> 6640 6641It's unclear to me whether the absence of the requirement to use these 6642allocator members is an unintentional omission or a deliberate 6643choice. However, since the functions exist in the standard allocator 6644and since they are required to be provided by any user-defined 6645allocator I believe the standard ought to be clarified to explictly 6646specify whether programs should or should not be able to rely on 6647standard containers calling the functions. 6648 6649 </p> 6650 <p> 6651 6652I propose that all containers be required to make use of these 6653functions. 6654 6655 </p> 6656 <hr> 6657<a name="581"><h3>581. <code>flush()</code> not unformatted function</h3></a><p><b>Section:</b> 27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 14 June 2006</p> 6658 <p> 6659 6660The resolution of issue 60 changed <code>basic_ostream::flush()</code> 6661so as not to require it to behave as an unformatted output function. 6662That has at least two in my opinion problematic consequences: 6663 6664 </p> 6665 <p> 6666 6667First, <code>flush()</code> now calls <code>rdbuf()->pubsync()</code> 6668unconditionally, without regard to the state of the stream. I can't 6669think of any reason why <code>flush()</code> should behave differently 6670from the vast majority of stream functions in this respect. 6671 6672 </p> 6673 <p> 6674 6675Second, <code>flush()</code> is not required to catch exceptions from 6676<code>pubsync()</code> or set <code>badbit</code> in response to such 6677events. That doesn't seem right either, as most other stream functions 6678do so. 6679 6680 </p> 6681 <p><b>Proposed resolution:</b></p> 6682 <p> 6683 6684I propose to revert the resolution of issue 60 with respect to 6685<code>flush()</code>. Specifically, I propose to change 27.6.2.6, p7 6686as follows: 6687 6688 </p> 6689 6690Effects: <ins>Behaves as an unformatted output function (as described 6691in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null 6692pointer, <ins>constructs a sentry object. If this object returns 6693<code>true</code> when converted to a value of type bool the function 6694</ins>calls <code>rdbuf()->pubsync()</code>. If that function returns 6695-1 calls <code>setstate(badbit)</code> (which may throw 6696<code>ios_base::failure</code> (27.4.4.3)). <ins>Otherwise, if the 6697sentry object returns <code>false</code>, does nothing.</ins><del>Does 6698not behave as an unformatted output function (as described in 669927.6.2.6, paragraph 1).</del> 6700 6701 <hr> 6702<a name="582"><h3>582. specialized algorithms and volatile storage</h3></a><p><b>Section:</b> 20.6.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.uninitialized.copy"> [lib.uninitialized.copy]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 14 June 2006</p> 6703 <p> 6704 6705The specialized algorithms [lib.specialized.algorithms] are specified 6706as having the general effect of invoking the following expression: 6707 6708 </p> 6709 <p> 6710 </p><pre> 6711new (static_cast<void*>(&*i)) 6712 typename iterator_traits<ForwardIterator>::value_type (x) 6713 6714 </pre> 6715 <p></p> 6716 <p> 6717 6718This expression is ill-formed when the type of the subexpression 6719<code>&*i</code> is some volatile-qualified <code>T</code>. 6720 6721 </p> 6722 <p><b>Proposed resolution:</b></p> 6723 <p> 6724 6725In order to allow these algorithms to operate on volatile storage I 6726propose to change the expression so as to make it well-formed even for 6727pointers to volatile types. Specifically, I propose the following 6728changes to clauses 20 and 24. Change 20.6.4.1, p1 to read: 6729 6730 </p> 6731 <p> 6732 </p><pre> 6733<i>Effects</i>: 6734 6735typedef typename iterator_traits<ForwardIterator>::pointer pointer; 6736typedef typename iterator_traits<ForwardIterator>::value_type value_type; 6737 6738for (; first != last; ++result, ++first) 6739 new (static_cast<void*>(const_cast<pointer>(&*result)) 6740 value_type (*first); 6741 6742 </pre> 6743 <p></p> 6744 <p> 6745 6746change 20.6.4.2, p1 to read 6747 6748 </p> 6749 <p> 6750 </p><pre> 6751<i>Effects</i>: 6752 6753typedef typename iterator_traits<ForwardIterator>::pointer pointer; 6754typedef typename iterator_traits<ForwardIterator>::value_type value_type; 6755 6756for (; first != last; ++result, ++first) 6757 new (static_cast<void*>(const_cast<pointer>(&*first)) 6758 value_type (*x); 6759 6760 </pre> 6761 <p></p> 6762 <p> 6763 6764and change 20.6.4.3, p1 to read 6765 6766 </p> 6767 <p> 6768 </p><pre> 6769<i>Effects</i>: 6770 6771typedef typename iterator_traits<ForwardIterator>::pointer pointer; 6772typedef typename iterator_traits<ForwardIterator>::value_type value_type; 6773 6774for (; n--; ++first) 6775 new (static_cast<void*>(const_cast<pointer>(&*first)) 6776 value_type (*x); 6777 6778 </pre> 6779 <p></p> 6780 <p> 6781 6782In addition, since there is no partial specialization for 6783<code>iterator_traits<volatile T*></code> I propose to add one 6784to parallel such specialization for <const T*>. Specifically, I 6785propose to add the following text to the end of 24.3.1, p3: 6786 6787 </p> 6788 <p> 6789 6790and for pointers to volatile as 6791 6792 </p> 6793 <p> 6794 </p><pre> 6795namespace std { 6796template<class T> struct iterator_traits<volatile T*> { 6797typedef ptrdiff_t difference_type; 6798typedef T value_type; 6799typedef volatile T* pointer; 6800typedef volatile T& reference; 6801typedef random_access_iterator_tag iterator_category; 6802}; 6803} 6804 6805 </pre> 6806 <p></p> 6807 <p> 6808 6809Note that the change to <code>iterator_traits</code> isn't necessary 6810in order to implement the specialized algorithms in a way that allows 6811them to operate on volatile strorage. It is only necesassary in order 6812to specify their effects in terms of <code>iterator_traits</code> as 6813is done here. Implementations can (and some do) achieve the same 6814effect by means of function template overloading. 6815 6816 </p> 6817 <hr> 6818<a name="583"><h3>583. div() for unsigned integral types</h3></a><p><b>Section:</b> 26.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 15 Jun 2006</p> 6819<p> 6820There is no div() function for unsigned integer types. 6821</p> 6822<p> 6823There are several possible resolutions. The simplest one is noted below. Other 6824possibilities include a templated solution. 6825</p> 6826<p><b>Proposed resolution:</b></p> 6827<p> 6828Add to 26.7 [lib.c.math] paragraph 8: 6829</p> 6830 6831<blockquote><pre>struct udiv_t div(unsigned, unsigned); 6832struct uldiv_t div(unsigned long, unsigned long); 6833struct ulldiv_t div(unsigned long long, unsigned long long); 6834</pre></blockquote> 6835 6836<hr> 6837<a name="584"><h3>584. missing int pow(int,int) functionality</h3></a><p><b>Section:</b> 26.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 15 Jun 2006</p> 6838<p> 6839There is no pow() function for any integral type. 6840</p> 6841<p><b>Proposed resolution:</b></p> 6842<p> 6843Add something like: 6844</p> 6845 6846<blockquote><pre>template< typename T> 6847T power( T x, int n ); 6848// requires: n >=0 6849</pre></blockquote> 6850<hr> 6851<a name="585"><h3>585. facet error reporting</h3></a><p><b>Section:</b> 22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Date:</b> 22 June 2006</p> 6852 <p> 6853 6854Section 22.2, paragraph 2 requires facet <code>get()</code> members 6855that take an <code>ios_base::iostate&</code> argument, 6856<code><i>err</i></code>, to ignore the (initial) value of the 6857argument, but to set it to <code>ios_base::failbit</code> in case of a 6858parse error. 6859 6860 </p> 6861 <p> 6862 6863We believe there are a few minor problems with this blanket 6864requirement in conjunction with the wording specific to each 6865<code>get()</code> member function. 6866 6867 </p> 6868 <p> 6869 6870First, besides <code>get()</code> there are other member functions 6871with a slightly different name (for example, 6872<code>get_date()</code>). It's not completely clear that the intent of 6873the paragraph is to include those as well, and at least one 6874implementation has interpreted the requirement literally. 6875 6876 </p> 6877 <p> 6878 6879Second, the requirement to "set the argument to 6880<code>ios_base::failbit</code> suggests that the functions are not 6881permitted to set it to any other value (such as 6882<code>ios_base::eofbit</code>, or even <code>ios_base::eofbit | 6883ios_base::failbit</code>). 6884 6885 </p> 6886 <p> 6887 6888However, 22.2.2.1.2, p5 (Stage 3 of <code>num_get</code> parsing) and 6889p6 (<code>bool</code> parsing) specifies that the <code>do_get</code> 6890functions perform <code><i>err</i> |= ios_base::eofbit</code>, which 6891contradicts the earlier requirement to ignore <i>err</i>'s initial 6892value. 6893 6894 </p> 6895 <p> 6896 689722.2.6.1.2, p1 (the Effects clause of the <code>money_get</code> 6898facet's <code>do_get</code> member functions) also specifies that 6899<code><i>err</i></code>'s initial value be used to compute the final 6900value by ORing it with either <code>ios_base::failbit</code> or 6901with<code>ios_base::eofbit | ios_base::failbit</code>. 6902 6903 </p> 6904 <p><b>Proposed resolution:</b></p> 6905 <p> 6906 6907We believe the intent is for all facet member functions that take an 6908<code>ios_base::iostate&</code> argument to: 6909 6910 </p> 6911 <p> 6912 </p><ul> 6913 <li> 6914 6915ignore the initial value of the <code><i>err</i></code> argument, 6916 6917 </li> 6918 <li> 6919 6920reset <code><i>err</i></code> to <code>ios_base::goodbit</code> prior 6921to any further processing, 6922 6923 </li> 6924 <li> 6925 6926and set either <code>ios_base::eofbit</code>, or 6927<code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as 6928appropriate, in response to reaching the end-of-file or on parse 6929error, or both. 6930 6931 </li> 6932 </ul> 6933 <p></p> 6934 <p> 6935 6936To that effect we propose to change 22.2, p2 as follows: 6937 6938 </p> 6939 <p> 6940 6941The <i>put</i><del>()</del> members make no provision for error 6942reporting. (Any failures of the OutputIterator argument must be 6943extracted from the returned iterator.) <ins>Unless otherwise 6944specified, </ins>the <i>get</i><del>()</del> members <ins>that</ins> 6945take an <code>ios_base::iostate&</code> argument <del>whose value 6946they ignore, but set to ios_base::failbit in case of a parse 6947error.</del><ins>, <code><i>err</i></code>, start by evaluating 6948<code>err = ios_base::goodbit</code>, and may subsequently set 6949<i>err</i> to either <code>ios_base::eofbit</code>, or 6950<code>ios_base::failbit</code>, or <code>ios_base::eofbit | 6951ios_base::failbit</code> in response to reaching the end-of-file or in 6952case of a parse error, or both, respectively.</ins> 6953 6954 </p> 6955 <hr> 6956<a name="586"><h3>586. string inserter not a formatted function</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 22 June 2006</p> 6957 <p> 6958 6959Section and paragraph numbers in this paper are relative to the 6960working draft document number N2009 from 4/21/2006. 6961 6962 </p> 6963 6964 <p> 6965 6966The <code>basic_string</code> extractor in 21.3.7.9, p1 is clearly 6967required to behave as a formatted input function, as is the 6968<code>std::getline()</code> overload for string described in p7. 6969 6970 </p> 6971 <p> 6972 6973However, the <code>basic_string</code> inserter described in p5 of the 6974same section has no such requirement. This has implications on how the 6975operator responds to exceptions thrown from <code>xsputn()</code> 6976(formatted output functions are required to set <code>badbit</code> 6977and swallow the exception unless <code>badbit</code> is also set in 6978<code>exceptions()</code>; the string inserter doesn't have any such 6979requirement). 6980 6981 </p> 6982 <p> 6983 6984I don't see anything in the spec for the string inserter that would 6985justify requiring it to treat exceptions differently from all other 6986similar operators. (If it did, I think it should be made this explicit 6987by saying that the operator "does not behave as a formatted output 6988function" as has been made customary by the adoption of the resolution 6989of issue 60). 6990 6991 </p> 6992 <p><b>Proposed resolution:</b></p> 6993 <p> 6994 6995I propose to change the Effects clause in 21.3.7.9, p5, as follows: 6996 6997 </p> 6998 <p> 6999 </p><blockquote> 7000 7001<i>Effects</i>: <del>Begins by constructing a sentry object k as if k 7002were constructed by typename <code>basic_ostream<charT, 7003traits>::sentry k (os)</code>. If <code>bool(k)</code> is 7004<code>true</code>, </del><ins>Behaves as a formatted output function 7005(27.6.2.5.1). After constructing a <code>sentry</code> object, if 7006this object returns <code>true</code> when converted to a value of 7007type <code>bool</code>, determines padding as described in 700822.2.2.2.2</ins>, then inserts the resulting sequence of characters 7009<code><i>seq</i></code> as if by calling <code>os.rdbuf()->sputn(seq , 7010n)</code>, where <code><i>n</i></code> is the larger of 7011<code>os.width()</code> and <code>str.size()</code>; then calls 7012<code>os.width(0)</code>. <del>If the call to sputn fails, calls 7013<code>os.setstate(ios_base::failbit)</code>.</del> 7014 7015 </blockquote> 7016 <p></p> 7017 <p> 7018 7019This proposed resilution assumes the resolution of issue 394 (i.e., 7020that all formatted output functions are required to set 7021<code>ios_base::badbit</code> in response to any kind of streambuf 7022failure), and implicitly assumes that a return value of 7023<code>sputn(seq, <i>n</i>)</code> other than <code><i>n</i></code> 7024indicates a failure. 7025 7026 </p> 7027 <hr> 7028<a name="587"><h3>587. iststream ctor missing description</h3></a><p><b>Section:</b> D.7.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.istrstream.cons"> [depr.istrstream.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 22 June 2006</p> 7029 <p> 7030 7031The <code>iststream(char*, streamsize)</code> ctor is in the class 7032synopsis in D.7.2 but its signature is missing in the description 7033below (in D.7.2.1). 7034 7035 </p> 7036 <p><b>Proposed resolution:</b></p> 7037 <p> 7038 7039This seems like a simple editorial issue and the missing signature can 7040be added to the one for <code>const char*</code> in paragraph 2. 7041 7042 </p> 7043 <hr> 7044<a name="588"><h3>588. requirements on zero sized tr1::arrays and other details</h3></a><p><b>Section:</b> 23.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array"> [lib.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Gennaro Prota <b>Date:</b> 18 Jul 2006</p> 7045<p> 7046The wording used for section 23.2.1 [lib.array] seems to be subtly 7047ambiguous about zero sized arrays (N==0). Specifically: 7048</p> 7049<p> 7050* "An instance of array<T, N> stores N elements of type T, so that 7051[...]" 7052</p> 7053<p> 7054Does this imply that a zero sized array object stores 0 elements, i.e. 7055that it cannot store any element of type T? The next point clarifies 7056the rationale behind this question, basically how to implement begin() 7057and end(): 7058</p> 7059<p> 7060* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() == 7061end() == unique value." 7062</p> 7063<p> 7064What does "unique" mean in this context? Let's consider the following 7065possible implementations, all relying on a partial specialization: 7066</p> 7067<blockquote><pre>a) 7068 template< typename T > 7069 class array< T, 0 > { 7070 7071 .... 7072 7073 iterator begin() 7074 { return iterator( reinterpret_cast< T * >( this ) ); } 7075 .... 7076 7077 }; 7078</pre></blockquote> 7079<p> 7080This has been used in boost, probably intending that the return value 7081had to be unique to the specific array object and that array couldn't 7082store any T. Note that, besides relying on a reinterpret_cast, has 7083(more than potential) alignment problems. 7084</p> 7085<blockquote><pre>b) 7086 template< typename T > 7087 class array< T, 0 > { 7088 7089 T t; 7090 7091 iterator begin() 7092 { return iterator( &t ); } 7093 .... 7094 7095 }; 7096</pre></blockquote> 7097<p> 7098This provides a value which is unique to the object and to the type of 7099the array, but requires storing a T. Also, it would allow the user to 7100mistakenly provide an initializer list with one element. 7101</p> 7102<p> 7103A slight variant could be returning *the* null pointer of type T 7104</p> 7105<blockquote><pre> return static_cast<T*>(0); 7106</pre></blockquote> 7107<p> 7108In this case the value would be unique to the type array<T, 0> but not 7109to the objects (all objects of type array<T, 0> with the same value 7110for T would yield the same pointer value). 7111</p> 7112<p> 7113Furthermore this is inconsistent with what the standard requires from 7114allocation functions (see library issue 9). 7115</p> 7116<p> 7117c) same as above but with t being a static data member; again, the 7118value would be unique to the type, not to the object. 7119</p> 7120<p> 7121d) to avoid storing a T *directly* while disallowing the possibility 7122to use a one-element initializer list a non-aggregate nested class 7123could be defined 7124</p> 7125<blockquote><pre> struct holder { holder() {} T t; } h; 7126</pre></blockquote> 7127<p> 7128and then begin be defined as 7129</p> 7130<blockquote><pre> iterator begin() { return &h.t; } 7131</pre></blockquote> 7132<p> 7133But then, it's arguable whether the array stores a T or not. 7134Indirectly it does. 7135</p> 7136<p> 7137----------------------------------------------------- 7138</p> 7139<p> 7140Now, on different issues: 7141</p> 7142<p> 7143* what's the effect of calling assign(T&) on a zero-sized array? There 7144seems to be only mention of front() and back(), in 23.2.1 [lib.array] 7145p4 (I would also suggest to move that bullet to section 23.2.1.5 7146[lib.array.zero], for locality of reference) 7147</p> 7148<p> 7149* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit 7150inconsistent with that of other sequences: that's not a problem in 7151itself, but compare it for instance with "A vector is a kind of 7152sequence that supports random access iterators"; though the intent is 7153obvious one might argue that the wording used for arrays doesn't tell 7154what an array is, and relies on the reader to infer that it is what 7155the <array> header defines. 7156</p> 7157<p> 7158* it would be desiderable to have a static const data member of type 7159std::size_t, with value N, for usage as integral constant expression 7160</p> 7161<p> 7162* section 23.1 [lib.container.requirements] seem not to consider 7163fixed-size containers at all, as it says: "[containers] control 7164allocation and deallocation of these objects [the contained objects] 7165through constructors, destructors, *insert and erase* operations" 7166</p> 7167<p> 7168* max_size() isn't specified: the result is obvious but, technically, 7169it relies on table 80: "size() of the largest possible container" 7170which, again, doesn't seem to consider fixed size containers 7171</p> 7172<p><b>Proposed resolution:</b></p> 7173<p> 7174</p> 7175<hr> 7176<a name="589"><h3>589. Requirements on iterators of member template functions of containers</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2 Aug 2006</p> 7177<p> 7178There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in 7179terms of their value_type, and the requirements in 23.1.2 appear to be overly strict 7180(requires InputIterator::value_type be the same type as the container's value_type). 7181</p> 7182<p><b>Proposed resolution:</b></p> 7183<p> 7184Change 23.1.1 p3: 7185</p> 7186 7187<blockquote> 7188In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a 7189value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input 7190iterator requirements <ins>and refer to elements <ins>implicitly 7191convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid 7192range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a 7193valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable 7194iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>, 7195and <tt>t</tt> denotes a value of <tt>X::value_type</tt>. 7196</blockquote> 7197 7198<p> 7199Change 23.1.2 p7: 7200</p> 7201 7202<blockquote> 7203In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value 7204of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports 7205unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports 7206multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and 7207refer to elements <del>of</del> <ins>implicitly convertible to</ins> 7208<tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid 7209iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to 7210<tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a 7211value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt> 7212and <tt>c</tt> is a value of type <tt>X::key_compare</tt>. 7213</blockquote> 7214 7215<hr> 7216<a name="590"></a><h3><a name="590">590. Type traits implementation latitude should be removed for C++0x</a></h3><p><b>Section:</b> <font color="red">20.4.9</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 10 Aug 2006</p> 7217<p> 721820.4.9 [lib.meta.req], Implementation requirements, provides latitude for type 7219traits implementers that is not needed in C++0x. It includes the wording: 7220</p> 7221 7222<blockquote> 7223[<i>Note:</i> the latitude granted to implementers in this clause is temporary, 7224and is expected to be removed in future revisions of this document. -- <i>end note</i>] 7225</blockquote> 7226 7227<p> 7228Note: 7229<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028: 7230Minor Modifications to the type traits Wording</a> 7231also has the intent of removing this wording from the WP. 7232</p> 7233 7234<p><b>Proposed resolution:</b></p> 7235<p> 7236Remove 20.4.9 [lib.meta.req] in its entirety from the WP. 7237</p> 7238<hr> 7239<a name="591"><h3>591. Misleading "built-in</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> whyglinux <b>Date:</b> 8 Aug 2006</p> 7240<p> 724118.2.1.2 numeric_limits members [lib.numeric.limits.members] 7242Paragraph 7: 7243</p> 7244<blockquote> 7245"For built-in integer types, the number of non-sign bits in the 7246representation." 7247</blockquote> 7248 7249<p> 725026.1 Numeric type requirements [lib.numeric.requirements] 7251Footnote: 7252</p> 7253 7254<blockquote> 7255"In other words, value types. These include built-in arithmetic types, 7256pointers, the library class complex, and instantiations of valarray for 7257value types." 7258</blockquote> 7259 7260<p> 7261Integer types (which are bool, char, wchar_t, and the signed and 7262unsigned integer types) and arithmetic types (which are integer and 7263floating types) are all built-in types and thus there are no 7264non-built-in (that is, user-defined) integer or arithmetic types. Since 7265the redundant "built-in" in the above 2 sentences can mislead that 7266there may be built-in or user-defined integer and arithmetic types 7267(which is not correct), the "built-in" should be removed. 7268</p> 7269<p><b>Proposed resolution:</b></p> 7270<p> 7271</p><p> 727218.2.1.2 numeric_limits members [lib.numeric.limits.members] 7273Paragraph 7: 7274</p> 7275<blockquote> 7276"For <del>built-in</del> integer types, the number of non-sign bits in the 7277representation." 7278</blockquote> 7279 7280<p> 728126.1 Numeric type requirements [lib.numeric.requirements] 7282Footnote: 7283</p> 7284 7285<blockquote> 7286"In other words, value types. These include <del>built-in</del> arithmetic types, 7287pointers, the library class complex, and instantiations of valarray for 7288value types." 7289</blockquote> 7290<p></p> 7291<hr> 7292<a name="592"><h3>592. Incorrect treatment of rdbuf()->close() return type</h3></a><p><b>Section:</b> 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 17 Aug 2006</p> 7293<p> 7294I just spotted a minor problem in 27.8.1.7 7295[lib.ifstream.members] para 4 and also 27.8.1.13 7296[lib.fstream.members] para 4. In both places it says: 7297</p> 7298<blockquote> 7299<pre>void close(); 7300</pre> 7301<p> 7302Effects: Calls rdbuf()->close() and, if that function returns false, ... 7303</p> 7304</blockquote> 7305<p> 7306However, basic_filebuf::close() (27.8.1.2) returns a pointer to the 7307filebuf on success, null on failure, so I think it is meant to 7308say "if that function returns a null pointer". Oddly, it is 7309correct for basic_ofstream. 7310</p> 7311<p><b>Proposed resolution:</b></p> 7312<p> 7313Change 27.8.1.7 [lib.ifstream.members], p5: 7314</p> 7315 7316<blockquote> 7317<i>Effects:</i> Calls <tt>rdbuf()->close()</tt> and, if that function 7318<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>, 7319calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt> 7320(27.4.4.3)). 7321</blockquote> 7322 7323<p> 7324Change 27.8.1.13 [lib.fstream.members], p5: 7325</p> 7326 7327<blockquote> 7328<i>Effects:</i> Calls <tt>rdbuf()->close()</tt> and, if that function 7329<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>, 7330calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt> 7331(27.4.4.3)). 7332</blockquote> 7333 7334<hr> 7335<a name="593"><h3>593. __STDC_CONSTANT_MACROS</h3></a><p><b>Section:</b> 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.cstdint"> [lib.cstdint]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 28 Aug 2006</p> 7336<p> 7337Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers 7338<cstdint> and <stdint.h>. These are of course based on the C99 header 7339<stdint.h>, and were part of TR1. 7340</p> 7341 7342<p> 7343Per 18.3.1/1, these headers define a number of macros and function macros. 7344While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99 7345footnotes do mention __STDC_CONSTANT_MACROS. Further, 18.3.1/2 states that "The 7346header defines all ... macros the same as C99 subclause 7.18." 7347</p> 7348 7349<p> 7350Therefore, if I wish to have the above-referenced macros and function macros 7351defined, must I #define __STDC_CONSTANT_MACROS before I #include <cstdint>, or 7352does the C++ header define these macros/function macros unconditionally? 7353</p> 7354<p><b>Proposed resolution:</b></p> 7355<p> 7356To put this issue to rest for C++0X, I propose the following addition to 735718.3.1/2 of the Working Paper N2009: 7358</p> 7359 7360<blockquote> 7361[Note: The macros defined by <cstdint> are provided unconditionally: in 7362particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS 7363(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note] 7364</blockquote> 7365<hr> 7366<a name="594"><h3>594. Disadvantages of defining Swappable in terms of 7367CopyConstructible and Assignable</h3></a><p><b>Section:</b> 20.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.swappable"> [lib.swappable]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Niels Dekker <b>Date:</b> 2 Nov 2006</p> 7368<p> 7369It seems undesirable to define the Swappable requirement in terms of 7370CopyConstructible and Assignable requirements. And likewise, once the 7371MoveConstructible and MoveAssignable requirements (N1860) have made it 7372into the Working Draft, it seems undesirable to define the Swappable 7373requirement in terms of those requirements. Instead, it appears 7374preferable to have the Swappable requirement defined exclusively in 7375terms of the existence of an appropriate swap function. 7376</p> 7377<p> 7378Section 20.1.4 [lib.swappable] of the current Working Draft (N2009) 7379says: 7380</p><blockquote> 7381The Swappable requirement is met by satisfying one or more of the 7382following conditions: 7383<ul> 7384<li> 7385T is Swappable if T satisfies the CopyConstructible requirements 7386(20.1.3) and the Assignable requirements (23.1); 7387</li> 7388<li> 7389T is Swappable if a namespace scope function named swap exists in the 7390same namespace as the definition of T, such that the expression 7391swap(t,u) is valid and has the semantics described in Table 33. 7392</li> 7393</ul> 7394</blockquote> 7395I can think of three disadvantages of this definition: 7396<ol> 7397<li> 7398If a client's type T satisfies the first condition (T is both 7399CopyConstructible and Assignable), the client cannot stop T from 7400satisfying the Swappable requirement without stopping T from 7401satisfying the first condition. 7402<p> 7403A client might want to stop T from satisfying the Swappable 7404requirement, because swapping by means of copy construction and 7405assignment might throw an exception, and she might find a throwing 7406swap unacceptable for her type. On the other hand, she might not feel 7407the need to fully implement her own swap function for this type. In 7408this case she would want to be able to simply prevent algorithms that 7409would swap objects of type T from being used, e.g., by declaring a 7410swap function for T, and leaving this function purposely undefined. 7411This would trigger a link error, if an attempt would be made to use 7412such an algorithm for this type. For most standard library 7413implementations, this practice would indeed have the effect of 7414stopping T from satisfying the Swappable requirement. 7415</p> 7416</li> 7417<li> 7418A client's type T that does not satisfy the first condition can not be 7419made Swappable by providing a specialization of std::swap for T. 7420<p> 7421While I'm aware about the fact that people have mixed feelings about 7422providing a specialization of std::swap, it is well-defined to do so. 7423It sounds rather counter-intuitive to say that T is not Swappable, if 7424it has a valid and semantically correct specialization of std::swap. 7425Also in practice, providing such a specialization will have the same 7426effect as satisfying the Swappable requirement. 7427</p> 7428</li> 7429<li> 7430For a client's type T that satisfies both conditions of the Swappable 7431requirement, it is not specified which of the two conditions prevails. 7432After reading section 20.1.4 [lib.swappable], one might wonder whether 7433objects of T will be swapped by doing copy construction and 7434assignments, or by calling the swap function of T. 7435<p> 7436I'm aware that the intention of the Draft is to prefer calling the 7437swap function of T over doing copy construction and assignments. Still 7438in my opinion, it would be better to make this clear in the wording of 7439the definition of Swappable. 7440</p> 7441</li> 7442</ol> 7443<p></p> 7444<p> 7445I would like to have the Swappable requirement defined in such a way 7446that the following code fragment will correctly swap two objects of a 7447type T, if and only if T is Swappable: 7448</p><pre> using std::swap; 7449 swap(t, u); // t and u are of type T. 7450</pre> 7451This is also the way Scott Meyers recommends calling a swap function, 7452in Effective C++, Third Edition, item 25. 7453<p></p> 7454<p> 7455Most aspects of this issue have been dealt with in a discussion on 7456comp.std.c++ about the Swappable requirement, from 13 September to 4 7457October 2006, including valuable input by David Abrahams, Pete Becker, 7458Greg Herlihy, Howard Hinnant and others. 7459</p> 7460<p><b>Proposed resolution:</b></p> 7461<p> 7462Change section 20.1.4 [lib.swappable] as follows: 7463</p> 7464<blockquote> 7465The Swappable requirement is met by satisfying 7466<del>one or more of the following conditions:</del> 7467<ins>the following condition:</ins> 7468<ul> 7469<del> 7470<li> 7471T is Swappable if T satisfies the CopyConstructible requirements 7472(20.1.3) and the Assignable requirements (23.1); 7473</li> 7474</del> 7475<li> 7476<del> 7477T is Swappable if a namespace scope function named swap exists in the 7478same namespace as the definition of T, such that the expression 7479swap(t,u) is valid and has the semantics described in Table 33. 7480</del> 7481T is Swappable if an unqualified function call swap(t,u) is valid 7482within the namespace std, and has the semantics described in Table 33. 7483</li> 7484</ul> 7485</blockquote> 7486<hr> 7487<a name="595"><h3>595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified</h3></a><p><b>Section:</b> 26.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Stefan Gro�e Pawig <b>Date:</b> 24 Sep 2006</p> 7488<p> 7489TR1 introduced, in the C compatibility chapter, the function 7490fabs(complex<T>): 7491</p> 7492<blockquote><pre>----- SNIP ----- 74938.1.1 Synopsis [tr.c99.cmplx.syn] 7494 7495 namespace std { 7496 namespace tr1 { 7497[...] 7498 template<class T> complex<T> fabs(const complex<T>& x); 7499 } // namespace tr1 7500 } // namespace std 7501 7502[...] 7503 75048.1.8 Function fabs [tr.c99.cmplx.fabs] 7505 75061 Effects: Behaves the same as C99 function cabs, defined in 7507 subclause 7.3.8.1. 7508----- SNIP ----- 7509</pre></blockquote> 7510 7511<p> 7512The current C++0X draft document (n2009.pdf) adopted this 7513definition in chapter 26.3.1 (under the comment // 26.3.7 values) 7514and 26.3.7/7. 7515</p> 7516<p> 7517But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document 7518n1124), the referenced subclause reads 7519</p> 7520 7521<blockquote><pre>----- SNIP ----- 75227.3.8.1 The cabs functions 7523 7524 Synopsis 7525 75261 #include <complex.h> 7527 double cabs(double complex z); 7528 float cabsf(float complex z); 7529 long double cabsl(long double z); 7530 7531 Description 7532 75332 The cabs functions compute the complex absolute value (also called 7534 norm, modulus, or magnitude) of z. 7535 7536 Returns 7537 75383 The cabs functions return the complex absolute value. 7539----- SNIP ----- 7540</pre></blockquote> 7541 7542<p> 7543Note that the return type of the cabs*() functions is not a complex 7544type. Thus, they are equivalent to the already well established 7545 template<class T> T abs(const complex<T>& x); 7546(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft 7547document n2009.pdf). 7548</p> 7549<p> 7550So either the return value of fabs() is specified wrongly, or fabs() 7551does not behave the same as C99's cabs*(). 7552</p> 7553<p><b>Proposed resolution:</b></p> 7554<p> 7555This depends on the intention behind the introduction of fabs(). 7556</p> 7557<p> 7558If the intention was to provide a /complex/ valued function that 7559calculates the magnitude of its argument, this should be 7560explicitly specified. In TR1, the categorization under "C 7561compatibility" is definitely wrong, since C99 does not provide 7562such a complex valued function. 7563</p> 7564<p> 7565Also, it remains questionable if such a complex valued function 7566is really needed, since complex<T> supports construction and 7567assignment from real valued arguments. There is no difference 7568in observable behaviour between 7569</p> 7570<blockquote><pre> complex<double> x, y; 7571 y = fabs(x); 7572 complex<double> z(fabs(x)); 7573</pre></blockquote> 7574<p> 7575and 7576</p> 7577<blockquote><pre> complex<double> x, y; 7578 y = abs(x); 7579 complex<double> z(abs(x)); 7580</pre></blockquote> 7581<p> 7582If on the other hand the intention was to provide the intended 7583functionality of C99, fabs() should be either declared deprecated 7584or (for C++0X) removed from the standard, since the functionality 7585is already provided by the corresponding overloads of abs(). 7586</p> 7587<hr> 7588<a name="596"><h3>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3></a><p><b>Section:</b> 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Thomas Plum <b>Date:</b> 26 Sep 2006</p> 7589<p> 7590In testing 27.8.1.3, Table 112 (in the latest N2009 draft), we invoke 7591</p> 7592<blockquote><pre> ostr.open("somename", ios_base::out | ios_base::in | ios_base::app) 7593</pre></blockquote> 7594<p> 7595and we expect the open to fail, because out|in|app is not listed in 7596Table 92, and just before the table we see very specific words: 7597</p> 7598<blockquote> 7599 If mode is not some combination of flags shown in the table 7600 then the open fails. 7601</blockquote> 7602<p> 7603But the corresponding table in the C standard, 7.19.5.3, provides two 7604modes "a+" and "a+b", to which the C++ modes out|in|app and 7605out|in|app|binary would presumably apply. 7606</p> 7607<p><b>Proposed resolution:</b></p> 7608<p> 7609We would like to argue that the intent of Table 112 was to match the 7610semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was 7611unintentional. (Otherwise there would be valid and useful behaviors 7612available in C file I/O which are unavailable using C++, for no 7613valid functional reason.) 7614</p> 7615<p> 7616We further request that the missing modes be explicitly restored to 7617the WP, for inclusion in C++0x. 7618</p> 7619<hr> 7620<a name="597"><h3>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3></a><p><b>Section:</b> <font color="red">Decimal 3.2</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 5 April 2006</p> 7621<p> 7622In a private email, Daveed writes: 7623</p> 7624<blockquote> 7625<p> 7626I am not familiar with the C TR, but my guess is that the 7627class type approach still won't match a built-in type 7628approach because the notion of "promotion" cannot be 7629emulated by user-defined types. 7630</p> 7631<p> 7632Here is an example: 7633</p> 7634</blockquote> 7635<pre> 7636 struct S { 7637 S(_Decimal32 const&); // Converting constructor 7638 }; 7639 void f(S); 7640 7641 void f(_Decimal64); 7642 7643 void g(_Decimal32 d) { 7644 f(d); 7645 } 7646</pre> 7647 7648<blockquote> 7649<p> 7650If _Decimal32 is a built-in type, the call f(d) will likely 7651resolve to f(_Decimal64) because that requires only a 7652promotion, whereas f(S) requires a user-defined conversion. 7653</p> 7654<p> 7655If _Decimal32 is a class type, I think the call f(d) will be 7656ambiguous because both the conversion to _Decimal64 and the 7657conversion to S will be user-defined conversions with neither 7658better than the other. 7659</p> 7660</blockquote> 7661<p> 7662Robert comments: 7663</p> 7664<p>In general, a library of arithmetic types cannot exactly emulate the 7665behavior of the intrinsic numeric types. There are several ways to tell 7666whether an implementation of the decimal types uses compiler 7667intrinisics or a library. For example: 7668</p> 7669<pre> _Decimal32 d1; 7670 d1.operator+=(5); // If d1 is a builtin type, this won't compile. 7671</pre> 7672<p> 7673In preparing the decimal TR, we have three options: 7674</p> 7675<ol> 7676<li>require that the decimal types be class types</li> 7677<li>require that the decimal types be builtin types, like float and double</li> 7678<li>specify a library of class types, but allow enough implementor 7679latitude that a conforming implementation could instead provide builtin 7680types</li> 7681</ol> 7682<p> 7683We decided as a group to pursue option #3, but that approach implies 7684that implementations may not agree on the semantics of certain use 7685cases (first example, above), or on whether certain other cases are 7686well-formed (second example). Another potentially important problem is 7687that, under the present definition of POD, the decimal classes are not 7688POD types, but builtins will be. 7689</p> 7690<p>Note that neither example above implies any problems with respect to 7691C-to-C++ compatibility, since neither example can be expressed in C. 7692</p> 7693<p><b>Proposed resolution:</b></p> 7694<hr> 7695<a name="598"><h3>598. Decimal: Conversion to integral should truncate, not round.</h3></a><p><b>Section:</b> <font color="red">Decimal 3.2</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 28 May 2006</p> 7696 7697<p> 7698In a private email, Daniel writes: 7699</p> 7700<blockquote> 7701<p> 7702I would like to 7703ask, what where the reason for the decision to 7704define the semantics of the integral conversion of the decimal types, namely 7705</p> 7706<pre>"operator long long() const; 7707 7708 Returns: Returns the result of the 7709conversion of *this to the type long long, as if 7710performed by the expression llrounddXX(*this)." 7711</pre> 7712<p> 7713where XX stands for either 32, 64, or 128, 7714corresponding to the proper decimal type. The 7715exact meaning of llrounddXX is not given in that 7716paper, so I compared it to the corresponding 7717definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2: 7718</p> 7719<p> 7720"The lround and llround functions round their 7721argument to the nearest integer value, 7722rounding halfway cases away from zero, regardless 7723of the current rounding direction. [..]" 7724</p> 7725<p> 7726Now considering the fact that integral conversion 7727of the usual floating-point types ("4.9 7728Floating-integral conversions") has truncation 7729semantic I wonder why this conversion behaviour 7730has not been transferred for the decimal types. 7731</p> 7732</blockquote> 7733<p> 7734Robert comments: 7735</p> 7736<p> 7737Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>. It currently calls <code>llroundd64</code>, not <code>llroundd128</code>. 7738</p> 7739 7740<p><b>Proposed resolution:</b></p> 7741<p> 7742Change the <b>Returns:</b> clause in 3.2.2.4 to: 7743</p> 7744<blockquote> 7745<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>. 7746</blockquote> 7747<p> 7748Change the <b>Returns:</b> clause in 3.2.3.4 to: 7749</p> 7750<blockquote> 7751<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>. 7752</blockquote> 7753<p> 7754Change the <b>Returns:</b> clause in 3.2.4.4 to: 7755</p> 7756<blockquote> 7757<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>. 7758</blockquote> 7759 7760<hr> 7761<a name="599"><h3>599. Decimal: Say "octets" instead of "bytes."</h3></a><p><b>Section:</b> <font color="red">Decimal 3.1</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 28 May 2006</p> 7762<p> 7763Daniel writes in a private email: 7764</p> 7765 7766<blockquote> 7767<p> 7768- 3.1 'Decimal type encodings' says in its note: 7769</p> 7770<p> 7771"this implies that 7772sizeof(std::decimal::decimal32) == 4, 7773sizeof(std::decimal::decimal64) == 8, and 7774sizeof(std::decimal::decimal128) == 16." 7775</p><p> 7776</p> 7777This is a wrong assertion, because the definition 7778of 'byte' in 1.7 'The C+ + memory model' of ISO 777914882 (2nd edition) does not specify that a byte 7780must be necessarily 8 bits large, which would be 7781necessary to compare with the specified bit sizes 7782of the types decimal32, decimal64, and decimal128. 7783<p></p> 7784</blockquote> 7785<p><b>Proposed resolution:</b></p> 7786<p> 7787Change 3.1 as follows: 7788</p> 7789<blockquote> 7790<p> 7791The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows: 7792</p> 7793<ul> 7794<li> 7795decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits) 7796</li> 7797<li> 7798decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits) 7799 7800</li> 7801<li> 7802decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits) 7803</li> 7804</ul> 7805<p> 7806<del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>. <i>--end note</i>]</del> 7807</p> 7808</blockquote> 7809<hr> 7810<a name="600"><h3>600. Decimal: Wrong parameters for wcstod* functions</h3></a><p><b>Section:</b> <font color="red">Decimal 3.9</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 28 May 2006</p> 7811<p> 7812Daniel writes: 7813</p> 7814<blockquote> 7815- 3.9.1 'Additions to <cwchar>' provides wrong 7816signatures to the wcstod32, wcstod64, and 7817wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t). 7818</blockquote> 7819<p><b>Proposed resolution:</b></p> 7820<p> 7821Change "3.9.1 Additions to <code><cwchar></code> synopsis" to: 7822</p> 7823<pre> namespace std { 7824 namespace decimal { 7825 // 3.9.2 wcstod functions: 7826 decimal32 wcstod32 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr); 7827 decimal64 wcstod64 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr); 7828 decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr); 7829 } 7830 } 7831</pre> 7832<hr> 7833<a name="601"><h3>601. Decimal: numeric_limits typos</h3></a><p><b>Section:</b> <font color="red">Decimal 3.3</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 28 May 2006</p> 7834<p> 7835Daniel writes in a private email: 7836</p> 7837 7838<blockquote> 7839<p> 7840- 3.3 'Additions to header <limits>' contains two 7841errors in the specialisation of numeric_limits<decimal::decimal128>: 7842</p> 7843<ol> 7844<li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li> 7845<li>The static member digits is assigned to 384, 7846this should be 34 (Probably mixed up with the 7847max. exponent for decimal::decimal64).</li> 7848</ol> 7849</blockquote> 7850<p><b>Proposed resolution:</b></p> 7851<p> 7852In "3.3 Additions to header <code><limits></code>" change numeric_limits<decimal::decimal128> as follows: 7853</p> 7854<pre> template<> class numeric_limits<decimal::decimal128> { 7855 public: 7856 static const bool is_specialized = true; 7857 7858 static decimal::decimal128 min() throw() { return DEC128_MIN; } 7859 static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> } 7860 7861 static const int digits = <del>384</del> <ins>34</ins>; 7862 /* ... */ 7863</pre> 7864<hr> 7865<a name="602"><h3>602. Decimal: "generic floating type" not defined.</h3></a><p><b>Section:</b> <font color="red">Decimal 3</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 28 May 2006</p> 7866<p> 7867The document uses the term "generic floating types," but defines it nowhere. 7868</p> 7869<p><b>Proposed resolution:</b></p> 7870<p> 7871Change the first paragraph of "3 Decimal floating-point types" as follows: 7872</p> 7873<blockquote> 7874This Technical Report introduces three decimal floating-point types, named 7875decimal32, decimal64, and decimal128. The set of values of type decimal32 is a 7876subset of the set of values of type decimal64; the set of values of the type 7877decimal64 is a subset of the set of values of the type decimal128. Support for 7878decimal128 is optional. <ins>These types supplement the Standard C++ types 7879<code>float</code>, <code>double</code>, and <code>long double</code>, which are 7880collectively described as the <i>basic floating types</i></ins>. 7881</blockquote> 7882<hr> 7883<a name="603"><h3>603. Decimal: Trivially simplifying decimal classes.</h3></a><p><b>Section:</b> <font color="red">Decimal 3</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 May 2006</p> 7884<p>In c++std-lib-17198, Martin writes:</p> 7885 7886<blockquote> 7887Each of the three classes proposed in the paper (decimal32, decimal64, 7888and decimal128) explicitly declares and specifies the semantics of its 7889copy constructor, copy assignment operator, and destructor. Since the 7890semantics of all three functions are identical to the trivial versions 7891implicitly generated by the compiler in the absence of any declarations 7892it is safe to drop them from the spec. This change would make the 7893proposed classes consistent with other similar classes already in the 7894standard (e.g., std::complex). 7895</blockquote> 7896<p><b>Proposed resolution:</b></p> 7897<p> 7898Change "3.2.2 Class <code>decimal32</code>" as follows: 7899</p> 7900<pre> namespace std { 7901 namespace decimal { 7902 class decimal32 { 7903 public: 7904 // 3.2.2.1 construct/copy/destroy: 7905 decimal32(); 7906 <del>decimal32(const decimal32 & d32);</del> 7907 <del>decimal32 & operator=(const decimal32 & d32);</del> 7908 <del>~decimal32();</del> 7909 /* ... */ 7910</pre> 7911<p> 7912Change "3.2.2.1 construct/copy/destroy" as follows: 7913</p> 7914<pre> decimal32(); 7915 7916 Effects: Constructs an object of type decimal32 with the value 0; 7917 7918 <del>decimal32(const decimal32 & d32);</del> 7919 <del>decimal32 & operator=(const decimal32 & d32);</del> 7920 7921 <del>Effects: Copies an object of type decimal32.</del> 7922 7923 <del>~decimal32();</del> 7924 7925 <del>Effects: Destroys an object of type decimal32.</del> 7926 7927</pre> 7928<p> 7929Change "3.2.3 Class <code>decimal64</code>" as follows: 7930</p> 7931<pre> namespace std { 7932 namespace decimal { 7933 class decimal64 { 7934 public: 7935 // 3.2.3.1 construct/copy/destroy: 7936 decimal64(); 7937 <del>decimal64(const decimal64 & d64);</del> 7938 <del>decimal64 & operator=(const decimal64 & d64);</del> 7939 <del>~decimal64();</del> 7940 /* ... */ 7941</pre> 7942<p> 7943Change "3.2.3.1 construct/copy/destroy" as follows: 7944</p> 7945<pre> decimal64(); 7946 7947 Effects: Constructs an object of type decimal64 with the value 0; 7948 7949 <del>decimal64(const decimal64 & d64);</del> 7950 <del>decimal64 & operator=(const decimal64 & d64);</del> 7951 7952 <del>Effects: Copies an object of type decimal64.</del> 7953 7954 <del>~decimal64();</del> 7955 7956 <del>Effects: Destroys an object of type decimal64.</del> 7957 7958</pre> 7959<p> 7960Change "3.2.4 Class <code>decimal128</code>" as follows: 7961</p> 7962<pre> namespace std { 7963 namespace decimal { 7964 class decimal128 { 7965 public: 7966 // 3.2.4.1 construct/copy/destroy: 7967 decimal128(); 7968 <del>decimal128(const decimal128 & d128);</del> 7969 <del>decimal128 & operator=(const decimal128 & d128);</del> 7970 <del>~decimal128();</del> 7971 /* ... */ 7972</pre> 7973<p> 7974Change "3.2.4.1 construct/copy/destroy" as follows: 7975</p> 7976<pre> decimal128(); 7977 7978 Effects: Constructs an object of type decimal128 with the value 0; 7979 7980 <del>decimal128(const decimal128 & d128);</del> 7981 <del>decimal128 & operator=(const decimal128 & d128);</del> 7982 7983 <del>Effects: Copies an object of type decimal128.</del> 7984 7985 <del>~decimal128();</del> 7986 7987 <del>Effects: Destroys an object of type decimal128.</del> 7988 7989</pre> 7990<hr> 7991<a name="604"><h3>604. Decimal: Storing a reference to a facet unsafe.</h3></a><p><b>Section:</b> <font color="red">Decimal 3</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 May 2006</p> 7992<p> 7993In c++std-lib-17197, Martin writes: 7994</p> 7995<blockquote> 7996The extended_num_get and extended_num_put facets are designed 7997to store a reference to a num_get or num_put facet which the 7998extended facets delegate the parsing and formatting of types 7999other than decimal. One form of the extended facet's ctor (the 8000default ctor and the size_t overload) obtains the reference 8001from the global C++ locale while the other form takes this 8002reference as an argument. 8003</blockquote> 8004<blockquote> 8005The problem with storing a reference to a facet in another 8006object (as opposed to storing the locale object in which the 8007facet is installed) is that doing so bypasses the reference 8008counting mechanism designed to prevent a facet that is still 8009being referenced (i.e., one that is still installed in some 8010locale) from being destroyed when another locale that contains 8011it is destroyed. Separating a facet reference from the locale 8012it comes from van make it cumbersome (and in some cases might 8013even make it impossible) for programs to prevent invalidating 8014the reference. (The danger of this design is highlighted in 8015the paper.) 8016</blockquote> 8017<blockquote> 8018This problem could be easily avoided by having the extended 8019facets store a copy of the locale from which they would extract 8020the base facet either at construction time or when needed. To 8021make it possible, the forms of ctors of the extended facets that 8022take a reference to the base facet would need to be changed to 8023take a locale argument instead. 8024</blockquote> 8025<p><b>Proposed resolution:</b></p> 8026<p> 80271. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows: 8028</p> 8029<pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0); 8030 8031 /* ... */ 8032 8033 <del>// <i>const std::num_get<charT, InputIterator> & <b>base</b></i>; <i><b>exposition only</b></i></del> 8034 <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins> 8035</pre> 8036<p> 80372. Change the description of the above constructor in 3.10.2.1: 8038</p> 8039<pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0); 8040 8041</pre> 8042<blockquote> 8043<p> 8044<b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by: 8045</p> 8046<pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0) 8047 : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>) 8048 { /* ... */ } 8049 8050</pre> 8051<p> 8052<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del> 8053</p> 8054</blockquote> 8055<p> 80563. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const</code>, <i>et al</i> to 8057</p> 8058<blockquote> 8059<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_get<charT, InputIterator> >(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>. 8060</blockquote> 8061<p> 80624. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows: 8063</p> 8064<pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0); 8065 8066 /* ... */ 8067 8068 <del>// <i>const std::num_put<charT, OutputIterator> & <b>base</b></i>; <i><b>exposition only</b></i></del> 8069 <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins> 8070</pre> 8071<p> 80725. Change the description of the above constructor in 3.10.3.1: 8073</p> 8074<pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0); 8075</pre> 8076<blockquote> 8077<p> 8078<b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by: 8079</p> 8080<pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0) 8081 : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>) 8082 { /* ... */ } 8083 8084</pre> 8085<p> 8086<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del> 8087</p> 8088</blockquote> 8089<p> 80906. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &, char_type, bool &) const</code>, <i>et al</i> to 8091</p> 8092<blockquote> 8093<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_put<charT, OutputIterator> >(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>. 8094</blockquote> 8095 8096<p><i>[ 8097Redmond: We would prefer to rename "extended" to "decimal". 8098]</i></p> 8099 8100<hr> 8101<a name="605"><h3>605. Decimal: <decfloat.h> doesn't live here anymore.</h3></a><p><b>Section:</b> <font color="red">Decimal 3.4</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 17 October 2006</p> 8102<p>In Berlin, WG14 decided to drop the <decfloat.h> header. The 8103contents of that header have been moved into <float.h>. For the 8104sake of C compatibility, we should make corresponding changes. 8105</p> 8106<p><b>Proposed resolution:</b></p> 8107<p> 81081. Change the heading of subclause 3.4, "Headers <code><cdecfloat></code> and <code><decfloat.h></code>" to "Additions to headers <code><cfloat></code> and <code><float.h></code>." 8109</p> 8110<p> 81112. Change the text of subclause 3.4 as follows: 8112</p> 8113<blockquote> 8114<p> 8115<del>The standard C++ headers <code><cfloat></code> and <code><float.h></code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>. Their contents remain unchanged by this Technical Report.</del> 8116</p> 8117<p> 8118<del>Headers <code><cdecfloat></code> and <code><decfloat.h></code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><decfloat.h></code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del> 8119</p> 8120<p> 8121<ins>The header <code><cfloat></code> is described in [tr.c99.cfloat]. The header <code><float.h></code> 8122is described in [tr.c99.floath]. These headers are extended by this 8123Technical Report to define characteristics of the decimal 8124floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><float.h></code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins> 8125</p> 8126</blockquote> 8127<p> 81283. Change the heading of subclause 3.4.1, "Header <code><cdecfloat></code> synopsis" to "Additions to header <code><cfloat></code> synopsis." 8129</p> 8130<p> 81314. Change the heading of subclause 3.4.2, "Header <code><decfloat.h></code> synopsis" to "Additions to header <code><float.h></code> synopsis." 8132</p> 8133<p> 81345. Change the contents of 3.4.2 as follows: 8135</p> 8136<pre> <del>#include <cdecfloat></del> 8137 8138 // <i>C-compatibility convenience typedefs:</i> 8139 8140 typedef std::decimal::decimal32 _Decimal32; 8141 typedef std::decimal::decimal64 _Decimal64; 8142 typedef std::decimal::decimal128 _Decimal128; 8143</pre> 8144 8145<hr> 8146<a name="606"><h3>606. Decimal: allow narrowing conversions</h3></a><p><b>Section:</b> <font color="red">Decimal 3.2</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 June 2006</p> 8147<p> 8148In c++std-lib-17205, Martin writes: 8149</p> 8150<blockquote> 8151...was it a deliberate design choice to make narrowing assignments 8152ill-formed while permitting narrowing compound assignments? For 8153instance: 8154</blockquote> 8155<pre> decimal32 d32; 8156 decimal64 d64; 8157 8158 d32 = 64; // error 8159 d32 += 64; // okay 8160</pre> 8161<p> 8162In c++std-lib-17229, Robert responds: 8163</p> 8164<blockquote>It is a vestige of an old idea that I forgot to remove from 8165the paper. Narrowing assignments should be permitted. The bug is that 8166the converting constructors that cause narrowing should not be 8167explicit. Thanks for pointing this out. 8168</blockquote> 8169<p><b>Proposed resolution:</b></p> 8170<p> 81711. In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions: 8172</p> 8173<pre> // <i>3.2.2.2 conversion from floating-point type:</i> 8174 <del>explicit</del> decimal32(decimal64 <i>d64</i>); 8175 <del>explicit</del> decimal32(decimal128 <i>d128</i>); 8176</pre> 8177<p> 81782. Do the same thing in "3.2.2.2. Conversion from floating-point type." 8179</p> 8180<p> 81813. In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion: 8182</p> 8183<pre> // <i>3.2.3.2 conversion from floating-point type:</i> 8184 <del>explicit</del> decimal64(decimal128 <i>d128</i>); 8185</pre> 8186<p> 81874. Do the same thing in "3.2.3.2. Conversion from floating-point type." 8188</p> 8189 8190<p><i>[ 8191Redmond: We prefer explicit conversions for narrowing and implicit for widening. 8192]</i></p> 8193 8194<hr> 8195<a name="607"><h3>607. Concern about short seed vectors</h3></a><p><b>Section:</b> 26.4.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.dist.iunif"> [lib.rand.dist.iunif]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Charles Karney <b>Date:</b> 26 Oct 2006</p> 8196<p> 8197Short seed vectors of 32-bit quantities all result in different states. However 8198this is not true of seed vectors of 16-bit (or smaller) quantities. For example 8199these two seeds 8200</p> 8201 8202<blockquote><pre>unsigned short seed = {1, 2, 3}; 8203unsigned short seed = {1, 2, 3, 0}; 8204</pre></blockquote> 8205 8206<p> 8207both pack to 8208</p> 8209 8210<blockquote><pre>unsigned seed = {0x20001, 0x3}; 8211</pre></blockquote> 8212 8213<p> 8214yielding the same state. 8215</p> 8216<p><b>Proposed resolution:</b></p> 8217<p> 8218In 26.4.7.1[rand.util.seedseq]/8a, replace 8219</p> 8220 8221<blockquote> 8222<p> 8223Set <tt>begin[0]</tt> to <tt>5489 + <del>s</del><ins>N</ins></tt>. 8224</p> 8225<p> 8226where <tt>N</tt> is the bit length of the sequence used to construct the 8227seed_seq in 26.4.7.1/6 [rand.util.seedseq]. (This quantity is called <tt>n</tt> 8228in 26.4.7.1/6 [rand.util.seedseq], but <tt>n</tt> has a different meaning in 822926.4.7.1/8 [rand.util.seedseq]. We have <tt>32^(s-1) < N <= 32^s</tt>.) Now 8230</p> 8231 8232<blockquote><pre>unsigned short seed = {1, 2, 3, 0}; 8233unsigned seed = {0x20001, 0x3}; 8234</pre></blockquote> 8235 8236<p> 8237are equivalent (<tt>N = 64</tt>), but 8238</p> 8239 8240<blockquote><pre>unsigned short seed = {1, 2, 3}; 8241</pre></blockquote> 8242 8243<p> 8244gives a distinct state (<tt>N = 48</tt>). 8245</p> 8246</blockquote> 8247 8248<hr> 8249<a name="608"><h3>608. Unclear seed_seq construction details</h3></a><p><b>Section:</b> 26.4.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.dist.iunif"> [lib.rand.dist.iunif]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Charles Karney <b>Date:</b> 26 Oct 2006</p> 8250<p> 8251In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the 8252treatment of signed quantities is unclear. Better to spell it out. 8253</p> 8254<p><b>Proposed resolution:</b></p> 8255<blockquote><pre>b = sum( unsigned(begin[i]) 2^(w i), 0 <= i < end-begin ) 8256</pre></blockquote> 8257 8258<p> 8259where <tt>w</tt> is the bit-width of the InputIterator. 8260</p> 8261<hr> 8262<a name="609"><h3>609. missing static const</h3></a><p><b>Section:</b> 26.4.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.eng.mers"> [lib.rand.eng.mers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Walter E. Brown <b>Date:</b> 2 Nov 2006</p> 8263<p> 8264In preparing N2111, an error on my part resulted in the omission of the 8265following line from the template synopsis in the cited section: 8266</p> 8267 8268<blockquote><pre>static const size_t word_size = w; 8269</pre></blockquote> 8270 8271<p> 8272(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].) 8273</p> 8274<p><b>Proposed resolution:</b></p> 8275<p> 8276Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4: 8277</p> 8278 8279<blockquote><pre>// engine characteristics 8280<ins>static const size_t word_size = w;</ins> 8281</pre></blockquote> 8282 8283<p> 8284and accept my apologies for the oversight. 8285</p> 8286<p>----- End of document -----</p> 8287</body></html>