libstdc++-v3/docs/html/ext/lwg-closed.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
   2 <html><head><title>C++ Standard Library Closed Issues List</title>
   3
   4 <style type="text/css">
   5 p {text-align:justify}
   6 li {text-align:justify}
   7 ins {background-color:#FFFFA0}
   8 del {background-color:#FFFFA0}
   9 </style></head>
  10
  11 <body>
  12 <table>
  13 <tbody><tr>
  14 <td align="left">Doc. no.</td>
  15 <td align="left">N2319=07-0179</td>
  16 </tr>
  17 <tr>
  18 <td align="left">Date:</td>
  19 <td align="left">2007-06-24</td>
  20 </tr>
  21 <tr>
  22 <td align="left">Project:</td>
  23 <td align="left">Programming Language C++</td>
  24 </tr>
  25 <tr>
  26 <td align="left">Reply to:</td>
  27 <td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
  28 </tr>
  29 </tbody></table>
  30 <h1>C++ Standard Library Closed Issues List (Revision R49)</h1>
  31
  32   <p>Reference ISO/IEC IS 14882:1998(E)</p>
  33   <p>Also see:</p>
  34     <ul>
  35       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
  36       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
  37       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
  38       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
  39       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
  40     </ul>
  41
  42   <p>This document contains only library issues which have been closed
  43   by the Library Working Group as duplicates or not defects. That is,
  44   issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> or
  45   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> active issues and more
  46   information. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered
  47   defects.  The introductory material in that document also applies to
  48   this document.</p>
  49
  50 <h2>Revision History</h2>
  51 <ul>
  52 <li>R49:
  53 2007-06-23 pre-Toronto mailing.
  54 <ul>
  55 <li><b>Summary:</b><ul>
  56 <li>158 open issues, up by 13.</li>
  57 <li>538 closed issues, up by 7.</li>
  58 <li>696 issues total, up by 20.</li>
  59 </ul></li>
  60 <li><b>Details:</b><ul>
  61 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
  62 <li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li>
  63 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li>
  64 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li>
  65 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>.</li>
  66 </ul></li>
  67 </ul>
  68 </li>
  69 <li>R48:
  70 2007-05-06 post-Oxford mailing.
  71 <ul>
  72 <li><b>Summary:</b><ul>
  73 <li>145 open issues, down by 33.</li>
  74 <li>531 closed issues, up by 53.</li>
  75 <li>676 issues total, up by 20.</li>
  76 </ul></li>
  77 <li><b>Details:</b><ul>
  78 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
  79 <li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
  80 <li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
  81 <li>Changed the following issues from NAD to NAD Editorial: <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#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <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#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#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#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#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li>
  82 <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
  83 <li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <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#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <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-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <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-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
  84 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
  85 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
  86 <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li>
  87 <li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
  88 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#646">646</a>.</li>
  89 <li>Changed the following issues from Review to Ready: <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>.</li>
  90 <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li>
  91 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
  92 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
  93 </ul></li>
  94 </ul>
  95 </li>
  96 <li>R47:
  97 2007-03-09 pre-Oxford mailing.
  98 <ul>
  99 <li><b>Summary:</b><ul>
 100 <li>178 open issues, up by 37.</li>
 101 <li>478 closed issues, up by 0.</li>
 102 <li>656 issues total, up by 37.</li>
 103 </ul></li>
 104 <li><b>Details:</b><ul>
 105 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
 106 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</a>.</li>
 107 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
 108 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
 109 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
 110 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li>
 111 </ul></li>
 112 </ul>
 113 </li>
 114 <li>R46:
 115 2007-01-12 mid-term mailing.
 116 <ul>
 117 <li><b>Summary:</b><ul>
 118 <li>141 open issues, up by 11.</li>
 119 <li>478 closed issues, down by 1.</li>
 120 <li>619 issues total, up by 10.</li>
 121 </ul></li>
 122 <li><b>Details:</b><ul>
 123 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
 124 </ul></li>
 125 </ul>
 126 </li>
 127 <li>R45:
 128 2006-11-03 post-Portland mailing.
 129 <ul>
 130 <li><b>Summary:</b><ul>
 131 <li>130 open issues, up by 0.</li>
 132 <li>479 closed issues, up by 17.</li>
 133 <li>609 issues total, up by 17.</li>
 134 </ul></li>
 135 <li><b>Details:</b><ul>
 136 <li>Moved 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.</li>
 137 <li>Moved 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.</li>
 138 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
 139 <li>Moved 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-defects.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-defects.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.</li>
 140 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li>
 141 <li>Moved 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.</li>
 142 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
 143 </ul></li>
 144 </ul>
 145 </li>
 146 <li>R44:
 147 2006-09-08 pre-Portland mailing.
 148 <ul>
 149 <li><b>Summary:</b><ul>
 150 <li>130 open issues, up by 6.</li>
 151 <li>462 closed issues, down by 1.</li>
 152 <li>592 issues total, up by 5.</li>
 153 </ul></li>
 154 <li><b>Details:</b><ul>
 155 <li>Added 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>.</li>
 156 </ul></li>
 157 </ul>
 158 </li>
 159 <li>R43:
 160 2006-06-23 mid-term mailing.
 161 <ul>
 162 <li><b>Summary:</b><ul>
 163 <li>124 open issues, up by 14.</li>
 164 <li>463 closed issues, down by 1.</li>
 165 <li>587 issues total, up by 13.</li>
 166 </ul></li>
 167 <li><b>Details:</b><ul>
 168 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
 169 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
 170 <li>Moved 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.</li>
 171 </ul></li>
 172 </ul>
 173 </li>
 174 <li>R42:
 175 2006-04-21 post-Berlin mailing.
 176 <ul>
 177 <li><b>Summary:</b><ul>
 178 <li>110 open issues, down by 16.</li>
 179 <li>464 closed issues, up by 24.</li>
 180 <li>574 issues total, up by 8.</li>
 181 </ul></li>
 182 <li><b>Details:</b><ul>
 183 <li>Added 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-closed.html#572">572</a>.</li>
 184 <li>Moved 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.</li>
 185 <li>Moved 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-closed.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-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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.</li>
 186 <li>Moved 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.</li>
 187 <li>Moved 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.</li>
 188 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
 189 </ul></li>
 190 </ul>
 191 </li>
 192 <li>R41:
 193 2006-02-24 pre-Berlin mailing.
 194 <ul>
 195 <li><b>Summary:</b><ul>
 196 <li>126 open issues, up by 31.</li>
 197 <li>440 closed issues, up by 0.</li>
 198 <li>566 issues total, up by 31.</li>
 199 </ul></li>
 200 <li><b>Details:</b><ul>
 201 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#566">566</a>.</li>
 202 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
 203 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
 204 </ul></li>
 205 </ul>
 206 </li>
 207 <li>R40:
 208 2005-12-16 mid-term mailing.
 209 <ul>
 210 <li><b>Summary:</b><ul>
 211 <li>95 open issues.</li>
 212 <li>440 closed issues.</li>
 213 <li>535 issues total.</li>
 214 </ul></li>
 215 <li><b>Details:</b><ul>
 216 <li>Added 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>.</li>
 217 </ul></li>
 218 </ul>
 219 </li>
 220 <li>R39:
 221 2005-10-14 post-Mont Tremblant mailing.
 222 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
 223 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
 224 Moved 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.
 225 Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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.
 226 Moved 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.
 227 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 228 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
 229 </li>
 230 <li>R38:
 231 2005-07-03 pre-Mont Tremblant mailing.
 232 Merged 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>.
 233 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
 234 </li>
 235 <li>R37:
 236 2005-06 mid-term mailing.
 237 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>.
 238 </li>
 239 <li>R36:
 240 2005-04 post-Lillehammer mailing. All issues in "ready" status except
 241 for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
 242 previously in "DR" status were moved to "WP".
 243 </li>
 244 <li>R35:
 245 2005-03 pre-Lillehammer mailing.
 246 </li>
 247 <li>R34:
 248 2005-01 mid-term mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
 249 </li>
 250 <li>R33:
 251 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
 252 </li>
 253 <li>R32:
 254 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
 255 new issues received after the 2004-07 mailing.  Added
 256 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
 257 </li>
 258 <li>R31:
 259 2004-07 mid-term mailing: reflects new proposed resolutions and
 260 new issues received after the post-Sydney mailing.  Added
 261 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
 262 </li>
 263 <li>R30:
 264 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 265 Voted all "Ready" issues from R29 into the working paper.
 266 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>.
 267 </li>
 268 <li>R29:
 269 Pre-Sydney mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
 270 </li>
 271 <li>R28:
 272 Post-Kona mailing: reflects decisions made at the Kona meeting.
 273 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
 274 </li>
 275 <li>R27:
 276 Pre-Kona mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
 277 </li>
 278 <li>R26:
 279 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 280 All issues in Ready status were voted into DR status.  All issues in
 281 DR status were voted into WP status.
 282 </li>
 283 <li>R25:
 284 Pre-Oxford mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
 285 </li>
 286 <li>R24:
 287 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 288 meeting.  All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
 289 moved to DR status.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>.  (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
 290 at the meeting.)  Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
 291 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 292 </li>
 293 <li>R23:
 294 Pre-Santa Cruz mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>.
 295 Moved issues in the TC to TC status.
 296 </li>
 297 <li>R22:
 298 Post-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>.
 299 </li>
 300 <li>R21:
 301 Pre-Curaçao mailing.  Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
 302 </li>
 303 <li>R20:
 304 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 305 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues
 306 <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
 307 not discussed at the meeting.
 308
 309 All Ready issues were moved to DR status, with the exception of issues
 310 <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>.
 311
 312 Noteworthy issues discussed at Redmond include
 313 <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-defects.html#233">233</a>,
 314 <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-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
 315 </li>
 316 <li>R19:
 317 Pre-Redmond mailing.  Added new issues
 318 <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>.
 319 </li>
 320 <li>R18:
 321 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 322 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
 323 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
 324
 325 Changed status of issues
 326 <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>
 327 <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>
 328 <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>
 329 <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>
 330 <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>
 331 <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>
 332 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 333 to DR.
 334
 335 Changed status of issues
 336 <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>
 337 <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>
 338 <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>
 339 <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>
 340 <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>
 341 <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>
 342 <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>
 343 <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>
 344 <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>
 345 to Ready.
 346
 347 Closed issues
 348 <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>
 349 <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>
 350 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 351 as NAD.
 352
 353 </li>
 354 <li>R17:
 355 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 356 resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
 357 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
 358 </li>
 359 <li>R16:
 360 post-Toronto mailing; reflects actions taken in Toronto. Added new
 361 issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>.  Changed status of issues
 362 <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>,
 363 <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>,
 364 <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>,
 365 <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>,
 366 <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>,
 367 <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>,
 368 <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>,
 369 <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>,
 370 <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>,
 371 <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>,
 372 <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>,
 373 <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>,
 374 <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
 375 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
 376 <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
 377 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
 378 appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
 379 the bug in enough places.
 380 </li>
 381 <li>R15:
 382 pre-Toronto mailing. Added issues
 383 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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
 384 changes so that we pass Weblint tests.
 385 </li>
 386 <li>R14:
 387 post-Tokyo II mailing; reflects committee actions taken in
 388 Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
 389 </li>
 390 <li>R13:
 391 pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
 392 </li>
 393 <li>R12:
 394 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 395 <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
 396 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 397 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 398 </li>
 399 <li>R11:
 400 post-Kona mailing: Updated to reflect LWG and full committee actions
 401 in Kona (99-0048/N1224). Note changed resolution of issues
 402 <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>
 403 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
 404 "closed" documents.  Changed the proposed resolution of issue
 405 <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
 406 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 407 </li>
 408 <li>R10:
 409 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 410 <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>,
 411 <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
 412 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 413 </li>
 414 <li>R9:
 415 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 416 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 417 "closed" documents. (99-0030/N1206, 25 Aug 99)
 418 </li>
 419 <li>R8:
 420 post-Dublin mailing. Updated to reflect LWG and full committee actions
 421 in Dublin. (99-0016/N1193, 21 Apr 99)
 422 </li>
 423 <li>R7:
 424 pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
 425 <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>,
 426 <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>,
 427 <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)
 428 </li>
 429 <li>R6:
 430 pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
 431 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 432 </li>
 433 <li>R5:
 434 update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
 435 <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
 436 for making list public. (30 Dec 98)
 437 </li>
 438 <li>R4:
 439 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 440 <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
 441 issues corrected. (22 Oct 98)
 442 </li>
 443 <li>R3:
 444 post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
 445 added, many issues updated to reflect LWG consensus (12 Oct 98)
 446 </li>
 447 <li>R2:
 448 pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
 449 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 450 </li>
 451 <li>R1:
 452 Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
 453 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 454 </li>
 455 </ul>
 456
 457 <h2>Closed Issues</h2>
 458 <hr>
 459 <h3><a name="2"></a>2. Auto_ptr conversions effects incorrect</h3>
 460 <p><b>Section:</b> D.9.1.3 [auto.ptr.conv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 461  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1997-12-04</p>
 462 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 463 <p><b>Discussion:</b></p>
 464 <p>Paragraph 1 in "Effects", says "Calls
 465 p-&gt;release()" where it clearly must be "Calls
 466 p.release()". (As it is, it seems to require using
 467 auto_ptr&lt;&gt;::operator-&gt; to refer to X::release, assuming that
 468 exists.)</p>
 469
 470
 471 <p><b>Proposed resolution:</b></p>
 472 <p>Change 20.4.4.3 [meta.unary.prop] paragraph 1 Effects from
 473 "Calls p-&gt;release()" to "Calls p.release()".</p>
 474
 475
 476 <p><b>Rationale:</b></p>
 477 <p>Not a defect: the proposed change is already found in the standard.
 478 [Originally classified as a defect, later reclassified.]</p>
 479
 480
 481
 482
 483
 484 <hr>
 485 <h3><a name="4"></a>4. Basic_string size_type and difference_type should be implementation defined</h3>
 486 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 487  <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</p>
 488 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
 489 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 490 <p><b>Discussion:</b></p>
 491 <p>In Morristown we changed the size_type and difference_type typedefs
 492 for all the other containers to implementation defined with a
 493 reference to 23.1 [container.requirements].  This should probably also have been
 494 done for strings. </p>
 495
 496
 497 <p><b>Rationale:</b></p>
 498 <p>Not a defect.  [Originally classified as a defect, later
 499 reclassified.]  basic_string, unlike the other standard library
 500 template containers, is severely constrained by its use of
 501 char_traits. Those types are dictated by the traits class, and are far
 502 from implementation defined.</p>
 503
 504
 505
 506
 507
 508 <hr>
 509 <h3><a name="6"></a>6. File position not an offset unimplementable</h3>
 510 <p><b>Section:</b> 27.4.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 511  <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</p>
 512 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
 513 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 514 <p><b>Discussion:</b></p>
 515 <p>Table 88, in I/O, is too strict; it's unimplementable on systems
 516 where a file position isn't just an offset. It also never says just
 517 what fpos&lt;&gt; is really supposed to be.  [Here's my summary, which
 518 Jerry agrees is more or less accurate. "I think I now know what
 519 the class really is, at this point: it's a magic cookie that
 520 encapsulates an mbstate_t and a file position (possibly represented as
 521 an fpos_t), it has syntactic support for pointer-like arithmetic, and
 522 implementors are required to have real, not just syntactic, support
 523 for arithmetic." This isn't standardese, of course.] </p>
 524
 525
 526 <p><b>Rationale:</b></p>
 527 <p>Not a defect. The LWG believes that the Standard is already clear,
 528 and that the above summary is what the Standard in effect says.</p>
 529
 530
 531
 532
 533
 534 <hr>
 535 <h3><a name="10"></a>10. Codecvt&lt;&gt;::do unclear</h3>
 536 <p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
 537  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-14</p>
 538 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
 539 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 540 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a></p>
 541 <p><b>Discussion:</b></p>
 542 <p>Section 22.2.1.5.2 says that codecvt&lt;&gt;::do_in and do_out
 543 should return the value noconv if "no conversion was
 544 needed". However, I don't see anything anywhere that defines what
 545 it means for a conversion to be needed or not needed. I can think of
 546 several circumstances where one might plausibly think that a
 547 conversion is not "needed", but I don't know which one is
 548 intended here. </p>
 549
 550
 551 <p><b>Rationale:</b></p>
 552
 553
 554
 555
 556
 557
 558 <hr>
 559 <h3><a name="12"></a>12. Way objects hold allocators unclear</h3>
 560 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 561  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-02-23</p>
 562 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
 563 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
 564 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 565 <p><b>Discussion:</b></p>
 566 <p>I couldn't find a statement in the standard saying whether the allocator object held by
 567 a container is held as a copy of the constructor argument or whether a pointer of
 568 reference is maintained internal. There is an according statement for compare objects and
 569 how they are maintained by the associative containers, but I couldn't find anything
 570 regarding allocators. </p>
 571
 572 <p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left
 573 unspecified? </p>
 574
 575
 576 <p><b>Rationale:</b></p>
 577 <p>Not a defect. The LWG believes that the Standard is already
 578 clear.&nbsp; See 23.1 [container.requirements], paragraph 8.</p>
 579
 580
 581
 582
 583
 584 <hr>
 585 <h3><a name="43"></a>43. Locale table correction</h3>
 586 <p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
 587  <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p>
 588 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
 589 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 590 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a></p>
 591 <p><b>Discussion:</b></p>
 592
 593
 594 <p><b>Rationale:</b></p>
 595
 596
 597
 598
 599
 600
 601 <hr>
 602 <h3><a name="45"></a>45. Stringstreams read/write pointers initial position unclear</h3>
 603 <p><b>Section:</b> 27.7.3 [ostringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 604  <b>Submitter:</b> Matthias Mueller <b>Date:</b> 1998-05-27</p>
 605 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 606 <p><b>Discussion:</b></p>
 607 <p>In a comp.lang.c++.moderated Matthias Mueller wrote:</p>
 608
 609 <p>"We are not sure how to interpret the CD2 (see 27.2
 610 [iostream.forward], 27.7.3.1 [ostringstream.cons], 27.7.1.1
 611 [stringbuf.cons])
 612 with respect to the question as to what the correct initial positions
 613 of the write and&nbsp; read pointers of a stringstream should
 614 be."</p>
 615
 616 <p>"Is it the same to output two strings or to initialize the stringstream with the
 617 first and to output the second?"</p>
 618
 619 <p><i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and
 620 Jerry Schwarz have all offered opinions; see reflector messages
 621 lib-6518, 6519, 6520, 6521, 6523, 6524.]</i></p>
 622
 623
 624
 625
 626 <p><b>Rationale:</b></p>
 627 <p>The LWG believes the Standard is correct as written. The behavior
 628 of stringstreams is consistent with fstreams, and there is a
 629 constructor which can be used to obtain the desired effect. This
 630 behavior is known to be different from strstreams.</p>
 631
 632
 633
 634
 635
 636 <hr>
 637 <h3><a name="58"></a>58. Extracting a char from a wide-oriented stream</h3>
 638 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 639  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p>
 640 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
 641 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 642 <p><b>Discussion:</b></p>
 643 <p>27.6.1.2.3 has member functions for extraction of signed char and
 644 unsigned char, both singly and as strings. However, it doesn't say
 645 what it means to extract a <tt>char</tt> from a
 646 <tt>basic_streambuf&lt;charT, Traits&gt;</tt>. </p>
 647
 648 <p>basic_streambuf, after all, has no members to extract a char, so
 649 basic_istream must somehow convert from charT to signed char or
 650 unsigned char. The standard doesn't say how it is to perform that
 651 conversion. </p>
 652
 653
 654 <p><b>Rationale:</b></p>
 655 <p>The Standard is correct as written.  There is no such extractor and
 656 this is the intent of the LWG.</p>
 657
 658
 659
 660
 661 <hr>
 662 <h3><a name="65"></a>65. Underspecification of strstreambuf::seekoff</h3>
 663 <p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 664  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p>
 665 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
 666 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 667 <p><b>Discussion:</b></p>
 668 <p>The standard says how this member function affects the current
 669 stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not
 670 say how this member function affects the beginning and end of the
 671 get/put area. </p>
 672
 673 <p>This is an issue when seekoff is used to position the get pointer
 674 beyond the end of the current read area. (Which is legal. This is
 675 implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.)
 676 </p>
 677
 678
 679 <p><b>Rationale:</b></p>
 680 <p>The LWG agrees that seekoff() is underspecified, but does not wish
 681 to invest effort in this deprecated feature.</p>
 682
 683
 684
 685
 686
 687 <hr>
 688 <h3><a name="67"></a>67. Setw useless for strings</h3>
 689 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
 690  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-07-09</p>
 691 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
 692 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 693 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a></p>
 694 <p><b>Discussion:</b></p>
 695 <p>In a comp.std.c++ posting Michel Michaud wrote: What
 696 should be output by: </p>
 697
 698 <pre>   string text("Hello");
 699    cout &lt;&lt; '[' &lt;&lt; setw(10) &lt;&lt; right &lt;&lt; text &lt;&lt; ']';
 700 </pre>
 701
 702 <p>Shouldn't it be:</p>
 703
 704 <pre>   [     Hello]</pre>
 705
 706 <p>Another person replied: Actually, according to the FDIS, the width
 707 of the field should be the minimum of width and the length of the
 708 string, so the output shouldn't have any padding. I think that this is
 709 a typo, however, and that what is wanted is the maximum of the
 710 two. (As written, setw is useless for strings. If that had been the
 711 intent, one wouldn't expect them to have mentioned using its value.)
 712 </p>
 713
 714 <p>It's worth pointing out that this is a recent correction anyway;
 715 IIRC, earlier versions of the draft forgot to mention formatting
 716 parameters whatsoever.</p>
 717
 718
 719 <p><b>Rationale:</b></p>
 720
 721
 722
 723
 724
 725
 726 <hr>
 727 <h3><a name="72"></a>72. Do_convert phantom member function</h3>
 728 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
 729  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-24</p>
 730 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
 731 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 732 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a></p>
 733 <p><b>Discussion:</b></p>
 734 <p>In 22.2.1.4 [locale.codecvt] par 3, and in 22.2.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function
 735 "do_convert" is mentioned. This member was replaced with
 736 "do_in" and "do_out", the proper referents in the
 737 contexts above.</p>
 738
 739
 740 <p><b>Rationale:</b></p>
 741
 742
 743
 744
 745
 746 <hr>
 747 <h3><a name="73"></a>73. <tt>is_open</tt> should be const</h3>
 748 <p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 749  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-27</p>
 750 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
 751 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 752 <p><b>Discussion:</b></p>
 753 <p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and
 754 <tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It
 755 should be a <tt>const</tt> member function, since it does nothing but
 756 call one of <tt>basic_filebuf</tt>'s const member functions. </p>
 757
 758
 759 <p><b>Rationale:</b></p>
 760 <p>Not a defect. This is a deliberate feature; const streams would be
 761 meaningless.</p>
 762
 763
 764
 765
 766 <hr>
 767 <h3><a name="77"></a>77. Valarray operator[] const returning value</h3>
 768 <p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
 769  <b>Submitter:</b> Levente Farkas <b>Date:</b> 1998-09-09</p>
 770 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
 771 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
 772 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a></p>
 773 <p><b>Discussion:</b></p>
 774 <p>valarray:<br>
 775 <br>
 776 &nbsp;&nbsp;&nbsp; <tt>T operator[] (size_t) const;</tt><br>
 777 <br>
 778 why not <br>
 779 <br>
 780 &nbsp;&nbsp;&nbsp; <tt>const T&amp; operator[] (size_t) const;</tt><br>
 781 <br>
 782 as in vector ???<br>
 783 <br>
 784 One can't copy even from a const valarray eg:<br>
 785 <br>
 786 &nbsp;&nbsp;&nbsp; <tt>memcpy(ptr, &amp;v[0], v.size() * sizeof(double));<br>
 787 </tt><br>
 788 [I] find this bug in valarray is very difficult.</p>
 789
 790
 791 <p><b>Rationale:</b></p>
 792 <p>The LWG believes that the interface was deliberately designed that
 793 way. That is what valarray was designed to do; that's where the
 794 "value array" name comes from. LWG members further comment
 795 that "we don't want valarray to be a full STL container."
 796 26.5.2.3 [valarray.access] specifies properties that indicate "an
 797 absence of aliasing" for non-constant arrays; this allows
 798 optimizations, including special hardware optimizations, that are not
 799 otherwise possible. </p>
 800
 801
 802
 803
 804
 805 <hr>
 806 <h3><a name="81"></a>81. Wrong declaration of slice operations</h3>
 807 <p><b>Section:</b> 26.5.5 [template.slice.array], 26.5.7 [template.gslice.array], 26.5.8 [template.mask.array], 26.5.9 [template.indirect.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 808  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 809 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</p>
 810 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 811 <p><b>Discussion:</b></p>
 812 <p>Isn't the definition of copy constructor and assignment operators wrong?
 813 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Instead of</p>
 814
 815 <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array(const slice_array&amp;);
 816 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array&amp; operator=(const slice_array&amp;);</pre>
 817
 818 <p>IMHO they have to be</p>
 819
 820 <pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array(const slice_array&lt;T&gt;&amp;);
 821 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array&amp; operator=(const slice_array&lt;T&gt;&amp;);</pre>
 822
 823 <p>Same for gslice_array. </p>
 824
 825
 826 <p><b>Rationale:</b></p>
 827 <p>Not a defect. The Standard is correct as written. </p>
 828
 829
 830
 831
 832 <hr>
 833 <h3><a name="82"></a>82. Missing constant for set elements</h3>
 834 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 835  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 836 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
 837 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 838 <p><b>Discussion:</b></p>
 839 <p>Paragraph 5 specifies:</p>
 840
 841 <blockquote><p>
 842 For set and multiset the value type is the same as the key type. For
 843 map and multimap it is equal to pair&lt;const Key, T&gt;.
 844 </p></blockquote>
 845
 846 <p>Strictly speaking, this is not correct because for set and multiset
 847 the value type is the same as the <b>constant</b> key type.</p>
 848
 849
 850 <p><b>Rationale:</b></p>
 851 <p>Not a defect. The Standard is correct as written; it uses a
 852 different mechanism (const &amp;) for <tt>set</tt> and
 853 <tt>multiset</tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for a related
 854 issue.</p>
 855
 856
 857
 858
 859 <hr>
 860 <h3><a name="84"></a>84. Ambiguity with string::insert()</h3>
 861 <p><b>Section:</b> 21.3.5 [string.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 862  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 863 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 864 <p><b>Discussion:</b></p>
 865 <p>If I try</p>
 866 <pre>    s.insert(0,1,' ');</pre>
 867
 868 <p>&nbsp; I get an nasty ambiguity. It might be</p>
 869 <pre>    s.insert((size_type)0,(size_type)1,(charT)' ');</pre>
 870
 871 <p>which inserts 1 space character at position 0, or</p>
 872 <pre>    s.insert((char*)0,(size_type)1,(charT)' ')</pre>
 873
 874 <p>which inserts 1 space character at iterator/address 0 (bingo!), or</p>
 875 <pre>    s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre>
 876
 877 <p>which normally inserts characters from iterator 1 to iterator '
 878 '. But according to 23.1.1.9 (the "do the right thing" fix)
 879 it is equivalent to the second. However, it is still ambiguous,
 880 because of course I mean the first!</p>
 881
 882
 883 <p><b>Rationale:</b></p>
 884 <p>Not a defect. The LWG believes this is a "genetic
 885 misfortune" inherent in the design of string and thus not a
 886 defect in the Standard as such .</p>
 887
 888
 889
 890
 891 <hr>
 892 <h3><a name="85"></a>85. String char types</h3>
 893 <p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 894  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 895 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
 896 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 897 <p><b>Discussion:</b></p>
 898 <p>The standard seems not to require that charT is equivalent to
 899 traits::char_type. So, what happens if charT is not equivalent to
 900 traits::char_type?</p>
 901
 902
 903 <p><b>Rationale:</b></p>
 904 <p>There is already wording in 21.1 [char.traits] paragraph 3 that
 905 requires them to be the same.</p>
 906
 907
 908
 909
 910 <hr>
 911 <h3><a name="87"></a>87. Error in description of string::compare()</h3>
 912 <p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
 913  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 914 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
 915 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 916 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a></p>
 917 <p><b>Discussion:</b></p>
 918 <p>The following compare() description is obviously a bug:</p>
 919
 920 <pre>int compare(size_type pos, size_type n1,
 921             charT *s, size_type n2 = npos) const;
 922 </pre>
 923
 924 <p>because without passing n2 it should compare up to the end of the
 925 string instead of comparing npos characters (which throws an
 926 exception) </p>
 927
 928
 929 <p><b>Rationale:</b></p>
 930
 931
 932
 933
 934
 935 <hr>
 936 <h3><a name="88"></a>88. Inconsistency between string::insert() and string::append()</h3>
 937 <p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.2 [string::append] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 938  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 939 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
 940 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 941 <p><b>Discussion:</b></p>
 942 <p>Why does </p>
 943 <pre>  template&lt;class InputIterator&gt;
 944        basic_string&amp; append(InputIterator first, InputIterator last);</pre>
 945
 946 <p>return a string, while</p>
 947 <pre>  template&lt;class InputIterator&gt;
 948        void insert(iterator p, InputIterator first, InputIterator last);</pre>
 949
 950 <p>returns nothing ?</p>
 951
 952
 953 <p><b>Rationale:</b></p>
 954 <p>The LWG believes this stylistic inconsistency is not sufficiently
 955 serious to constitute a defect.</p>
 956
 957
 958
 959
 960 <hr>
 961 <h3><a name="89"></a>89. Missing throw specification for string::insert() and string::replace()</h3>
 962 <p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
 963  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 964 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
 965 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
 966 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a></p>
 967 <p><b>Discussion:</b></p>
 968 <p>All insert() and replace() members for strings with an iterator as
 969 first argument lack a throw specification. The throw
 970 specification should probably be: length_error if size exceeds
 971 maximum. </p>
 972
 973
 974 <p><b>Rationale:</b></p>
 975 <p>Considered a duplicate because it will be solved by the resolution
 976 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
 977
 978
 979
 980
 981
 982 <hr>
 983 <h3><a name="93"></a>93. Incomplete Valarray Subset Definitions</h3>
 984 <p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
 985  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
 986 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p>
 987 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
 988 <p><b>Discussion:</b></p>
 989 <p>You can easily create subsets, but you can't easily combine them
 990 with other subsets.  Unfortunately, you almost always needs an
 991 explicit type conversion to valarray. This is because the standard
 992 does not specify that valarray subsets provide the same operations as
 993 valarrays. </p>
 994
 995 <p>For example, to multiply two subsets and assign the result to a third subset, you can't
 996 write the following:</p>
 997
 998 <pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre>
 999
1000 <p>Instead, you have to code as follows:</p>
1001
1002 <pre>va[slice(0,4,3)] = static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(1,4,3)]) *
1003                    static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(2,4,3)]);</pre>
1004
1005 <p>This is tedious and error-prone. Even worse, it costs performance because each cast
1006 creates a temporary objects, which could be avoided without the cast. </p>
1007
1008
1009 <p><b>Proposed resolution:</b></p>
1010 <p>Extend all valarray subset types so that they offer all valarray operations.</p>
1011
1012
1013 <p><b>Rationale:</b></p>
1014 <p>This is not a defect in the Standard; it is a request for an extension.</p>
1015
1016
1017
1018
1019 <hr>
1020 <h3><a name="94"></a>94. May library implementors add template parameters to Standard Library classes?</h3>
1021 <p><b>Section:</b> 17.4.4 [conforming] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1022  <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p>
1023 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1024 <p><b>Discussion:</b></p>
1025 <p>Is it a permitted extension for library implementors to add template parameters to
1026 standard library classes, provided that those extra parameters have defaults? For example,
1027 instead of defining <tt>template &lt;class T, class Alloc = allocator&lt;T&gt; &gt; class
1028 vector;</tt> defining it as <tt>template &lt;class T, class Alloc = allocator&lt;T&gt;,
1029 int N = 1&gt; class vector;</tt> </p>
1030
1031 <p>The standard may well already allow this (I can't think of any way that this extension
1032 could break a conforming program, considering that users are not permitted to
1033 forward-declare standard library components), but it ought to be explicitly permitted or
1034 forbidden. </p>
1035
1036 <p>comment from Steve Cleary via comp.std.c++:</p>
1037 <blockquote>
1038 <p>I disagree [with the proposed resolution] for the following reason:
1039 consider user library code with template template parameters. For
1040 example, a user library object may be templated on the type of
1041 underlying sequence storage to use (deque/list/vector), since these
1042 classes all take the same number and type of template parameters; this
1043 would allow the user to determine the performance tradeoffs of the
1044 user library object. A similar example is a user library object
1045 templated on the type of underlying set storage (set/multiset) or map
1046 storage (map/multimap), which would allow users to change (within
1047 reason) the semantic meanings of operations on that object.</p>
1048 <p>I think that additional template parameters should be forbidden in
1049 the Standard classes. Library writers don't lose any expressive power,
1050 and can still offer extensions because additional template parameters
1051 may be provided by a non-Standard implementation class:</p>
1052 <pre>
1053    template &lt;class T, class Allocator = allocator&lt;T&gt;, int N = 1&gt;
1054    class __vector
1055    { ... };
1056    template &lt;class T, class Allocator = allocator&lt;T&gt; &gt;
1057    class vector: public __vector&lt;T, Allocator&gt;
1058    { ... };
1059 </pre>
1060
1061 </blockquote>
1062
1063
1064
1065 <p><b>Proposed resolution:</b></p>
1066 <p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.8 [res.on.exception.handling]:</p>
1067
1068 <blockquote>
1069   <p>17.4.4.9 Template Parameters</p> <p>A specialization of a
1070   template class described in the C++ Standard Library behaves the
1071   same as if the implementation declares no additional template
1072   parameters.</p> <p>Footnote: Additional template parameters with
1073   default values are thus permitted.</p>
1074 </blockquote>
1075
1076 <p>Add "template parameters" to the list of subclauses at
1077 the end of 17.4.4 [conforming] paragraph 1.</p>
1078
1079 <p><i>[Kona: The LWG agreed the standard needs clarification. After
1080 discussion with John Spicer, it seems added template parameters can be
1081 detected by a program using template-template parameters. A straw vote
1082 - "should implementors be allowed to add template
1083 parameters?" found no consensus ; 5 - yes, 7 - no.]</i></p>
1084
1085
1086
1087
1088 <p><b>Rationale:</b></p>
1089 <p>
1090 There is no ambiguity; the standard is clear as written.  Library
1091 implementors are not permitted to add template parameters to standard
1092 library classes.  This does not fall under the "as if" rule,
1093 so it would be permitted only if the standard gave explicit license
1094 for implementors to do this.  This would require a change in the
1095 standard.
1096 </p>
1097
1098 <p>
1099 The LWG decided against making this change, because it would break
1100 user code involving template template parameters or specializations
1101 of standard library class templates.
1102 </p>
1103
1104
1105
1106
1107
1108 <hr>
1109 <h3><a name="95"></a>95. Members added by the implementation</h3>
1110 <p><b>Section:</b> 17.4.4.4 [member.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1111  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1112 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1113 <p><b>Discussion:</b></p>
1114 <p>In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual
1115 members a base class and break user derived classes.</p>
1116
1117 <p>Example: </p>
1118
1119 <blockquote>
1120   <pre>// implementation code:
1121 struct _Base { // _Base is in the implementer namespace
1122         virtual void foo ();
1123 };
1124 class vector : _Base // deriving from a class is allowed
1125 { ... };
1126
1127 // user code:
1128 class vector_checking : public vector
1129 {
1130         void foo (); // don't want to override _Base::foo () as the
1131                      // user doesn't know about _Base::foo ()
1132 };</pre>
1133 </blockquote>
1134
1135
1136 <p><b>Proposed resolution:</b></p>
1137 <p>Clarify the wording to make the example illegal.</p>
1138
1139
1140 <p><b>Rationale:</b></p>
1141 <p>This is not a defect in the Standard.&nbsp; The example is already
1142 illegal.&nbsp; See 17.4.4.4 [member.functions] paragraph 2.</p>
1143
1144
1145
1146
1147 <hr>
1148 <h3><a name="97"></a>97. Insert inconsistent definition</h3>
1149 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1150  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1151 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
1152 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1153 <p><b>Discussion:</b></p>
1154 <p><tt>insert(iterator, const value_type&amp;)</tt> is defined both on
1155 sequences and on set, with unrelated semantics: insert here (in
1156 sequences), and insert with hint (in associative containers). They
1157 should have different names (B.S. says: do not abuse overloading).</p>
1158
1159
1160 <p><b>Rationale:</b></p>
1161 <p>This is not a defect in the Standard. It is a genetic misfortune of
1162 the design, for better or for worse.</p>
1163
1164
1165
1166
1167 <hr>
1168 <h3><a name="99"></a>99. Reverse_iterator comparisons completely wrong</h3>
1169 <p><b>Section:</b> 24.4.1.3.13 [reverse.iter.op==] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1170  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1171 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1172 <p><b>Discussion:</b></p>
1173 <p>The &lt;, &gt;, &lt;=, &gt;= comparison operator are wrong: they
1174 return the opposite of what they should.</p>
1175
1176 <p>Note: same problem in CD2, these were not even defined in CD1.  SGI
1177 STL code is correct; this problem is known since the Morristown
1178 meeting but there it was too late</p>
1179
1180
1181 <p><b>Rationale:</b></p>
1182 <p>This is not a defect in the Standard. A careful reading shows the Standard is correct
1183 as written. A review of several implementations show that they implement
1184 exactly what the Standard says.</p>
1185
1186
1187
1188
1189 <hr>
1190 <h3><a name="100"></a>100. Insert iterators/ostream_iterators overconstrained</h3>
1191 <p><b>Section:</b> 24.4.2 [insert.iterators], 24.5.4 [ostreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1192  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1194 <p><b>Discussion:</b></p>
1195 <p>Overspecified For an insert iterator it, the expression *it is
1196 required to return a reference to it. This is a simple possible
1197 implementation, but as the SGI STL documentation says, not the only
1198 one, and the user should not assume that this is the case.</p>
1199
1200
1201 <p><b>Rationale:</b></p>
1202 <p>The LWG believes this causes no harm and is not a defect in the
1203 standard. The only example anyone could come up with caused some
1204 incorrect code to work, rather than the other way around.</p>
1205
1206
1207
1208
1209
1210 <hr>
1211 <h3><a name="101"></a>101. No way to free storage for vector and deque</h3>
1212 <p><b>Section:</b> 23.2.5 [vector], 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1213  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1214 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
1215 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1216 <p><b>Discussion:</b></p>
1217 <p>Reserve can not free storage, unlike string::reserve</p>
1218
1219
1220 <p><b>Rationale:</b></p>
1221 <p>This is not a defect in the Standard. The LWG has considered this
1222 issue in the past and sees no need to change the Standard. Deque has
1223 no reserve() member function. For vector, shrink-to-fit can be
1224 expressed in a single line of code (where <tt>v</tt> is
1225 <tt>vector&lt;T&gt;</tt>):
1226 </p>
1227
1228 <blockquote>
1229   <p><tt>vector&lt;T&gt;(v).swap(v);&nbsp; // shrink-to-fit v</tt></p>
1230 </blockquote>
1231
1232
1233
1234
1235
1236 <hr>
1237 <h3><a name="102"></a>102. Bug in insert range in associative containers</h3>
1238 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1239  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1240 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
1241 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1242 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a></p>
1243 <p><b>Discussion:</b></p>
1244 <p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems
1245 impossible to implement, as it means that if [i, j) = [x], insert in an associative
1246 container is O(1)!</p>
1247
1248
1249 <p><b>Proposed resolution:</b></p>
1250 <p>N+log (size()) if [i,j) is sorted according to value_comp()</p>
1251
1252
1253 <p><b>Rationale:</b></p>
1254 <p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>.</p>
1255
1256
1257
1258
1259
1260 <hr>
1261 <h3><a name="104"></a>104. Description of basic_string::operator[] is unclear</h3>
1262 <p><b>Section:</b> 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1263  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1264 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.capacity">issues</a> in [string.capacity].</p>
1265 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1266 <p><b>Discussion:</b></p>
1267 <p>It is not clear that undefined behavior applies when pos == size ()
1268 for the non const version.</p>
1269
1270
1271 <p><b>Proposed resolution:</b></p>
1272 <p>Rewrite as: Otherwise, if pos &gt; size () or pos == size () and
1273 the non-const version is used, then the behavior is undefined.</p>
1274
1275
1276 <p><b>Rationale:</b></p>
1277 <p>The Standard is correct. The proposed resolution already appears in
1278 the Standard.</p>
1279
1280
1281
1282
1283 <hr>
1284 <h3><a name="105"></a>105. fstream ctors argument types desired</h3>
1285 <p><b>Section:</b> 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
1286  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1287 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1288 <p><b>Discussion:</b></p>
1289 <p>fstream ctors take a const char* instead of string.<br>
1290 fstream ctors can't take wchar_t</p>
1291
1292 <p>An extension to add a const wchar_t* to fstream would make the
1293 implementation non conforming.</p>
1294
1295
1296 <p><b>Rationale:</b></p>
1297 <p>This is not a defect in the Standard. It might be an
1298 interesting extension for the next Standard. </p>
1299
1300
1301
1302
1303 <hr>
1304 <h3><a name="107"></a>107. Valarray constructor is strange</h3>
1305 <p><b>Section:</b> 26.5.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1306  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1307 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.valarray">issues</a> in [template.valarray].</p>
1308 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1309 <p><b>Discussion:</b></p>
1310 <p>The order of the arguments is (elem, size) instead of the normal
1311 (size, elem) in the rest of the library. Since elem often has an
1312 integral or floating point type, both types are convertible to each
1313 other and reversing them leads to a well formed program.</p>
1314
1315
1316 <p><b>Proposed resolution:</b></p>
1317 <p>Inverting the arguments could silently break programs. Introduce
1318 the two signatures (const T&amp;, size_t) and (size_t, const T&amp;),
1319 but make the one we do not want private so errors result in a
1320 diagnosed access violation. This technique can also be applied to STL
1321 containers.</p>
1322
1323
1324 <p><b>Rationale:</b></p>
1325 <p>The LWG believes that while the order of arguments is unfortunate,
1326 it does not constitute a defect in the standard. The LWG believes that
1327 the proposed solution will not work for valarray&lt;size_t&gt; and
1328 perhaps other cases.</p>
1329
1330
1331
1332
1333 <hr>
1334 <h3><a name="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3>
1335 <p><b>Section:</b> 24.5.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
1336  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-10-15</p>
1337 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1338 <p><b>Discussion:</b></p>
1339 <p>The member istreambuf_iterator&lt;&gt;::equal is specified to be
1340 unnecessarily inefficient. While this does not affect the efficiency
1341 of conforming implementations of iostreams, because they can
1342 "reach into" the iterators and bypass this function, it does
1343 affect users who use istreambuf_iterators. </p>
1344
1345 <p>The inefficiency results from a too-scrupulous definition, which
1346 requires a "true" result if neither iterator is at eof. In
1347 practice these iterators can only usefully be compared with the
1348 "eof" value, so the extra test implied provides no benefit,
1349 but slows down users' code. </p>
1350
1351 <p>The solution is to weaken the requirement on the function to return
1352 true only if both iterators are at eof. </p>
1353
1354
1355 <p><b>Proposed resolution:</b></p>
1356 <p>Replace 24.5.3.5 [istreambuf.iterator::equal],
1357 paragraph 1, </p>
1358
1359 <blockquote>
1360   <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at
1361   end-of-stream, regardless of what streambuf object they use. </p>
1362 </blockquote>
1363
1364 <p>with</p>
1365
1366 <blockquote>
1367   <p>-1- Returns: true if and only if both iterators are at
1368   end-of-stream, regardless of what streambuf object they use. </p>
1369 </blockquote>
1370
1371
1372
1373 <p><b>Rationale:</b></p>
1374 <p>It is not clear that this is a genuine defect.  Additionally, the
1375 LWG was reluctant to make a change that would result in
1376 operator== not being a equivalence relation.  One consequence of
1377 this change is that an algorithm that's passed the range [i, i)
1378 would no longer treat it as an empty range.</p>
1379
1380
1381
1382
1383
1384 <hr>
1385 <h3><a name="113"></a>113. Missing/extra iostream sync semantics</h3>
1386 <p><b>Section:</b> 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1387  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-13</p>
1388 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</p>
1389 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1390 <p><b>Discussion:</b></p>
1391 <p>In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3,
1392 paragraph 36. </p>
1393
1394 <p>Following the chain of definitions, I find that the various sync functions have defined
1395 semantics for output streams, but no semantics for input streams. On the other hand,
1396 basic_ostream has no sync function. </p>
1397
1398 <p>The sync function should at minimum be added to basic_ostream, for internal
1399 consistency. </p>
1400
1401 <p>A larger question is whether sync should have assigned semantics for input streams. </p>
1402
1403 <p>Classic iostreams said streambuf::sync flushes pending output and attempts to return
1404 unread input characters to the source. It is a protected member function. The filebuf
1405 version (which is public) has that behavior (it backs up the read pointer). Class
1406 strstreambuf does not override streambuf::sync, and so sync can't be called on a
1407 strstream. </p>
1408
1409 <p>If we can add corresponding semantics to the various sync functions, we should. If not,
1410 we should remove sync from basic_istream.</p>
1411
1412
1413 <p><b>Rationale:</b></p>
1414 <p>A sync function is not needed in basic_ostream because the flush function provides the
1415 desired functionality.</p>
1416
1417 <p>As for the other points, the LWG finds the standard correct as written.</p>
1418
1419
1420
1421
1422
1423 <hr>
1424 <h3><a name="116"></a>116. bitset cannot be constructed with a const char*</h3>
1425 <p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
1426  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-11-06</p>
1427 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
1428 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
1429 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1430 <p><b>Discussion:</b></p>
1431 <p>The following code does not compile with the EDG compiler:</p>
1432
1433 <blockquote>
1434   <pre>#include &lt;bitset&gt;
1435 using namespace std;
1436 bitset&lt;32&gt; b("111111111");</pre>
1437 </blockquote>
1438
1439 <p>If you cast the ctor argument to a string, i.e.:</p>
1440
1441 <blockquote>
1442   <pre>bitset&lt;32&gt; b(string("111111111"));</pre>
1443 </blockquote>
1444
1445 <p>then it will compile. The reason is that bitset has the following templatized
1446 constructor:</p>
1447
1448 <blockquote>
1449   <pre>template &lt;class charT, class traits, class Allocator&gt;
1450 explicit bitset (const basic_string&lt;charT, traits, Allocator&gt;&amp; str, ...);</pre>
1451 </blockquote>
1452
1453 <p>According to the compiler vendor, Steve Adamcyk at EDG, the user
1454 cannot pass this template constructor a <tt>const char*</tt> and
1455 expect a conversion to <tt>basic_string</tt>.  The reason is
1456 "When you have a template constructor, it can get used in
1457 contexts where type deduction can be done. Type deduction basically
1458 comes up with exact matches, not ones involving conversions."
1459 </p>
1460
1461 <p>I don't think the intention when this constructor became
1462 templatized was for construction from a <tt>const char*</tt> to no
1463 longer work.</p>
1464
1465
1466 <p><b>Proposed resolution:</b></p>
1467 <p>Add to 23.3.5 [template.bitset] a bitset constructor declaration</p>
1468
1469 <blockquote>
1470   <pre>explicit bitset(const char*);</pre>
1471 </blockquote>
1472
1473 <p>and in Section 23.3.5.1 [bitset.cons] add:</p>
1474
1475 <blockquote>
1476   <pre>explicit bitset(const char* str);</pre>
1477   <p>Effects: <br>
1478   &nbsp;&nbsp;&nbsp; Calls <tt>bitset((string) str, 0, string::npos);</tt></p>
1479 </blockquote>
1480
1481
1482 <p><b>Rationale:</b></p>
1483 <p>Although the problem is real, the standard is designed that way so
1484 it is not a defect.  Education is the immediate workaround. A future
1485 standard may wish to consider the Proposed Resolution as an
1486 extension.</p>
1487
1488
1489
1490
1491
1492 <hr>
1493 <h3><a name="121"></a>121. Detailed definition for ctype&lt;wchar_t&gt; specialization</h3>
1494 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1495  <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
1496 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
1497 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1498 <p><b>Discussion:</b></p>
1499 <p>Section 22.1.1.1.1 has the following listed in Table 51: ctype&lt;char&gt; ,
1500 ctype&lt;wchar_t&gt;. </p>
1501
1502 <p>Also Section 22.2.1.1 [locale.ctype] says: </p>
1503
1504 <blockquote>
1505   <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype&lt;char&gt; and
1506   ctype&lt;wchar_t&gt; , implement character classing appropriate to the implementation's
1507   native character set. </p>
1508 </blockquote>
1509
1510 <p>However, Section 22.2.1.3 [facet.ctype.special]
1511 only has a detailed description of the ctype&lt;char&gt; specialization, not the
1512 ctype&lt;wchar_t&gt; specialization. </p>
1513
1514
1515 <p><b>Proposed resolution:</b></p>
1516 <p>Add the ctype&lt;wchar_t&gt; detailed class description to Section
1517 22.2.1.3 [facet.ctype.special]. </p>
1518
1519
1520 <p><b>Rationale:</b></p>
1521 <p>Specialization for wchar_t is not needed since the default is acceptable.</p>
1522
1523
1524
1525
1526
1527 <hr>
1528 <h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string&nbsp; buffers</h3>
1529 <p><b>Section:</b> 27.7 [string.streams], 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
1530  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
1531 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
1532 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1533 <p><b>Discussion:</b></p>
1534 <p>The following question came from Thorsten Herlemann:</p>
1535
1536 <blockquote>
1537   <p>You can set a mode when constructing or opening a file-stream or
1538   filebuf, e.g.  ios::in, ios::out, ios::binary, ... But how can I get
1539   that mode later on, e.g. in my own operator &lt;&lt; or operator
1540   &gt;&gt; or when I want to check whether a file-stream or
1541   file-buffer object passed as parameter is opened for input or output
1542   or binary? Is there no possibility? Is this a design-error in the
1543   standard C++ library? </p>
1544 </blockquote>
1545
1546 <p>It is indeed impossible to find out what a stream's or stream
1547 buffer's open mode is, and without that knowledge you don't know
1548 how certain operations behave. Just think of the append mode. </p>
1549
1550 <p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
1551 current open mode setting. </p>
1552
1553
1554 <p><b>Proposed resolution:</b></p>
1555 <p>For stream buffers, add a function to the base class as a non-virtual function
1556 qualified as const to 27.5.2 [streambuf]:</p>
1557
1558 <p>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>
1559
1560 <p><b>&nbsp;&nbsp;&nbsp; Returns</b> the current open mode.</p>
1561
1562 <p>With streams, I'm not sure what to suggest. In principle, the mode
1563 could already be returned by <tt>ios_base</tt>, but the mode is only
1564 initialized for file and string stream objects, unless I'm overlooking
1565 anything. For this reason it should be added to the most derived
1566 stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
1567 and would be default initialized in <tt>basic_ios&lt;&gt;::init()</tt>.</p>
1568
1569
1570 <p><b>Rationale:</b></p>
1571 <p>This might be an interesting extension for some future, but it is
1572 not a defect in the current standard. The Proposed Resolution is
1573 retained for future reference.</p>
1574
1575
1576
1577
1578
1579 <hr>
1580 <h3><a name="131"></a>131. list::splice throws nothing</h3>
1581 <p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1582  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
1583 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
1584 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1585 <p><b>Discussion:</b></p>
1586 <p>What happens if a splice operation causes the size() of a list to grow
1587 beyond max_size()?</p>
1588
1589
1590 <p><b>Rationale:</b></p>
1591 <p>Size() cannot grow beyond max_size().&nbsp; </p>
1592
1593
1594
1595
1596
1597 <hr>
1598 <h3><a name="135"></a>135. basic_iostream doubly initialized</h3>
1599 <p><b>Section:</b> 27.6.1.5.1 [iostream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1600  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
1601 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1602 <p><b>Discussion:</b></p>
1603 <p>-1- Effects Constructs an object of class basic_iostream, assigning
1604 initial values to the base classes by calling
1605 basic_istream&lt;charT,traits&gt;(sb) (lib.istream) and
1606 basic_ostream&lt;charT,traits&gt;(sb) (lib.ostream)</p>
1607
1608 <p>The called for basic_istream and basic_ostream constructors call
1609 init(sb). This means that the basic_iostream's virtual base class is
1610 initialized twice.</p>
1611
1612
1613 <p><b>Proposed resolution:</b></p>
1614 <p>Change 27.6.1.5.1, paragraph 1 to:</p>
1615
1616 <p>-1- Effects Constructs an object of class basic_iostream, assigning
1617 initial values to the base classes by calling
1618 basic_istream&lt;charT,traits&gt;(sb) (lib.istream).</p>
1619
1620
1621 <p><b>Rationale:</b></p>
1622 <p>The LWG agreed that the <tt> init()</tt> function is called
1623 twice, but said that this is harmless and so not a defect in the
1624 standard.</p>
1625
1626
1627
1628
1629 <hr>
1630 <h3><a name="138"></a>138. Class ctype_byname&lt;char&gt; redundant and misleading</h3>
1631 <p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
1632  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-18</p>
1633 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
1634 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1635 <p><b>Discussion:</b></p>
1636 <p>Section 22.2.1.4 [locale.codecvt] specifies that
1637 ctype_byname&lt;char&gt; must be a specialization of the ctype_byname
1638 template.</p>
1639
1640 <p>It is common practice in the standard that specializations of class templates are only
1641 mentioned where the interface of the specialization deviates from the interface of the
1642 template that it is a specialization of. Otherwise, the fact whether or not a required
1643 instantiation is an actual instantiation or a specialization is left open as an
1644 implementation detail. </p>
1645
1646 <p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
1647 fact, that ctype_byname&lt;char&gt; is specified as a specialization suggests that there
1648 must be something "special" about it, but it has the exact same interface as the
1649 ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
1650 redundant, at worst misleading - unless I am missing anything. </p>
1651
1652 <p>Naturally, an implementation will most likely implement ctype_byname&lt;char&gt; as a
1653 specialization, because the base class ctype&lt;char&gt; is a specialization with an
1654 interface different from the ctype template, but that's an implementation detail and need
1655 not be mentioned in the standard. </p>
1656
1657
1658 <p><b>Rationale:</b></p>
1659 <p> The standard as written is mildly misleading, but the correct fix
1660 is to deal with the underlying problem in the ctype_byname base class,
1661 not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
1662
1663
1664
1665
1666 <hr>
1667 <h3><a name="140"></a>140. map&lt;Key, T&gt;::value_type does not satisfy the assignable requirement</h3>
1668 <p><b>Section:</b> 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
1669  <b>Submitter:</b> Mark Mitchell <b>Date:</b> 1999-04-14</p>
1670 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p>
1671 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1672 <p><b>Discussion:</b></p>
1673 <blockquote>
1674   <p>23.1 [container.requirements]<br>
1675   <br>
1676   expression&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return type
1677   &nbsp;&nbsp;&nbsp;&nbsp; pre/post-condition<br>
1678   -------------&nbsp;&nbsp;&nbsp;&nbsp; ----------- &nbsp;&nbsp;&nbsp;&nbsp;
1679   -------------------<br>
1680   X::value_type&nbsp;&nbsp;&nbsp; T
1681   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1682   T is assignable<br>
1683   <br>
1684   23.3.1 [map]<br>
1685   <br>
1686   A map satisfies all the requirements of a container.<br>
1687   <br>
1688   For a map&lt;Key, T&gt; ... the value_type is pair&lt;const Key, T&gt;.</p>
1689 </blockquote>
1690
1691 <p>There's a contradiction here. In particular, `pair&lt;const Key,
1692 T&gt;' is not assignable; the `const Key' cannot be assigned
1693 to. So,&nbsp; map&lt;Key, T&gt;::value_type does not satisfy the
1694 assignable requirement imposed by a container.</p>
1695
1696 <p><i>[See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for the slightly related issue of
1697 modification of set keys.]</i></p>
1698
1699
1700
1701 <p><b>Rationale:</b></p>
1702 <p>The LWG believes that the standard is inconsistent, but that this
1703 is a design problem rather than a strict defect. May wish to
1704 reconsider for the next standard.</p>
1705
1706
1707
1708
1709 <hr>
1710 <h3><a name="143"></a>143. C .h header wording unclear</h3>
1711 <p><b>Section:</b> D.5 [depr.c.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1712  <b>Submitter:</b> Christophe de Dinechin <b>Date:</b> 1999-05-04</p>
1713 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1714 <p><b>Discussion:</b></p>
1715 <p>[depr.c.headers] paragraph 2 reads:</p>
1716
1717 <blockquote>
1718
1719 <p>Each C header, whose name has the form name.h, behaves as if each
1720 name placed in the Standard library namespace by the corresponding
1721 cname header is also placed within the namespace scope of the
1722 namespace std and is followed by an explicit using-declaration
1723 (_namespace.udecl_)</p>
1724
1725 </blockquote>
1726
1727 <p>I think it should mention the global name space somewhere...&nbsp;
1728 Currently, it indicates that name placed in std is also placed in
1729 std...</p>
1730
1731 <p>I don't know what is the correct wording. For instance, if struct
1732 tm is defined in time.h, ctime declares std::tm. However, the current
1733 wording seems ambiguous regarding which of the following would occur
1734 for use of both ctime and time.h:</p>
1735
1736 <blockquote>
1737   <pre>// version 1:
1738 namespace std {
1739         struct tm { ... };
1740 }
1741 using std::tm;
1742
1743 // version 2:
1744 struct tm { ... };
1745 namespace std {
1746         using ::tm;
1747 }
1748
1749 // version 3:
1750 struct tm { ... };
1751 namespace std {
1752         struct tm { ... };
1753 }</pre>
1754 </blockquote>
1755
1756 <p>I think version 1 is intended.</p>
1757
1758 <p><i>[Kona: The LWG agreed that the wording is not clear. It also
1759 agreed that version 1 is intended, version 2 is not equivalent to
1760 version 1, and version 3 is clearly not intended. The example below
1761 was constructed by Nathan Myers to illustrate why version 2 is not
1762 equivalent to version 1.</i></p>
1763
1764 <p><i>Although not equivalent, the LWG is unsure if (2) is enough of
1765 a problem to be prohibited. Points discussed in favor of allowing
1766 (2):</i></p>
1767
1768 <blockquote>
1769   <ul>
1770     <li><i>It may be a convenience to implementors.</i></li>
1771     <li><i>The only cases that fail are structs, of which the C library
1772       contains only a few.</i></li>
1773   </ul>
1774 </blockquote>
1775
1776 <p><i>]</i></p>
1777
1778 <p><b>Example:</b></p>
1779
1780 <blockquote>
1781
1782 <pre>#include &lt;time.h&gt;
1783 #include &lt;utility&gt;
1784
1785 int main() {
1786     std::tm * t;
1787     make_pair( t, t ); // okay with version 1 due to Koenig lookup
1788                        // fails with version 2; make_pair not found
1789     return 0;
1790 }</pre>
1791
1792 </blockquote>
1793
1794
1795 <p><b>Proposed resolution:</b></p>
1796
1797 <p>Replace D.5 [depr.c.headers] paragraph 2 with:</p>
1798
1799 <blockquote>
1800
1801 <p> Each C header, whose name has the form name.h, behaves as if each
1802 name placed in the Standard library namespace by the corresponding
1803 cname header is also placed within the namespace scope of the
1804 namespace std by name.h and is followed by an explicit
1805 using-declaration (_namespace.udecl_) in global scope.</p>
1806
1807 </blockquote>
1808
1809
1810
1811 <p><b>Rationale:</b></p>
1812 <p> The current wording in the standard is the result of a difficult
1813 compromise that averted delay of the standard. Based on discussions
1814 in Tokyo it is clear that there is no still no consensus on stricter
1815 wording, so the issue has been closed. It is suggested that users not
1816 write code that depends on Koenig lookup of C library functions.</p>
1817
1818
1819
1820
1821 <hr>
1822 <h3><a name="145"></a>145. adjustfield lacks default value</h3>
1823 <p><b>Section:</b> 27.4.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1824  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p>
1825 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
1826 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1827 <p><b>Discussion:</b></p>
1828 <p>There is no initial value for the adjustfield defined, although
1829 many people believe that the default adjustment were right. This is a
1830 common misunderstanding. The standard only defines that, if no
1831 adjustment is specified, all the predefined inserters must add fill
1832 characters before the actual value, which is "as if" the
1833 right flag were set. The flag itself need not be set.</p>
1834
1835 <p>When you implement a user-defined inserter you cannot rely on right
1836 being the default setting for the adjustfield. Instead, you must be
1837 prepared to find none of the flags set and must keep in mind that in
1838 this case you should make your inserter behave "as if" the
1839 right flag were set. This is surprising to many people and complicates
1840 matters more than necessary.</p>
1841
1842 <p>Unless there is a good reason why the adjustfield should not be
1843 initialized I would suggest to give it the default value that
1844 everybody expects anyway.</p>
1845
1846
1847
1848 <p><b>Rationale:</b></p>
1849 <p>This is not a defect. It is deliberate that the default is no bits
1850 set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</p>
1851
1852
1853
1854
1855 <hr>
1856 <h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
1857 <p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
1858  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-06-28</p>
1859 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
1860 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
1861 <p><b>Discussion:</b></p>
1862 <p>Suppose that c and c1 are sequential containers and i is an
1863 iterator that refers to an element of c.  Then I can insert a copy of
1864 c1's elements into c ahead of element i by executing </p>
1865
1866 <blockquote>
1867
1868 <pre>c.insert(i, c1.begin(), c1.end());</pre>
1869
1870 </blockquote>
1871
1872 <p>If c is a vector, it is fairly easy for me to find out where the
1873 newly inserted elements are, even though i is now invalid: </p>
1874
1875 <blockquote>
1876
1877 <pre>size_t i_loc = i - c.begin();
1878 c.insert(i, c1.begin(), c1.end());</pre>
1879
1880 </blockquote>
1881
1882 <p>and now the first inserted element is at c.begin()+i_loc and one
1883 past the last is at c.begin()+i_loc+c1.size().<br>
1884 <br>
1885 But what if c is a list? I can still find the location of one past the
1886 last inserted element, because i is still valid. To find the location
1887 of the first inserted element, though, I must execute something like </p>
1888
1889 <blockquote>
1890
1891 <pre>for (size_t n = c1.size(); n; --n)
1892    --i;</pre>
1893
1894 </blockquote>
1895
1896 <p>because i is now no longer a random-access iterator.<br>
1897 <br>
1898 Alternatively, I might write something like </p>
1899
1900 <blockquote>
1901
1902 <pre>bool first = i == c.begin();
1903 list&lt;T&gt;::iterator j = i;
1904 if (!first) --j;
1905 c.insert(i, c1.begin(), c1.end());
1906 if (first)
1907    j = c.begin();
1908 else
1909    ++j;</pre>
1910
1911 </blockquote>
1912
1913 <p>which, although wretched, requires less overhead.<br>
1914 <br>
1915 But I think the right solution is to change the definition of insert
1916 so that instead of returning void, it returns an iterator that refers
1917 to the first element inserted, if any, and otherwise is a copy of its
1918 first argument.&nbsp; </p>
1919
1920
1921 <p><b>Rationale:</b></p>
1922 <p>The LWG believes this was an intentional design decision and so is
1923 not a defect. It may be worth revisiting for the next standard.</p>
1924
1925
1926
1927
1928 <hr>
1929 <h3><a name="157"></a>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt></h3>
1930 <p><b>Section:</b> 27.4.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1931  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
1932 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</p>
1933 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1934 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a></p>
1935 <p><b>Discussion:</b></p>
1936 <p>According to paragraphs 2 and 4 of 27.4.2.5 [ios.base.storage], the
1937 functions <tt>iword()</tt> and <tt>pword()</tt> "set the
1938 <tt>badbit</tt> (which might throw an exception)" on
1939 failure. ... but what does it mean for <tt>ios_base</tt> to set the
1940 <tt>badbit</tt>? The state facilities of the IOStream library are
1941 defined in <tt>basic_ios</tt>, a derived class! It would be possible
1942 to attempt a down cast but then it would be necessary to know the
1943 character type used...</p>
1944
1945
1946 <p><b>Rationale:</b></p>
1947
1948
1949
1950
1951
1952 <hr>
1953 <h3><a name="162"></a>162. Really "formatted input functions"?</h3>
1954 <p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1955  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
1956 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
1957 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1958 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
1959 <p><b>Discussion:</b></p>
1960 <p>It appears to be somewhat nonsensical to consider the functions
1961 defined in the paragraphs 1 to 5 to be "Formatted input
1962 function" but since these functions are defined in a section
1963 labeled "Formatted input functions" it is unclear to me
1964 whether these operators are considered formatted input functions which
1965 have to conform to the "common requirements" from 27.6.1.2.1
1966 [istream.formatted.reqmts]: If this is the case, all manipulators, not
1967 just
1968 <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set
1969 (... but setting <tt>noskipws</tt> using the manipulator syntax would
1970 also skip whitespace :-)</p>
1971
1972 <p>See also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a> for the same problem in formatted
1973 output</p>
1974
1975
1976 <p><b>Rationale:</b></p>
1977
1978
1979
1980
1981
1982 <hr>
1983 <h3><a name="163"></a>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt></h3>
1984 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1985  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
1986 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
1987 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
1988 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1989 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
1990 <p><b>Discussion:</b></p>
1991 <p>It is not clear which functions are to be considered unformatted
1992 input functions. As written, it seems that all functions in 27.6.1.3
1993 [istream.unformatted] are unformatted input functions. However, it does
1994 not
1995 really make much sense to construct a sentry object for
1996 <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what
1997 happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>,
1998 <tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called:
1999 These functions don't extract characters, some of them even
2000 "unextract" a character. Should this still be reflected in
2001 <tt>gcount()</tt>? Of course, it could be read as if after a call to
2002 <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last
2003 unformatted input function, <tt>gcount()</tt>, didn't extract any
2004 character) and after a call to <tt>putback()</tt> <tt>gcount()</tt>
2005 returns <tt>-1</tt> (the last unformatted input function
2006 <tt>putback()</tt> did "extract" back into the
2007 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2008 intended?  If so, this should be clarified. Otherwise, a corresponding
2009 clarification should be used.</p>
2010
2011
2012 <p><b>Rationale:</b></p>
2013
2014
2015
2016
2017
2018 <hr>
2019 <h3><a name="166"></a>166. Really "formatted output functions"?</h3>
2020 <p><b>Section:</b> 27.6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2021  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
2022 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2023 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2024 <p><b>Discussion:</b></p>
2025 <p>From 27.6.2.6.1 [ostream.formatted.reqmts] it appears that all the functions
2026 defined in 27.6.2.6.3 [ostream.inserters] have to construct a
2027 <tt>sentry</tt> object. Is this really intended?</p>
2028
2029 <p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but
2030 for output instead of input.</p>
2031
2032
2033 <p><b>Rationale:</b></p>
2034
2035
2036
2037
2038
2039 <hr>
2040 <h3><a name="177"></a>177. Complex operators cannot be explicitly instantiated</h3>
2041 <p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2042  <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</p>
2043 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p>
2044 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2045 <p><b>Discussion:</b></p>
2046 <p>A user who tries to explicitly instantiate a complex non-member operator will
2047 get compilation errors. Below is a simplified example of the reason why. The
2048 problem is that iterator_traits cannot be instantiated on a non-pointer type
2049 like float, yet when the compiler is trying to decide which operator+ needs to
2050 be instantiated it must instantiate the declaration to figure out the first
2051 argument type of a reverse_iterator operator.</p>
2052 <pre>namespace std {
2053 template &lt;class Iterator&gt;
2054 struct iterator_traits
2055 {
2056     typedef typename Iterator::value_type value_type;
2057 };
2058
2059 template &lt;class T&gt; class reverse_iterator;
2060
2061 // reverse_iterator operator+
2062 template &lt;class T&gt;
2063 reverse_iterator&lt;T&gt; operator+
2064 (typename iterator_traits&lt;T&gt;::difference_type, const reverse_iterator&lt;T&gt;&amp;);
2065
2066 template &lt;class T&gt; struct complex {};
2067
2068 // complex operator +
2069 template &lt;class T&gt;
2070 complex&lt;T&gt; operator+ (const T&amp; lhs, const complex&lt;T&gt;&amp; rhs)
2071 { return complex&lt;T&gt;();}
2072 }
2073
2074 // request for explicit instantiation
2075 template std::complex&lt;float&gt; std::operator+&lt;float&gt;(const float&amp;,
2076      const std::complex&lt;float&gt;&amp;);</pre>
2077 <p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p>
2078
2079
2080 <p><b>Rationale:</b></p>
2081 <p>Implementors can make minor changes and the example will
2082 work. Users are not affected in any case.</p> <p>According to John
2083 Spicer, It is possible to explicitly instantiate these operators using
2084 different syntax: change "std::operator+&lt;float&gt;" to
2085 "std::operator+".</p>
2086
2087 <p>The proposed resolution of issue 120 is that users will not be able
2088 to explicitly instantiate standard library templates. If that
2089 resolution is accepted then library implementors will be the only ones
2090 that will be affected by this problem, and they must use the indicated
2091 syntax.</p>
2092
2093
2094
2095
2096 <hr>
2097 <h3><a name="178"></a>178. Should clog and cerr initially be tied to cout?</h3>
2098 <p><b>Section:</b> 27.3.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2099  <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</p>
2100 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</p>
2101 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2102 <p><b>Discussion:</b></p>
2103 <p>
2104 Section 27.3.1 says "After the object cerr is initialized,
2105 cerr.flags() &amp; unitbuf is nonzero. Its state is otherwise the same as
2106 required for ios_base::init (lib.basic.ios.cons).  It doesn't say
2107 anything about the the state of clog.  So this means that calling
2108 cerr.tie() and clog.tie() should return 0 (see Table 89 for
2109 ios_base::init effects).
2110 </p>
2111 <p>
2112 Neither of the popular standard library implementations
2113 that I tried does this, they both tie cerr and clog
2114 to &amp;cout. I would think that would be what users expect.
2115 </p>
2116
2117
2118 <p><b>Rationale:</b></p>
2119 <p>The standard is clear as written.</p>
2120 <p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags()
2121 &amp; unitbuf is nonzero. Its state is otherwise the same as required for
2122 ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the
2123 postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct
2124 ios_base::init to basic_ios::init().)</p>
2125
2126
2127
2128
2129 <hr>
2130 <h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
2131 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
2132  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p>
2133 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
2134 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
2135 <p><b>Discussion:</b></p>
2136 <p>It is the constness of the container which should control whether
2137 it can be modified through a member function such as erase(), not the
2138 constness of the iterators. The iterators only serve to give
2139 positioning information.</p>
2140
2141 <p>Here's a simple and typical example problem which is currently very
2142 difficult or impossible to solve without the change proposed
2143 below.</p>
2144
2145 <p>Wrap a standard container C in a class W which allows clients to
2146 find and read (but not modify) a subrange of (C.begin(), C.end()]. The
2147 only modification clients are allowed to make to elements in this
2148 subrange is to erase them from C through the use of a member function
2149 of W.</p>
2150
2151
2152 <p><b>Proposed resolution:</b></p>
2153 <p>Change all non-const iterator parameters of standard library
2154 container member functions to accept const_iterator parameters.
2155 Note that this change applies to all library clauses, including
2156 strings.</p>
2157
2158 <p>For example, in   21.3.5.5  change:<br>
2159 <br>
2160 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>iterator erase(iterator p);</tt><br>
2161 <br>
2162 to:<br>
2163 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>iterator erase(const_iterator p);</tt>
2164 </p>
2165
2166
2167 <p><b>Rationale:</b></p>
2168 <p>The issue was discussed at length. It was generally agreed that 1)
2169 There is no major technical argument against the change (although
2170 there is a minor argument that some obscure programs may break), and
2171 2) Such a change would not break const correctness. The concerns about
2172 making the change were 1) it is user detectable (although only in
2173 boundary cases), 2) it changes a large number of signatures, and 3) it
2174 seems more of a design issue that an out-and-out defect.</p>
2175
2176 <p>The LWG believes that this issue should be considered as part of a
2177 general review of const issues for the next revision of the
2178 standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
2179
2180
2181
2182
2183 <hr>
2184 <h3><a name="188"></a>188. valarray helpers missing augmented assignment operators</h3>
2185 <p><b>Section:</b> 26.5.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
2186  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-08-15</p>
2187 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
2188 <p><b>Discussion:</b></p>
2189 <p>26.5.2.6 defines augmented assignment operators
2190 valarray&lt;T&gt;::op=(const T&amp;), but fails to provide
2191 corresponding versions for the helper classes. Thus making the
2192 following illegal:</p>
2193 <blockquote>
2194 <pre>#include &lt;valarray&gt;
2195
2196 int main()
2197 {
2198 std::valarray&lt;double&gt; v(3.14, 1999);
2199
2200 v[99] *= 2.0; // Ok
2201
2202 std::slice s(0, 50, 2);
2203
2204 v[s] *= 2.0; // ERROR
2205 }</pre>
2206 </blockquote>
2207 <p>I can't understand the intent of that omission.  It makes the
2208 valarray library less intuitive and less useful.</p>
2209
2210
2211 <p><b>Rationale:</b></p>
2212 <p>Although perhaps an unfortunate
2213 design decision, the omission is not a defect in the current
2214 standard.&nbsp; A future standard may wish to add the missing
2215 operators.</p>
2216
2217
2218
2219
2220 <hr>
2221 <h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
2222 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
2223  <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p>
2224 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
2225 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
2226 <p><b>Discussion:</b></p>
2227 <p>Both std::min and std::max are defined as template functions.  This
2228 is very different than the definition of std::plus (and similar
2229 structs) which are defined as function objects which inherit
2230 std::binary_function.<br>
2231 <br>
2232         This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
2233 a function object that inherits std::binary_function.</p>
2234
2235
2236 <p><b>Rationale:</b></p>
2237 <p>Although perhaps an unfortunate design decision, the omission is not a defect
2238 in the current standard.&nbsp; A future standard may wish to consider additional
2239 function objects.</p>
2240
2241
2242
2243
2244 <hr>
2245 <h3><a name="191"></a>191. Unclear complexity for algorithms such as binary search</h3>
2246 <p><b>Section:</b> 25.3.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2247  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1999-10-10</p>
2248 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</p>
2249 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2250 <p><b>Discussion:</b></p>
2251 <p>The complexity of binary_search() is stated as "At most
2252 log(last-first) + 2 comparisons", which seems to say that the
2253 algorithm has logarithmic complexity. However, this algorithms is
2254 defined for forward iterators. And for forward iterators, the need to
2255 step element-by-element results into linear complexity. But such a
2256 statement is missing in the standard. The same applies to
2257 lower_bound(), upper_bound(), and equal_range().&nbsp;<br>
2258 <br>
2259 However, strictly speaking the standard contains no bug here. So this
2260 might considered to be a clarification or improvement.
2261 </p>
2262
2263
2264 <p><b>Rationale:</b></p>
2265 <p>The complexity is expressed in terms of comparisons, and that
2266 complexity can be met even if the number of iterators accessed is
2267 linear. Paragraph 1 already says exactly what happens to
2268 iterators.</p>
2269
2270
2271
2272
2273 <hr>
2274 <h3><a name="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3>
2275 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2276  <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-06</p>
2277 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
2278 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2279 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
2280 <p><b>Discussion:</b></p>
2281 <p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from
2282 several problems:</p>
2283 <table border="1" cellpadding="5">
2284   <tbody><tr>
2285     <td><b>expression</b></td>
2286     <td><b>return type</b></td>
2287     <td><b>pre/post-condition</b></td>
2288     <td><b>complexity</b></td>
2289   </tr>
2290   <tr>
2291     <td><tt>a.insert(p,t)</tt></td>
2292     <td><tt>iterator</tt></td>
2293     <td>inserts t if and only if there is no element with key equivalent to the key of
2294        t in containers with unique keys; always inserts t in containers with equivalent
2295        keys. always returns the iterator pointing to the element with key equivalent to
2296        the key of t . iterator p is a hint pointing to where the insert should start to search.</td>
2297     <td>logarithmic in general, but amortized constant if t is inserted right after p .</td>
2298   </tr>
2299 </tbody></table>
2300 <p>1. For a container with unique keys, only logarithmic complexity is
2301 guaranteed if no element is inserted, even though constant complexity is always
2302 possible if p points to an element equivalent to t.</p>
2303 <p>2. For a container with equivalent keys, the amortized constant complexity
2304 guarantee is only useful if no key equivalent to t exists in the container.
2305 Otherwise, the insertion could occur in one of multiple locations, at least one
2306 of which would not be right after p.</p>
2307 <p>3. By guaranteeing amortized constant complexity only when t is inserted
2308 after p, it is impossible to guarantee constant complexity if t is inserted at
2309 the beginning of the container. Such a problem would not exist if amortized
2310 constant complexity was guaranteed if t is inserted before p, since there is
2311 always some p immediately before which an insert can take place.</p>
2312 <p>4. For a container with equivalent keys, p does not allow specification of
2313 where to insert the element, but rather only acts as a hint for improving
2314 performance. This negates the added functionality that p would provide if it
2315 specified where within a sequence of equivalent keys the insertion should occur.
2316 Specifying the insert location provides more control to the user, while
2317 providing no disadvantage to the container implementation.</p>
2318
2319
2320 <p><b>Proposed resolution:</b></p>
2321 <p>In 23.1.2 [associative.reqmts] paragraph 7, replace the row in table 69
2322 for a.insert(p,t) with the following two rows:</p>
2323 <table border="1" cellpadding="5">
2324   <tbody><tr>
2325     <td><b>expression</b></td>
2326     <td><b>return type</b></td>
2327     <td><b>pre/post-condition</b></td>
2328     <td><b>complexity</b></td>
2329   </tr>
2330   <tr>
2331     <td><tt>a_uniq.insert(p,t)</tt></td>
2332     <td><tt>iterator</tt></td>
2333     <td>inserts t if and only if there is no element with key equivalent to the
2334       key of t. returns the iterator pointing to the element with key equivalent
2335       to the key of t.</td>
2336     <td>logarithmic in general, but amortized constant if t is inserted right
2337       before p or p points to an element with key equivalent to t.</td>
2338   </tr>
2339   <tr>
2340     <td><tt>a_eq.insert(p,t)</tt></td>
2341     <td><tt>iterator</tt></td>
2342     <td>inserts t and returns the iterator pointing to the newly inserted
2343       element. t is inserted right before p if doing so preserves the container
2344       ordering.</td>
2345     <td>logarithmic in general, but amortized constant if t is inserted right
2346       before p.</td>
2347   </tr>
2348 </tbody></table>
2349
2350
2351
2352 <p><b>Rationale:</b></p>
2353 <p>Too big a change.&nbsp; Furthermore, implementors report checking
2354 both before p and after p, and don't want to change this behavior.</p>
2355
2356
2357
2358
2359
2360 <hr>
2361 <h3><a name="194"></a>194. rdbuf() functions poorly specified</h3>
2362 <p><b>Section:</b> 27.4.4 [ios] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2363  <b>Submitter:</b> Steve Clamage <b>Date:</b> 1999-09-07</p>
2364 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2365 <p><b>Discussion:</b></p>
2366 <p>In classic iostreams, base class ios had an rdbuf function that returned a
2367 pointer to the associated streambuf. Each derived class had its own rdbuf
2368 function that returned a pointer of a type reflecting the actual type derived
2369 from streambuf. Because in ARM C++, virtual function overrides had to have the
2370 same return type, rdbuf could not be virtual.</p>
2371 <p>In standard iostreams, we retain the non-virtual rdbuf function design, and
2372 in addition have an overloaded rdbuf function that sets the buffer pointer.
2373 There is no need for the second function to be virtual nor to be implemented in
2374 derived classes.</p>
2375 <p>Minor question: Was there a specific reason not to make the original rdbuf
2376 function virtual?</p>
2377 <p>Major problem: Friendly compilers warn about functions in derived classes
2378 that hide base-class overloads. Any standard implementation of iostreams will
2379 result in such a warning on each of the iostream classes, because of the
2380 ill-considered decision to overload rdbuf only in a base class.</p>
2381 <p>In addition, users of the second rdbuf function must use explicit
2382 qualification or a cast to call it from derived classes. An explicit
2383 qualification or cast to basic_ios would prevent access to any later overriding
2384 version if there was one.</p>
2385 <p>What I'd like to do in an implementation is add a using- declaration for the
2386 second rdbuf function in each derived class. It would eliminate warnings about
2387 hiding functions, and would enable access without using explicit qualification.
2388 Such a change I don't think would change the behavior of any valid program, but
2389 would allow invalid programs to compile:</p>
2390 <blockquote>
2391   <pre> filebuf mybuf;
2392  fstream f;
2393  f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre>
2394 </blockquote>
2395 <p>I'd like to suggest this problem as a defect, with the proposed resolution to
2396 require the equivalent of a using-declaration for the rdbuf function that is not
2397 replaced in a later derived class. We could discuss whether replacing the
2398 function should be allowed.</p>
2399
2400
2401 <p><b>Rationale:</b></p>
2402 <p>For historical reasons, the standard is correct as written. There is a subtle difference between the base
2403 class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived
2404 class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class
2405 <tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p>
2406
2407 <p>Permission is not required to add such an extension.  See
2408 17.4.4.4 [member.functions].</p>
2409
2410
2411
2412
2413 <hr>
2414 <h3><a name="196"></a>196. Placement new example has alignment problems</h3>
2415 <p><b>Section:</b> 18.5.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2416  <b>Submitter:</b> Herb Sutter <b>Date:</b> 1998-12-15</p>
2417 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p>
2418 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2419 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a></p>
2420 <p><b>Discussion:</b></p>
2421 <p>The example in 18.5.1.3 [new.delete.placement] paragraph 4 reads: </p>
2422
2423 <blockquote>
2424
2425 <p>[Example: This can be useful for constructing an object at a known address:<br>
2426 <br>
2427 <tt>&nbsp;&nbsp; char place[sizeof(Something)];<br>
2428 &nbsp;&nbsp; Something* p = new (place) Something();<br>
2429 <br>
2430 </tt>end example] </p>
2431
2432 </blockquote>
2433
2434 <p>This example has potential alignment problems. </p>
2435
2436
2437 <p><b>Rationale:</b></p>
2438
2439
2440
2441
2442
2443 <hr>
2444 <h3><a name="197"></a>197. max_size() underspecified</h3>
2445 <p><b>Section:</b> 20.1.2 [allocator.requirements], 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2446  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-10-21</p>
2447 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
2448 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
2449 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2450 <p><b>Discussion:</b></p>
2451 <p>Must the value returned by max_size() be unchanged from call to call? </p>
2452
2453 <p>Must the value returned from max_size() be meaningful? </p>
2454
2455 <p>Possible meanings identified in lib-6827: </p>
2456
2457 <p>1) The largest container the implementation can support given "best
2458 case" conditions - i.e. assume the run-time platform is "configured to
2459 the max", and no overhead from the program itself. This may possibly
2460 be determined at the point the library is written, but certainly no
2461 later than compile time.<br>
2462 <br>
2463 2) The largest container the program could create, given "best case"
2464 conditions - i.e. same platform assumptions as (1), but take into
2465 account any overhead for executing the program itself. (or, roughly
2466 "storage=storage-sizeof(program)"). This does NOT include any resource
2467 allocated by the program. This may (or may not) be determinable at
2468 compile time.<br>
2469 <br>
2470 3) The largest container the current execution of the program could
2471 create, given knowledge of the actual run-time platform, but again,
2472 not taking into account any currently allocated resource. This is
2473 probably best determined at program start-up.<br>
2474 <br>
2475 4) The largest container the current execution program could create at
2476 the point max_size() is called (or more correctly at the point
2477 max_size() returns :-), given it's current environment (i.e. taking
2478 into account the actual currently available resources). This,
2479 obviously, has to be determined dynamically each time max_size() is
2480 called. </p>
2481
2482
2483 <p><b>Proposed resolution:</b></p>
2484
2485
2486 <p><b>Rationale:</b></p>
2487 <p>max_size() isn't useful for very many things, and the existing
2488   wording is sufficiently clear for the few cases that max_size() can
2489   be used for.  None of the attempts to change the existing wording
2490   were an improvement.</p>
2491
2492 <p>It is clear to the LWG that the value returned by max_size() can't
2493   change from call to call.</p>
2494
2495
2496
2497
2498
2499
2500 <hr>
2501 <h3><a name="203"></a>203. basic_istream::sentry::sentry() is uninstantiable with ctype&lt;user-defined type&gt;</h3>
2502 <p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2503  <b>Submitter:</b> Matt McClure and Dietmar Kühl <b>Date:</b> 2000-01-01</p>
2504 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
2505 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2506 <p><b>Discussion:</b></p>
2507 <p>27.6.1.1.2 Paragraph 4 states:</p>
2508 <blockquote>
2509   <p>To decide if the character c is a whitespace character, the constructor
2510      performs ''as if'' it executes the following code fragment:&nbsp;</p>
2511   <pre>const ctype&lt;charT&gt;&amp; ctype = use_facet&lt;ctype&lt;charT&gt; &gt;(is.getloc());
2512 if (ctype.is(ctype.space,c)!=0)
2513 // c is a whitespace character.</pre>
2514 </blockquote>
2515
2516 <p> But Table 51 in 22.1.1.1.1 only requires an implementation to
2517 provide specializations for ctype&lt;char&gt; and
2518 ctype&lt;wchar_t&gt;.  If sentry's constructor is implemented using
2519 ctype, it will be uninstantiable for a user-defined character type
2520 charT, unless the implementation has provided non-working (since it
2521 would be impossible to define a correct ctype&lt;charT&gt; specialization
2522 for an arbitrary charT) definitions of ctype's virtual member
2523 functions.</p>
2524
2525 <p>
2526 It seems the intent the standard is that sentry should behave, in
2527 every respect, not just during execution, as if it were implemented
2528 using ctype, with the burden of providing a ctype specialization
2529 falling on the user.  But as it is written, nothing requires the
2530 translation of sentry's constructor to behave as if it used the above
2531 code, and it would seem therefore, that sentry's constructor should be
2532 instantiable for all character types.
2533 </p>
2534
2535 <p>
2536 Note: If I have misinterpreted the intent of the standard with
2537 respect to sentry's constructor's instantiability, then a note should
2538 be added to the following effect:
2539 </p>
2540
2541 <blockquote><p>
2542 An implementation is forbidden from using the above code if it renders
2543 the constructor uninstantiable for an otherwise valid character
2544 type.
2545 </p></blockquote>
2546
2547 <p>In any event, some clarification is needed.</p>
2548
2549
2550
2551 <p><b>Rationale:</b></p>
2552 <p>It is possible but not easy to instantiate on types other than char
2553 or wchar_t; many things have to be done first. That is by intention
2554 and is not a defect.</p>
2555
2556
2557
2558
2559 <hr>
2560 <h3><a name="204"></a>204. distance(first, last) when "last" is before "first"</h3>
2561 <p><b>Section:</b> 24.3.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2562  <b>Submitter:</b> Rintala Matti <b>Date:</b> 2000-01-28</p>
2563 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2564 <p><b>Discussion:</b></p>
2565 <p>Section 24.3.4 describes the function distance(first, last) (where first and
2566 last are iterators) which calculates "the number of increments or
2567 decrements needed to get from 'first' to 'last'".</p>
2568 <p>The function should work for forward, bidirectional and random access
2569 iterators, and there is a requirement 24.3.4.5 which states that "'last'
2570 must be reachable from 'first'".</p>
2571 <p>With random access iterators the function is easy to implement as "last
2572 - first".</p>
2573 <p>With forward iterators it's clear that 'first' must point to a place before
2574 'last', because otherwise 'last' would not be reachable from 'first'.</p>
2575 <p>But what about bidirectional iterators? There 'last' is reachable from
2576 'first' with the -- operator even if 'last' points to an earlier position than
2577 'first'. However, I cannot see how the distance() function could be implemented
2578 if the implementation does not know which of the iterators points to an earlier
2579 position (you cannot use ++ or -- on either iterator if you don't know which
2580 direction is the "safe way to travel").</p>
2581 <p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they
2582 use ++ to provide linear time implementations". However, the ++ operator is
2583 not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly
2584 mentions that distance() returns the number of increments _or decrements_,
2585 suggesting that it could return a negative number also for bidirectional
2586 iterators when 'last' points to a position before 'first'.</p>
2587 <p>Is a further requirement is needed to state that for forward and
2588 bidirectional iterators "'last' must be reachable from 'first' using the ++
2589 operator". Maybe this requirement might also apply to random access
2590 iterators so that distance() would work the same way for every iterator
2591 category?</p>
2592
2593
2594 <p><b>Rationale:</b></p>
2595 <p>"Reachable" is defined in the standard in 24.1 [iterator.requirements] paragraph 6.
2596 The definition is only in terms of operator++(). The LWG sees no defect in
2597 the standard.</p>
2598
2599
2600
2601
2602 <hr>
2603 <h3><a name="205"></a>205.  numeric_limits unclear on how to determine floating point types</h3>
2604 <p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2605  <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-01-28</p>
2606 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
2607 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2608 <p><b>Discussion:</b></p>
2609 <p>In several places in 18.2.1.2 [numeric.limits.members], a member is
2610 described as "Meaningful for all floating point types."
2611 However, no clear method of determining a floating point type is
2612 provided.</p>
2613
2614 <p>In 18.2.1.5 [numeric.special], paragraph 1 states ". . . (for
2615 example, epsilon() is only meaningful if is_integer is
2616 false). . ." which suggests that a type is a floating point type
2617 if is_specialized is true and is_integer is false; however, this is
2618 unclear.</p>
2619
2620 <p>When clarifying this, please keep in mind this need of users: what
2621 exactly is the definition of floating point? Would a fixed point or
2622 rational representation be considered one? I guess my statement here
2623 is that there could also be types that are neither integer or
2624 (strictly) floating point.</p>
2625
2626
2627 <p><b>Rationale:</b></p>
2628 <p>It is up to the implementor of a user define type to decide if it is a
2629 floating point type.</p>
2630
2631
2632
2633
2634 <hr>
2635 <h3><a name="207"></a>207. ctype&lt;char&gt; members return clause incomplete</h3>
2636 <p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2637  <b>Submitter:</b> Robert Klarer <b>Date:</b> 1999-11-02</p>
2638 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
2639 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2640 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a></p>
2641 <p><b>Discussion:</b></p>
2642 <p>
2643 The <tt>widen</tt> and <tt>narrow</tt> member functions are described
2644 in 22.2.1.3.2, paragraphs 9-11.  In each case we have two overloaded
2645 signatures followed by a <b>Returns</b> clause.  The <b>Returns</b>
2646 clause only describes one of the overloads.
2647 </p>
2648
2649
2650 <p><b>Proposed resolution:</b></p>
2651 <p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
2652 paragraph 10 from:</p>
2653 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
2654
2655 <p>to:</p>
2656 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
2657 respectively.</p>
2658
2659 <p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] paragraph 11
2660 from:</p>
2661 <p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(low, high, to).</p>
2662
2663 <p>to:</p>
2664 <p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(c) or do_narrow(low, high, to),
2665 respectively.</p>
2666
2667
2668 <p><b>Rationale:</b></p>
2669 <p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, which addresses the same
2670 paragraphs.</p>
2671
2672
2673
2674
2675
2676
2677 <hr>
2678 <h3><a name="213"></a>213. Math function overloads ambiguous</h3>
2679 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2680  <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
2681 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
2682 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
2683 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2684 <p><b>Discussion:</b></p>
2685 <p>Due to the additional overloaded versions of numeric functions for
2686 float and long double according to Section 26.5, calls such as int x;
2687 std::pow (x, 4) are ambiguous now in a standard conforming
2688 implementation. Current implementations solve this problem very
2689 different (overload for all types, don't overload for float and long
2690 double, use preprocessor, follow the standard and get
2691 ambiguities).</p> <p>This behavior should be standardized or at least
2692 identified as implementation defined.</p>
2693
2694
2695 <p><b>Rationale:</b></p>
2696 <p>These math issues are an
2697 understood and accepted consequence of the design. They have
2698 been discussed several times in the past. Users must write casts
2699 or write floating point expressions as arguments.</p>
2700
2701
2702
2703
2704 <hr>
2705 <h3><a name="215"></a>215. Can a map's key_type be const?</h3>
2706 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2707  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-29</p>
2708 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
2709 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2710 <p><b>Discussion:</b></p>
2711 <p>A user noticed that this doesn't compile with the Rogue Wave library because
2712 the rb_tree class declares a key_allocator, and allocator&lt;const int&gt; is
2713 not legal, I think:</p>
2714 <blockquote>
2715   <pre>map &lt; const int, ... &gt; // legal?</pre>
2716 </blockquote>
2717 <p>which made me wonder whether it is legal for a map's key_type to be const. In
2718 email from Matt Austern he said:</p>
2719 <blockquote>
2720 <p>I'm not sure whether it's legal to declare a map with a const key type. I
2721 hadn't thought about that question until a couple weeks ago. My intuitive
2722 feeling is that it ought not to be allowed, and that the standard ought to say
2723 so. It does turn out to work in SGI's library, though, and someone in the
2724 compiler group even used it. Perhaps this deserves to be written up as an issue
2725 too.</p>
2726 </blockquote>
2727
2728
2729 <p><b>Rationale:</b></p>
2730 <p>The "key is assignable" requirement from table 69 in
2731 23.1.2 [associative.reqmts] already implies the key cannot be const.</p>
2732
2733
2734
2735
2736 <hr>
2737 <h3><a name="216"></a>216. setbase manipulator description flawed</h3>
2738 <p><b>Section:</b> 27.6.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2739  <b>Submitter:</b> Hyman Rosen <b>Date:</b> 2000-02-29</p>
2740 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</p>
2741 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2742 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a></p>
2743 <p><b>Discussion:</b></p>
2744 <p>27.6.3 [std.manip] paragraph 5 says:</p>
2745 <blockquote>
2746 <pre>smanip setbase(int base);</pre>
2747 <p> Returns: An object s of unspecified type such that if out is an
2748 (instance of) basic_ostream then the expression out&lt;&lt;s behaves
2749 as if f(s) were called, in is an (instance of) basic_istream then the
2750 expression in&gt;&gt;s behaves as if f(s) were called. Where f can be
2751 defined as:</p>
2752 <pre>ios_base&amp; f(ios_base&amp; str, int base)
2753 {
2754   // set basefield
2755   str.setf(n == 8 ? ios_base::oct :
2756                 n == 10 ? ios_base::dec :
2757                 n == 16 ? ios_base::hex :
2758                   ios_base::fmtflags(0), ios_base::basefield);
2759   return str;
2760 }</pre>
2761 </blockquote>
2762 <p>There are two problems here. First, f takes two parameters, so the
2763 description needs to say that out&lt;&lt;s and in&gt;&gt;s behave as if f(s,base)
2764 had been called. Second, f is has a parameter named base, but is written as if
2765 the parameter was named n.</p>
2766 <p>Actually, there's a third problem. The paragraph has grammatical errors.
2767 There needs to be an "and" after the first comma, and the "Where
2768 f" sentence fragment needs to be merged into its preceding sentence. You
2769 may also want to format the function a little better. The formatting above is
2770 more-or-less what the Standard contains.</p>
2771
2772
2773 <p><b>Rationale:</b></p>
2774 <p>The resolution of this defect is subsumed by the proposed resolution for
2775 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>.</p>
2776
2777 <p><i>[Tokyo: The LWG agrees that this is a defect and notes that it
2778 occurs additional places in the section, all requiring fixes.]</i></p>
2779
2780
2781
2782
2783
2784
2785
2786
2787 <hr>
2788 <h3><a name="218"></a>218. Algorithms do not use binary predicate objects for default comparisons</h3>
2789 <p><b>Section:</b> 25.3 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2790  <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p>
2791 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
2792 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2793 <p><b>Discussion:</b></p>
2794 <p>Many of the algorithms take an argument, pred, of template parameter type
2795 BinaryPredicate or an argument comp of template parameter type Compare. These
2796 algorithms usually have an overloaded version that does not take the predicate
2797 argument. In these cases pred is usually replaced by the use of operator== and
2798 comp is replaced by the use of operator&lt;.</p>
2799 <p>This use of hard-coded operators is inconsistent with other parts of the
2800 library, particularly the containers library, where equality is established
2801 using equal_to&lt;&gt; and ordering is established using less&lt;&gt;. Worse,
2802 the use of operator&lt;, would cause the following innocent-looking code to have
2803 undefined behavior:</p>
2804 <blockquote>
2805   <pre>vector&lt;string*&gt; vec;
2806 sort(vec.begin(), vec.end());</pre>
2807 </blockquote>
2808 <p>The use of operator&lt; is not defined for pointers to unrelated objects. If
2809 std::sort used less&lt;&gt; to compare elements, then the above code would be
2810 well-defined, since less&lt;&gt; is explicitly specialized to produce a total
2811 ordering of pointers.</p>
2812
2813
2814 <p><b>Rationale:</b></p>
2815 <p>This use of operator== and operator&lt; was a very deliberate, conscious, and
2816 explicitly made design decision; these operators are often more efficient. The
2817 predicate forms are available for users who don't want to rely on operator== and
2818 operator&lt;.</p>
2819
2820
2821
2822
2823 <hr>
2824 <h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3>
2825 <p><b>Section:</b> 25.1.2 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
2826  <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p>
2827 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
2828 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
2829 <p><b>Discussion:</b></p>
2830 <p>The find function always searches for a value using operator== to compare the
2831 value argument to each element in the input iterator range. This is inconsistent
2832 with other find-related functions such as find_end and find_first_of, which
2833 allow the caller to specify a binary predicate object to be used for determining
2834 equality. The fact that this can be accomplished using a combination of find_if
2835 and bind_1st or bind_2nd does not negate the desirability of a consistent,
2836 simple, alternative interface to find.</p>
2837
2838
2839 <p><b>Proposed resolution:</b></p>
2840 <blockquote>
2841 <p>In section 25.1.2 [alg.find], add a second prototype for find
2842 (between the existing prototype and the prototype for find_if), as
2843 follows:</p>
2844 <pre>    template&lt;class InputIterator, class T, class BinaryPredicate&gt;
2845       InputIterator find(InputIterator first, InputIterator last,
2846                          const T&amp; value, BinaryPredicate bin_pred);</pre>
2847 <p>Change the description of the return from:</p>
2848 <blockquote>
2849   <p>Returns: The first iterator i in the range [first, last) for which the following corresponding
2850   conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p>
2851 </blockquote>
2852 <p>&nbsp;to:</p>
2853 <blockquote>
2854   <p>Returns: The first iterator i in the range [first, last) for which the following&nbsp;
2855   corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
2856   != false. Return last if no such iterator is found.</p>
2857 </blockquote>
2858 </blockquote>
2859
2860
2861 <p><b>Rationale:</b></p>
2862 <p>This is request for a pure extension, so it is not a defect in the
2863 current standard.&nbsp; As the submitter pointed out, "this can
2864 be accomplished using a combination of find_if and bind_1st or
2865 bind_2nd".</p>
2866
2867
2868
2869
2870 <hr>
2871 <h3><a name="236"></a>236. ctype&lt;char&gt;::is() member modifies facet</h3>
2872 <p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2873  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p>
2874 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
2875 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2876 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a></p>
2877 <p><b>Discussion:</b></p>
2878 <p>The description of the <tt>is()</tt> member in paragraph 4 of 22.2.1.3.2 [facet.ctype.char.members] is broken: According to this description, the
2879 second form of the <tt>is()</tt> method modifies the masks in the
2880 <tt>ctype</tt> object. The correct semantics if, of course, to obtain
2881 an array of masks. The corresponding method in the general case,
2882 ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p>
2883
2884
2885 <p><b>Proposed resolution:</b></p>
2886   <p>Change paragraph 4 from</p>
2887     <blockquote><p>
2888     The second form, for all *p in the range [low, high), assigns
2889     vec[p-low] to table()[(unsigned char)*p].
2890     </p></blockquote>
2891   <p>to become</p>
2892     <blockquote><p>
2893     The second form, for all *p in the range [low, high), assigns
2894     table()[(unsigned char)*p] to vec[p-low].
2895   </p></blockquote>
2896
2897
2898 <p><b>Rationale:</b></p>
2899
2900
2901
2902
2903
2904 <hr>
2905 <h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3>
2906 <p><b>Section:</b> 25.1.2 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2907  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p>
2908 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
2909 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2910 <p><b>Discussion:</b></p>
2911 <p>Is the following implementation of <tt>find</tt> acceptable?</p>
2912
2913 <pre>        template&lt;class Iter, class X&gt;
2914         Iter find(Iter begin, Iter end, const X&amp; x)
2915         {
2916             X x1 = x;           // this is the crucial statement
2917             while (begin != end &amp;&amp; *begin != x1)
2918                 ++begin;
2919             return begin;
2920         }
2921 </pre>
2922
2923 <p>If the answer is yes, then it is implementation-dependent as to
2924 whether the following fragment is well formed:</p>
2925
2926 <pre>        vector&lt;string&gt; v;
2927
2928         find(v.begin(), v.end(), "foo");
2929 </pre>
2930
2931 <p>At issue is whether there is a requirement that the third argument
2932 of find be CopyConstructible.  There may be no problem here, but
2933 analysis is necessary.</p>
2934
2935
2936 <p><b>Rationale:</b></p>
2937 <p>There is no indication in the standard that find's third argument
2938 is required to be Copy Constructible.  The LWG believes that no such
2939 requirement was intended.  As noted above, there are times when a user
2940 might reasonably pass an argument that is not Copy Constructible.</p>
2941
2942
2943
2944
2945 <hr>
2946 <h3><a name="245"></a>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</h3>
2947 <p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2948  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p>
2949 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2950 <p><b>Discussion:</b></p>
2951 <p>I do not think the standard specifies what operation(s) on istream
2952 iterators trigger input operations.  So, for example:</p>
2953
2954 <pre>        istream_iterator&lt;int&gt; i(cin);
2955
2956         int n = *i++;
2957 </pre>
2958
2959 <p>I do not think it is specified how many integers have been read
2960 from cin.  The number must be at least 1, of course, but can it be 2?
2961 More?</p>
2962
2963
2964 <p><b>Rationale:</b></p>
2965 <p>The standard is clear as written: the stream is read every time
2966 operator++ is called, and it is also read either when the iterator is
2967 constructed or when operator* is called for the first time.  In the
2968 example above, exactly two integers are read from cin.</p>
2969
2970 <p>There may be a problem with the interaction between istream_iterator
2971 and some STL algorithms, such as find.  There are no guarantees about
2972 how many times find may invoke operator++.</p>
2973
2974
2975
2976
2977 <hr>
2978 <h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3>
2979 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2980  <b>Submitter:</b> Mark Rodgers <b>Date:</b> 2000-05-19</p>
2981 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
2982 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2983 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
2984 <p><b>Discussion:</b></p>
2985 <p>Closed issue 192 raised several problems with the specification of
2986 this function, but was rejected as Not A Defect because it was too big
2987 a change with unacceptable impacts on existing implementations.
2988 However, issues remain that could be addressed with a smaller change
2989 and with little or no consequent impact.</p>
2990
2991 <ol>
2992    <li><p> The specification is inconsistent with the original
2993    proposal and with several implementations.</p>
2994
2995    <p>The initial implementation by Hewlett Packard only ever looked
2996    immediately <i>before</i> p, and I do not believe there was any
2997    intention to standardize anything other than this behavior.
2998    Consequently, current implementations by several leading
2999    implementors also look immediately before p, and will only insert
3000    after p in logarithmic time.  I am only aware of one implementation
3001    that does actually look after p, and it looks before p as well.  It
3002    is therefore doubtful that existing code would be relying on the
3003    behavior defined in the standard, and it would seem that fixing
3004    this defect as proposed below would standardize existing
3005    practice.</p></li>
3006
3007    <li><p>
3008    The specification is inconsistent with insertion for sequence
3009    containers.</p>
3010
3011    <p>This is difficult and confusing to teach to newcomers.  All
3012    insert operations that specify an iterator as an insertion location
3013    should have a consistent meaning for the location represented by
3014    that iterator.</p></li>
3015
3016    <li><p> As specified, there is no way to hint that the insertion
3017    should occur at the beginning of the container, and the way to hint
3018    that it should occur at the end is long winded and unnatural.</p>
3019
3020    <p>For a container containing n elements, there are n+1 possible
3021    insertion locations and n+1 valid iterators.  For there to be a
3022    one-to-one mapping between iterators and insertion locations, the
3023    iterator must represent an insertion location immediately before
3024    the iterator.</p></li>
3025
3026    <li><p> When appending sorted ranges using insert_iterators,
3027    insertions are guaranteed to be sub-optimal.</p>
3028
3029    <p>In such a situation, the optimum location for insertion is
3030    always immediately after the element previously inserted.  The
3031    mechanics of the insert iterator guarantee that it will try and
3032    insert after the element after that, which will never be correct.
3033    However, if the container first tried to insert before the hint,
3034    all insertions would be performed in amortized constant
3035    time.</p></li>
3036 </ol>
3037
3038
3039 <p><b>Proposed resolution:</b></p>
3040 <p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make
3041 the following changes in the row for a.insert(p,t):</p>
3042
3043 <p><i>assertion/note pre/post condition:</i>
3044 <br>Change the last sentence from</p>
3045      <blockquote><p>
3046      "iterator p is a hint pointing to where the insert should
3047      start to search."
3048      </p></blockquote>
3049 <p>to</p>
3050      <blockquote><p>
3051      "iterator p is a hint indicating that immediately before p
3052      may be a correct location where the insertion could occur."
3053      </p></blockquote>
3054
3055 <p><i>complexity:</i><br>
3056 Change the words "right after" to "immediately before".</p>
3057
3058
3059 <p><b>Rationale:</b></p>
3060
3061
3062
3063
3064
3065 <hr>
3066 <h3><a name="249"></a>249. Return Type of <tt>auto_ptr::operator=</tt></h3>
3067 <p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3068  <b>Submitter:</b> Joseph Gottman <b>Date:</b> 2000-06-30</p>
3069 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
3070 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3071 <p><b>Discussion:</b></p>
3072 <p>According to section 20.4.5, the function
3073 <tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr.
3074 The reason that <tt>operator=()</tt> usually returns a reference is to
3075 facilitate code like</p>
3076
3077 <pre>    int x,y,z;
3078     x = y = z = 1;
3079 </pre>
3080
3081 <p>However, given analogous code for <tt>auto_ptr</tt>s,</p>
3082 <pre>    auto_ptr&lt;int&gt; x, y, z;
3083     z.reset(new int(1));
3084     x = y = z;
3085 </pre>
3086
3087 <p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to
3088 NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value.
3089 This makes such cascading assignments useless and counterintuitive for
3090 <tt>auto_ptr</tt>s.</p>
3091
3092
3093 <p><b>Proposed resolution:</b></p>
3094 <p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead
3095 of an <tt>auto_ptr</tt> reference.</p>
3096
3097
3098 <p><b>Rationale:</b></p>
3099 <p>The return value has uses other than cascaded assignments: a user can
3100 call an auto_ptr member function, pass the auto_ptr to a
3101 function, etc.  Removing the return value could break working user
3102 code.</p>
3103
3104
3105
3106
3107 <hr>
3108 <h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3>
3109 <p><b>Section:</b> 20.5.3 [base], 24.3.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3110  <b>Submitter:</b> Robert Dick  <b>Date:</b> 2000-08-17</p>
3111 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
3112 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3113 <p><b>Discussion:</b></p>
3114 <p>
3115 According to the November 1997 Draft Standard, the results of deleting an
3116 object of a derived class through a pointer to an object of its base class are
3117 undefined if the base class has a non-virtual destructor.  Therefore, it is
3118 potentially dangerous to publicly inherit from such base classes.
3119 </p>
3120
3121 <p>Defect:
3122 <br>
3123 The STL design encourages users to publicly inherit from a number of classes
3124 which do nothing but specify interfaces, and which contain non-virtual
3125 destructors.
3126 </p>
3127
3128 <p>Attribution:
3129 <br>
3130 Wil Evers and William E. Kempf suggested this modification for functional
3131 objects.
3132 </p>
3133
3134
3135 <p><b>Proposed resolution:</b></p>
3136 <p>
3137 When a base class in the standard library is useful only as an interface
3138 specifier, i.e., when an object of the class will never be directly
3139 instantiated, specify that the class contains a protected destructor.  This
3140 will prevent deletion through a pointer to the base class without performance,
3141 or space penalties (on any implementation I'm aware of).
3142 </p>
3143
3144 <p>
3145 As an example, replace...
3146 </p>
3147
3148 <pre>    template &lt;class Arg, class Result&gt;
3149     struct unary_function {
3150             typedef Arg    argument_type;
3151             typedef Result result_type;
3152     };
3153 </pre>
3154
3155 <p>
3156 ... with...
3157 </p>
3158
3159 <pre>    template &lt;class Arg, class Result&gt;
3160     struct unary_function {
3161             typedef Arg    argument_type;
3162             typedef Result result_type;
3163     protected:
3164             ~unary_function() {}
3165     };
3166 </pre>
3167
3168 <p>
3169 Affected definitions:
3170 <br>
3171   &nbsp;20.3.1 [lib.function.objects] -- unary_function, binary_function
3172   <br>
3173   &nbsp;24.3.2 [lib.iterator.basic] -- iterator
3174 </p>
3175
3176
3177 <p><b>Rationale:</b></p>
3178 <p>
3179 The standard is clear as written; this is a request for change, not a
3180 defect in the strict sense.  The LWG had several different objections
3181 to the proposed change.  One is that it would prevent users from
3182 creating objects of type <tt>unary_function</tt> and
3183 <tt>binary_function</tt>.  Doing so can sometimes be legitimate, if users
3184 want to pass temporaries as traits or tag types in generic code.
3185 </p>
3186
3187
3188
3189
3190
3191 <hr>
3192 <h3><a name="267"></a>267. interaction of strstreambuf::overflow() and seekoff()</h3>
3193 <p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3194  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-10-05</p>
3195 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
3196 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3197 <p><b>Discussion:</b></p>
3198 <p>
3199 It appears that the interaction of the strstreambuf members overflow()
3200 and seekoff() can lead to undefined behavior in cases where defined
3201 behavior could reasonably be expected. The following program
3202 demonstrates this behavior:
3203 </p>
3204
3205 <pre>    #include &lt;strstream&gt;
3206
3207     int main ()
3208     {
3209          std::strstreambuf sb;
3210          sb.sputc ('c');
3211
3212          sb.pubseekoff (-1, std::ios::end, std::ios::in);
3213          return !('c' == sb.sgetc ());
3214     }
3215 </pre>
3216
3217 <p>
3218 D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf&lt;&gt;(),
3219 which in turn sets all pointers to 0 in 27.5.2.1, p1.
3220 </p>
3221
3222 <p>
3223 27.5.2.2.5, p1 says that basic_streambuf&lt;&gt;::sputc(c) calls
3224 overflow(traits::to_int_type(c)) if a write position isn't available (it
3225 isn't due to the above).
3226 </p>
3227
3228 <p>
3229 D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at
3230 least one write position available (i.e., it allows the function to make
3231 any positive number of write positions available).
3232 </p>
3233
3234 <p>
3235 D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see
3236 seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this
3237 case. newoff is then epptr() - eback().
3238 </p>
3239
3240 <p>
3241 D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or
3242 gptr() == epptr() + off holds.
3243 </p>
3244
3245 <p>
3246 If strstreambuf::overflow() made exactly one write position available
3247 then gptr() will be set to just before epptr(), and the program will
3248 return 0. Buf if the function made more than one write position
3249 available, epptr() and gptr() will both point past pptr() and the
3250 behavior of the program is undefined.
3251 </p>
3252
3253
3254 <p><b>Proposed resolution:</b></p>
3255
3256
3257    <p>Change the last sentence of D.7.1 [depr.strstreambuf] paragraph 4 from</p>
3258
3259       <blockquote><p>
3260       Otherwise, seeklow equals gbeg and seekhigh is either pend, if
3261       pend is not a null pointer, or gend.
3262       </p></blockquote>
3263
3264    <p>to become</p>
3265
3266       <blockquote><p>
3267       Otherwise, seeklow equals gbeg and seekhigh is either gend if
3268       0 == pptr(), or pbase() + max where max is the maximum value of
3269       pptr() - pbase() ever reached for this stream.
3270       </p></blockquote>
3271
3272 <p><i>[
3273   pre-Copenhagen: Dietmar provided wording for proposed resolution.
3274 ]</i></p>
3275
3276
3277 <p><i>[
3278   post-Copenhagen: Fixed a typo: proposed resolution said to fix
3279   4.7.1, not D.7.1.
3280 ]</i></p>
3281
3282
3283
3284
3285 <p><b>Rationale:</b></p>
3286 <p>This is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>: it's not clear what it
3287 means to seek beyond the current area.  Without resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a> we can't resolve this.  As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>,
3288 the library working group does not wish to invest time nailing down
3289 corner cases in a deprecated feature.</p>
3290
3291
3292
3293
3294
3295 <hr>
3296 <h3><a name="269"></a>269. cstdarg and unnamed parameters</h3>
3297 <p><b>Section:</b> 18.7 [support.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3298  <b>Submitter:</b> J. Stephen Adamczyk <b>Date:</b> 2000-10-10</p>
3299 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</p>
3300 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3301 <p><b>Discussion:</b></p>
3302 <p>
3303 One of our customers asks whether this is valid C++:
3304 </p>
3305
3306 <pre>   #include &lt;cstdarg&gt;
3307
3308    void bar(const char *, va_list);
3309
3310    void
3311    foo(const char *file, const char *, ...)
3312    {
3313      va_list ap;
3314      va_start(ap, file);
3315      bar(file, ap);
3316      va_end(ap);
3317    }
3318 </pre>
3319
3320 <p>
3321 The issue being whether it is valid to use cstdarg when the final
3322 parameter before the "..." is unnamed.  cstdarg is, as far
3323 as I can tell, inherited verbatim from the C standard. and the
3324 definition there (7.8.1.1 in the ISO C89 standard) refers to "the
3325 identifier of the rightmost parameter".  What happens when there
3326 is no such identifier?
3327 </p>
3328
3329 <p>
3330 My personal opinion is that this should be allowed, but some tweak
3331 might be required in the C++ standard.
3332 </p>
3333
3334
3335 <p><b>Rationale:</b></p>
3336 <p>
3337 Not a defect, the C and C++ standards are clear.  It is impossible to
3338 use varargs if the parameter immediately before "..." has no
3339 name, because that is the parameter that must be passed to va_start.
3340 The example given above is broken, because va_start is being passed
3341 the wrong parameter.
3342 </p>
3343
3344 <p>
3345 There is no support for extending varargs to provide additional
3346 functionality beyond what's currently there.  For reasons of C/C++
3347 compatibility, it is especially important not to make gratuitous
3348 changes in this part of the C++ standard.  The C committee has already
3349 been requested not to touch this part of the C standard unless
3350 necessary.
3351 </p>
3352
3353
3354
3355
3356 <hr>
3357 <h3><a name="277"></a>277. Normative encouragement in allocator requirements unclear</h3>
3358 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3359  <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-07</p>
3360 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
3361 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
3362 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3363 <p><b>Discussion:</b></p>
3364 <p>
3365 In 20.1.5, paragraph 5, the standard says that "Implementors are
3366 encouraged to supply libraries that can accept allocators that
3367 encapsulate more general memory models and that support non-equal
3368 instances." This is intended as normative encouragement to
3369 standard library implementors.  However, it is possible to interpret
3370 this sentence as applying to nonstandard third-party libraries.
3371 </p>
3372
3373
3374 <p><b>Proposed resolution:</b></p>
3375 <p>
3376 In 20.1.5, paragraph 5, change "Implementors" to
3377 "Implementors of the library described in this International
3378 Standard".
3379 </p>
3380
3381
3382 <p><b>Rationale:</b></p>
3383 <p>The LWG believes the normative encouragement is already
3384 sufficiently clear, and that there are no important consequences
3385 even if it is misunderstood.</p>
3386
3387
3388
3389
3390
3391 <hr>
3392 <h3><a name="279"></a>279. const and non-const iterators should have equivalent typedefs</h3>
3393 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3394  <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</p>
3395 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
3396 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
3397 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3398 <p><b>Discussion:</b></p>
3399
3400 <p>
3401 This came from an email from Steve Cleary to Fergus in reference to
3402 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
3403 this in Toronto and believes it should be a separate issue.
3404 </p>
3405
3406 <p>
3407 Steve said: "We may want to state that the const/non-const iterators must have
3408 the same difference type, size_type, and category."
3409 </p>
3410
3411 <p>
3412 (Comment from Judy)
3413 I'm not sure if the above sentence should be true for all
3414 const and non-const iterators in a particular container, or if it means
3415 the container's iterator can't be compared with the container's
3416 const_iterator unless the above it true. I suspect the former.
3417 </p>
3418
3419
3420 <p><b>Proposed resolution:</b></p>
3421 <p>
3422 In <b>Section:</b> 23.1 [container.requirements],
3423 table 65, in the assertion/note pre/post condition for X::const_iterator,
3424 add the following:
3425 </p>
3426
3427 <blockquote>
3428 <p>
3429 typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type)
3430 </p>
3431
3432 <p>
3433 typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type)
3434 </p>
3435
3436 <p>
3437 typeid(X::const_iterator::category) == typeid(X::iterator::category)
3438 </p>
3439 </blockquote>
3440
3441
3442 <p><b>Rationale:</b></p>
3443 <p>Going through the types one by one: Iterators don't have a
3444 <tt>size_type</tt>.  We already know that the difference types are
3445 identical, because the container requirements already say that the
3446 difference types of both X::iterator and X::const_iterator are both
3447 X::difference_type.  The standard does not require that X::iterator
3448 and X::const_iterator have the same iterator category, but the LWG
3449 does not see this as a defect: it's possible to imagine cases in which
3450 it would be useful for the categories to be different.</p>
3451
3452 <p>It may be desirable to require X::iterator and X::const_iterator to
3453 have the same value type, but that is a new issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>.)</p>
3454
3455
3456
3457
3458
3459
3460 <hr>
3461 <h3><a name="287"></a>287. conflicting ios_base fmtflags</h3>
3462 <p><b>Section:</b> 27.4.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3463  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
3464 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</p>
3465 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3466 <p><b>Discussion:</b></p>
3467 <p>
3468 The Effects clause for ios_base::setf(fmtflags fmtfl) says
3469 "Sets fmtfl in flags()".  What happens if the user first calls
3470 ios_base::scientific and then calls ios_base::fixed or vice-versa?
3471 This is an issue for all of the conflicting flags, i.e. ios_base::left
3472 and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct.
3473 </p>
3474
3475 <p>
3476 I see three possible solutions:
3477 </p>
3478
3479 <ol>
3480 <li>Set ios_base::failbit whenever the user specifies a conflicting
3481 flag with one previously explicitly set. If the constructor is
3482 supposed to set ios_base::dec (see discussion below), then
3483 the user setting hex or oct format after construction will not
3484 set failbit. </li>
3485 <li>The last call to setf "wins", i.e. it clears any conflicting
3486 previous setting.</li>
3487 <li>All the flags that the user specifies are set, but when actually
3488 interpreting them, fixed always override scientific, right always
3489 overrides left, dec overrides hex which overrides oct.</li>
3490 </ol>
3491
3492 <p>
3493 Most existing implementations that I tried seem to conform to resolution #3,
3494 except that when using the iomanip manipulator hex or oct then that always
3495 overrides dec, but calling setf(ios_base::hex) doesn't.
3496 </p>
3497
3498 <p>
3499 There is a sort of related issue, which is that although the ios_base
3500 constructor says that each ios_base member has an indeterminate value
3501 after construction, all the existing implementations I tried explicitly set
3502 ios_base::dec.
3503 </p>
3504
3505
3506 <p><b>Proposed resolution:</b></p>
3507
3508
3509 <p><b>Rationale:</b></p>
3510 <p>
3511 <tt>adjustfield</tt>, <tt>basefield</tt>, and <tt>floatfield</tt>
3512 are each multi-bit fields.  It is possible to set multiple bits within
3513 each of those fields.  (For example, <tt>dec</tt> and
3514 <tt>oct</tt>). These fields are used by locale facets. The LWG
3515 reviewed the way in which each of those three fields is used, and
3516 believes that in each case the behavior is well defined for any
3517 possible combination of bits. See for example Table 58, in 22.2.2.2.2
3518 [facet.num.put.virtuals], noting the requirement in paragraph 6 of that
3519 section.
3520 </p>
3521 <p>
3522 Users are advised to use manipulators, or else use the two-argument
3523 version of <tt>setf</tt>, to avoid unexpected behavior.
3524 </p>
3525
3526
3527
3528
3529
3530 <hr>
3531 <h3><a name="289"></a>289. &lt;cmath&gt; requirements missing C float and long double versions</h3>
3532 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3533  <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
3534 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
3535 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
3536 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3537 <p><b>Discussion:</b></p>
3538 <p>
3539     In ISO/IEC 9899:1990 Programming Languages C we find the following
3540     concerning &lt;math.h&gt;:
3541 </p>
3542
3543 <blockquote><p>
3544          7.13.4 Mathematics &lt;math.h&gt;
3545          <br>
3546          The names of all existing functions declared in the &lt;math.h&gt;
3547          header, suffixed with f or l, are reserved respectively for
3548          corresponding functions with float and long double arguments
3549          are return values.
3550 </p></blockquote>
3551
3552 <p>
3553     For example, <tt>float&nbsp;sinf(float)</tt>
3554     is reserved.
3555 </p>
3556
3557 <p>
3558     In the C99 standard, &lt;math.h&gt; must contain declarations
3559     for these functions.
3560 </p>
3561
3562 <p>
3563 So, is it acceptable for an implementor to add these prototypes to the
3564 C++ versions of the math headers? Are they required?
3565 </p>
3566
3567
3568 <p><b>Proposed resolution:</b></p>
3569 <p>
3570 Add these Functions to Table 80, section 26.5 and to Table 99,
3571 section C.2:
3572 </p>
3573
3574 <pre>    acosf asinf atanf atan2f ceilf cosf coshf
3575     expf fabsf floorf fmodf frexpf ldexpf
3576     logf log10f modff powf sinf sinhf sqrtf
3577     tanf tanhf
3578     acosl asinl atanl atan2l ceill cosl coshl
3579     expl fabsl floorl fmodl frexpl ldexpl
3580     logl log10l modfl powl sinl sinhl sqrtl
3581     tanl tanhl
3582 </pre>
3583
3584 <p>
3585 There should probably be a note saying that these functions
3586 are optional and, if supplied, should match the description in
3587 the 1999 version of the C standard. In the next round
3588 of C++ standardization they can then become mandatory.
3589 </p>
3590
3591
3592 <p><b>Rationale:</b></p>
3593 <p>The C90 standard, as amended, already permits (but does not
3594 require) these functions, and the C++ standard incorporates the
3595 C90 standard by reference.  C99 is not an issue, because it is
3596 never referred to by the C++ standard.</p>
3597
3598
3599
3600
3601
3602 <hr>
3603 <h3><a name="293"></a>293. Order of execution in transform algorithm</h3>
3604 <p><b>Section:</b> 25.2.4 [alg.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3605  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-04</p>
3606 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</p>
3607 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3608 <p><b>Discussion:</b></p>
3609 <p>This issue is related to issue 242.  In case that the resolution
3610 proposed for issue 242 is accepted, we have have the following
3611 situation: The 4 numeric algorithms (accumulate and consorts) as well
3612 as transform would allow a certain category of side effects.  The
3613 numeric algorithms specify that they invoke the functor "for
3614 every iterator i in the range [first, last) in order". transform,
3615 in contrast, would not give any guarantee regarding order of
3616 invocation of the functor, which means that the functor can be invoked
3617 in any arbitrary order.
3618 </p>
3619
3620 <p>Why would that be a problem?  Consider an example: say the
3621 transformator that is a simple enumerator ( or more generally
3622 speaking, "is order-sensitive" ).  Since a standard
3623 compliant implementation of transform is free to invoke the enumerator
3624 in no definite order, the result could be a garbled enumeration.
3625 Strictly speaking this is not a problem, but it is certainly at odds
3626 with the prevalent understanding of transform as an algorithms that
3627 assigns "a new _corresponding_ value" to the output
3628 elements.
3629 </p>
3630
3631 <p>All implementations that I know of invoke the transformator in
3632 definite order, namely starting from first and proceeding to last -
3633 1. Unless there is an optimization conceivable that takes advantage of
3634 the indefinite order I would suggest to specify the order, because it
3635 eliminate the uncertainty that users would otherwise have regarding
3636 the order of execution of their potentially order-sensitive function
3637 objects.
3638 </p>
3639
3640
3641 <p><b>Proposed resolution:</b></p>
3642 <p>In section 25.2.3 - Transform [lib.alg.transform] change:</p>
3643 <blockquote><p>
3644 -1- Effects: Assigns through every iterator i in the range [result,
3645 result + (last1 - first1)) a new corresponding
3646 value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
3647 (i - result), *(first2 + (i - result))).
3648 </p></blockquote>
3649 <p>to:</p>
3650 <blockquote><p>
3651 -1- Effects: Computes values by  invoking the operation op or binary_op
3652 for every iterator in the range [first1, last1) in order. Assigns through
3653 every iterator i in the range [result, result + (last1 - first1)) a new
3654 corresponding
3655 value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
3656 (i - result), *(first2 + (i - result))).
3657 </p></blockquote>
3658
3659
3660 <p><b>Rationale:</b></p>
3661 <p>For Input Iterators an order is already guaranteed, because
3662 only one order is possible.  If a user who passes a Forward
3663 Iterator to one of these algorithms really needs a specific
3664 order of execution, it's possible to achieve that effect by
3665 wrapping it in an Input Iterator adaptor.</p>
3666
3667
3668
3669
3670
3671 <hr>
3672 <h3><a name="296"></a>296. Missing descriptions and requirements of pair operators</h3>
3673 <p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3674  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-14</p>
3675 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
3676 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3677 <p><b>Discussion:</b></p>
3678 <p>The synopsis of the header <tt>&lt;utility&gt;</tt> in 20.2 [utility]
3679 lists the complete set of equality and relational operators for <tt>pair</tt>
3680 but the section describing the template and the operators only describes
3681 <tt>operator==()</tt> and <tt>operator&lt;()</tt>, and it fails to mention
3682 any requirements on the template arguments. The remaining operators are
3683 not mentioned at all.
3684 </p>
3685
3686
3687 <p><b>Rationale:</b></p>
3688 <p>20.2.1 [operators] paragraph 10 already specifies the semantics.
3689 That paragraph says that, if declarations of operator!=, operator&gt;,
3690 operator&lt;=, and operator&gt;= appear without definitions, they are
3691 defined as specified in 20.2.1 [operators].  There should be no user
3692 confusion, since that paragraph happens to immediately precede the
3693 specification of <tt>pair</tt>.</p>
3694
3695
3696
3697
3698
3699 <hr>
3700 <h3><a name="302"></a>302. Need error indication from codecvt&lt;&gt;::do_length</h3>
3701 <p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3702  <b>Submitter:</b> Gregory Bumgardner <b>Date:</b> 2001-01-25</p>
3703 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
3704 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3705 <p><b>Discussion:</b></p>
3706 <p>
3707 The effects of <tt>codecvt&lt;&gt;::do_length()</tt> are described in
3708 22.2.1.5.2, paragraph 10.  As implied by that paragraph, and clarified
3709 in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <tt>codecvt&lt;&gt;::do_length()</tt> must
3710 process the source data and update the <tt>stateT</tt> argument just
3711 as if the data had been processed by <tt>codecvt&lt;&gt;::in()</tt>.
3712 However, the standard does not specify how <tt>do_length()</tt> would
3713 report a translation failure, should the source sequence contain
3714 untranslatable or illegal character sequences.
3715 </p>
3716
3717 <p>
3718 The other conversion methods return an "error" result value
3719 to indicate that an untranslatable character has been encountered, but
3720 <tt>do_length()</tt> already has a return value (the number of source
3721 characters that have been processed by the method).
3722 </p>
3723
3724
3725 <p><b>Proposed resolution:</b></p>
3726 <p>
3727 This issue cannot be resolved without modifying the interface. An exception
3728 cannot be used, as there would be no way to determine how many characters
3729 have been processed and the state object would be left in an indeterminate
3730 state.
3731 </p>
3732
3733 <p>
3734 A source compatible solution involves adding a fifth argument to length()
3735 and do_length() that could be used to return position of the offending
3736 character sequence. This argument would have a default value that would
3737 allow it to be ignored:
3738 </p>
3739
3740 <pre>  int length(stateT&amp; state,
3741              const externT* from,
3742              const externT* from_end,
3743              size_t max,
3744              const externT** from_next = 0);
3745
3746   virtual
3747   int do_length(stateT&amp; state,
3748                 const externT* from,
3749                 const externT* from_end,
3750                 size_t max,
3751                 const externT** from_next);
3752 </pre>
3753
3754 <p>
3755 Then an exception could be used to report any translation errors and
3756 the from_next argument, if used, could then be used to retrieve the
3757 location of the offending character sequence.
3758 </p>
3759
3760
3761 <p><b>Rationale:</b></p>
3762 <p>The standard is already clear: the return value is the number of
3763 "valid complete characters".  If it encounters an invalid sequence of
3764 external characters, it stops.</p>
3765
3766
3767
3768
3769
3770 <hr>
3771 <h3><a name="304"></a>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3>
3772 <p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3773  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-02-05</p>
3774 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
3775 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
3776 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3777 <p><b>Discussion:</b></p>
3778 <p>
3779 We all "know" that input iterators are allowed to produce
3780 values when dereferenced of which there is no other in-memory copy.
3781 </p>
3782
3783 <p>
3784 But: Table 72, with a careful reading, seems to imply that this can only be
3785 the case if the value_type has no members (e.g. is a built-in type).
3786 </p>
3787
3788 <p>The problem occurs in the following entry:</p>
3789
3790 <pre>  a-&gt;m     pre: (*a).m is well-defined
3791            Equivalent to (*a).m
3792 </pre>
3793
3794 <p>
3795 <tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
3796 type, but since <tt>operator-&gt;()</tt> must return a pointer for
3797 <tt>a-&gt;m</tt> to be well-formed, it needs something to return a
3798 pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
3799 buffered somewhere to make a legal input iterator.
3800 </p>
3801
3802 <p>I don't think this was intentional.</p>
3803
3804
3805 <p><b>Rationale:</b></p>
3806 <p>The current standard is clear and consistent.  Input iterators that
3807   return rvalues are in fact implementable.  They may in some cases
3808   require extra work, but it is still possible to define an operator-&gt;
3809   in such cases: it doesn't have to return a T*, but may return a
3810   proxy type.  No change to the standard is justified.</p>
3811
3812
3813
3814
3815
3816 <hr>
3817 <h3><a name="313"></a>313. set_terminate and set_unexpected question</h3>
3818 <p><b>Section:</b> 18.7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3819  <b>Submitter:</b> Judy Ward <b>Date:</b> 2001-04-03</p>
3820 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
3821 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3822 <p><b>Discussion:</b></p>
3823 <p>
3824 According to section 18.7.3.3 of the standard, std::terminate() is
3825 supposed to call the terminate_handler in effect immediately after
3826 evaluating the throw expression.
3827 </p>
3828
3829 <p>
3830 Question: what if the terminate_handler in effect is itself
3831 std::terminate?
3832 </p>
3833
3834 <p>For example:</p>
3835
3836 <pre>  #include &lt;exception&gt;
3837
3838   int main () {
3839       std::set_terminate(std::terminate);
3840       throw 5;
3841       return 0;
3842   }
3843 </pre>
3844
3845 <p>
3846 Is the implementation allowed to go into an infinite loop?
3847 </p>
3848
3849 <p>
3850 I think the same issue applies to std::set_unexpected.
3851 </p>
3852
3853
3854 <p><b>Proposed resolution:</b></p>
3855
3856
3857 <p><b>Rationale:</b></p>
3858 <p>Infinite recursion is to be expected: users who set the terminate
3859 handler to <tt>terminate</tt> are explicitly asking for <tt>terminate</tt>
3860 to call itself.</p>
3861
3862
3863
3864
3865
3866 <hr>
3867 <h3><a name="314"></a>314. Is the stack unwound when terminate() is called?</h3>
3868 <p><b>Section:</b> 18.7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3869  <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-04-11</p>
3870 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
3871 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3872 <p><b>Discussion:</b></p>
3873
3874 <p>
3875 The standard appears to contradict itself about whether the stack is
3876 unwound when the implementation calls terminate().
3877 </p>
3878
3879 <p>From 18.7.3.3p2:</p>
3880 <blockquote><p>
3881     Calls the terminate_handler function in effect immediately
3882     after evaluating the throw-expression (lib.terminate.handler),
3883     if called by the implementation [...]
3884 </p></blockquote>
3885
3886 <p>So the stack is guaranteed not to be unwound.</p>
3887
3888 <p>But from 15.3p9:</p>
3889 <blockquote><p>
3890     [...]whether or not the stack is unwound before this call
3891     to terminate() is implementation-defined (except.terminate).
3892 </p></blockquote>
3893
3894 <p>
3895 And 15.5.1 actually defines that in most cases the stack is unwound.
3896 </p>
3897
3898
3899 <p><b>Proposed resolution:</b></p>
3900
3901
3902 <p><b>Rationale:</b></p>
3903 <p>There is definitely no contradiction between the core and library
3904 clauses; nothing in the core clauses says that stack unwinding happens
3905 after <tt>terminate</tt> is called.  18.7.3.3p2 does not say anything
3906 about when terminate() is called; it merely specifies which
3907 <tt>terminate_handler</tt> is used.</p>
3908
3909
3910
3911
3912
3913 <hr>
3914 <h3><a name="323"></a>323. abs() overloads in different headers</h3>
3915 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
3916  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-04</p>
3917 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
3918 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
3919 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
3920 <p><b>Discussion:</b></p>
3921 <p>Currently the standard mandates the following overloads of
3922 abs():</p>
3923
3924 <pre>    abs(long), abs(int) in &lt;cstdlib&gt;
3925
3926     abs(float), abs(double), abs(long double) in &lt;cmath&gt;
3927
3928     template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp;) in &lt;complex&gt;
3929
3930     template&lt;class T&gt; valarray&lt;T&gt; abs(const valarray&lt;T&gt;&amp;); in &lt;valarray&gt;
3931 </pre>
3932
3933 <p>
3934 The problem is that having only some overloads visible of a function
3935 that works on "implicitly inter-convertible" types is dangerous in
3936 practice. The headers that get included at any point in a translation
3937 unit can change unpredictably during program
3938 development/maintenance. The wrong overload might be unintentionally
3939 selected.
3940 </p>
3941
3942 <p>
3943 Currently, there is nothing that mandates the simultaneous visibility
3944 of these overloads. Indeed, some vendors have begun fastidiously
3945 reducing dependencies among their (public) headers as a QOI issue: it
3946 helps people to write portable code by refusing to compile unless all
3947 the correct headers are #included.
3948 </p>
3949
3950 <p>The same issue may exist for other functions in the library.</p>
3951
3952 <p>Redmond: PJP reports that C99 adds two new kinds of abs: complex,
3953 and int_max_abs.</p>
3954
3955 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#343">343</a>.</p>
3956
3957
3958
3959 <p><b>Rationale:</b></p>
3960 <p>The programs that could potentially be broken by this situation are
3961   already fragile, and somewhat contrived: For example, a user-defined
3962   class that has conversion overloads both to <tt>long</tt> and
3963   to <tt>float</tt>.  If <tt>x</tt> is a value of such a class, then
3964   <tt>abs(x)</tt> would give the <tt>long</tt> version if the user
3965   included &lt;cstdlib&gt;, the <tt>float</tt> version if the user
3966   included &lt;cmath&gt;, and would be diagnosed as ambiguous at
3967   compile time if the user included both headers.  The LWG couldn't
3968   find an example of a program whose meaning would be changed (as
3969   opposed to changing it from well-formed to ill-formed) simply by
3970   adding another standard header.</p>
3971
3972 <p>Since the harm seems minimal, and there don't seem to be any simple
3973   and noninvasive solutions, this is being closed as NAD.  It is
3974   marked as "Future" for two reasons.  First, it might be useful to
3975   define an <tt>&lt;all&gt;</tt> header that would include all
3976   Standard Library headers.  Second, we should at least make sure that
3977   future library extensions don't make this problem worse.</p>
3978
3979
3980
3981
3982
3983 <hr>
3984 <h3><a name="326"></a>326. Missing typedef in moneypunct_byname</h3>
3985 <p><b>Section:</b> 22.2.6.4 [locale.moneypunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3986  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-05</p>
3987 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3988 <p><b>Discussion:</b></p>
3989 <p>The definition of the moneypunct facet contains the typedefs char_type
3990 and string_type. Only one of these names, string_type, is defined in
3991 the derived facet, moneypunct_byname.</p>
3992
3993
3994 <p><b>Proposed resolution:</b></p>
3995 <p>For consistency with the numpunct facet, add a typedef for
3996 char_type to the definition of the moneypunct_byname facet in
3997 22.2.6.4 [locale.moneypunct.byname].</p>
3998
3999
4000 <p><b>Rationale:</b></p>
4001 <p>The absence of the typedef is irrelevant.  Users can still access
4002 the typedef, because it is inherited from the base class.</p>
4003
4004
4005
4006
4007
4008 <hr>
4009 <h3><a name="330"></a>330. Misleading "exposition only" value in class locale definition</h3>
4010 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4011  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-15</p>
4012 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
4013 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4014 <p><b>Discussion:</b></p>
4015 <p>
4016 The "exposition only" value of the std::locale::none constant shown in
4017 the definition of class locale is misleading in that it on many
4018 systems conflicts with the value assigned to one if the LC_XXX
4019 constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE
4020 on Linux and SunOS). This causes incorrect behavior when such a
4021 constant is passed to one of the locale member functions that accept a
4022 locale::category argument and interpret it as either the C LC_XXX
4023 constant or a bitmap of locale::category values. At least three major
4024 implementations adopt the suggested value without a change and
4025 consequently suffer from this problem.
4026 </p>
4027
4028 <p>
4029 For instance, the following code will (presumably) incorrectly copy facets
4030 belonging to the collate category from the German locale on AIX:
4031 </p>
4032
4033 <pre>  std::locale l (std::locale ("C"), "de_DE", std::locale::none);
4034 </pre>
4035
4036
4037 <p><b>Rationale:</b></p>
4038 <p>The LWG agrees that it may be difficult to implement locale member
4039 functions in such a way that they can take either <tt>category</tt>
4040 arguments or the LC_ constants defined in &lt;cctype&gt;.  In light of
4041 this requirement (22.1.1.1.1 [locale.category], paragraph 2), and in light
4042 of the requirement in the preceding paragraph that it is possible to
4043 combine <tt>category</tt> bitmask elements with bitwise operations,
4044 defining the <tt>category</tt> elements is delicate,
4045 particularly if an implementor is constrained to work with a
4046 preexisting C library.  (Just using the existing LC_ constants would
4047 not work in general.)  There's no set of "exposition only" values that
4048 could give library implementors proper guidance in such a delicate
4049 matter.  The non-normative example we're giving is no worse than
4050 any other choice would be.</p>
4051
4052 <p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p>
4053
4054
4055
4056
4057
4058 <hr>
4059 <h3><a name="332"></a>332. Consider adding increment and decrement operators to std::fpos&lt; T &gt; </h3>
4060 <p><b>Section:</b> 27.4.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4061  <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</p>
4062 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
4063 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4064 <p><b>Discussion:</b></p>
4065 <p>
4066 Increment and decrement operators are missing from
4067 Table 88 -- Position type requirements in 27.4.3 [fpos].
4068 </p>
4069
4070
4071 <p><b>Proposed resolution:</b></p>
4072 <p>
4073 Table 88 (section 27.4.3) -- Position type requirements
4074 be updated to include increment and decrement operators.
4075 </p>
4076
4077 <pre>expression        return type     operational    note
4078
4079 ++p               fpos&amp;           p += O(1)
4080 p++               fpos            { P tmp = p;
4081                                     ++p;
4082                                     return tmp; }
4083 --p               fpos&amp;           p -= O(1)
4084 p--               fpos            { P tmp = p;
4085                                     --p;
4086                                     return tmp; }
4087 </pre>
4088
4089
4090
4091 <p><b>Rationale:</b></p>
4092 <p>The LWG believes this is a request for extension, not a defect
4093 report.  Additionally, nobody saw a clear need for this extension;
4094 <tt>fpos</tt> is used only in very limited ways.</p>
4095
4096
4097
4098
4099
4100 <hr>
4101 <h3><a name="344"></a>344. grouping + showbase</h3>
4102 <p><b>Section:</b> 22.2.2 [category.numeric] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4103  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-13</p>
4104 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4105 <p><b>Discussion:</b></p>
4106 <p>
4107 When both grouping and showbase are active and the basefield is octal,
4108 does the leading 0 participate in the grouping or not?  For example,
4109 should one format as: 0,123,456 or 0123,456?
4110 </p>
4111 <p>
4112 An analogy can be drawn with hexadecimal.  It appears that 0x123,456 is
4113 preferred over 0x,123,456.  However, this analogy is not universally
4114 accepted to apply to the octal base.  The standard is not clear on how
4115 to format (or parse) in this manner.
4116 </p>
4117
4118 <p><b>Proposed resolution:</b></p>
4119 <p>
4120 Insert into 22.2.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
4121 sentence:
4122 </p>
4123 <blockquote><p>
4124 The leading hexadecimal base specifier "0x" does not participate in
4125 grouping.  The leading '0' octal base specifier may participate in
4126 grouping.  It is unspecified if the leading '0' participates in
4127 formatting octal numbers.  In parsing octal numbers, the implementation
4128 is encouraged to accept both the leading '0' participating in the
4129 grouping, and not participating (e.g. 0123,456 or 0,123,456).
4130 </p></blockquote>
4131
4132 <p><b>Rationale:</b></p>
4133 <p>
4134 The current behavior may be unspecified, but it's not clear that it
4135 matters.  This is an obscure corner case, since grouping is usually
4136 intended for the benefit of humans and oct/hex prefixes are usually
4137 intended for the benefit of machines.  There is not a strong enough
4138 consensus in the LWG for action.
4139 </p>
4140
4141
4142
4143
4144 <hr>
4145 <h3><a name="348"></a>348. Minor issue with std::pair operator&lt;</h3>
4146 <p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
4147  <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-23</p>
4148 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
4149 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
4150 <p><b>Discussion:</b></p>
4151 <p>
4152 The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
4153 operator&lt; on any pair type which contains a pointer.
4154 </p>
4155
4156
4157 <p><b>Proposed resolution:</b></p>
4158 <p>In 20.2.3 [pairs] paragraph 6, replace:</p>
4159 <pre>    Returns: x.first &lt; y.first || (!(y.first &lt; x.first) &amp;&amp; x.second &lt;
4160         y.second).
4161 </pre>
4162 <p>With:</p>
4163 <pre>    Returns: std::less&lt;T1&gt;()( x.first, y.first ) ||
4164              (!std::less&lt;T1&gt;()( y.first, x.first) &amp;&amp;
4165              std::less&lt;T2&gt;()( x.second, y.second ) )
4166 </pre>
4167
4168
4169
4170 <p><b>Rationale:</b></p>
4171 <p>This is an instance of a much more general problem.  If we want
4172   operator&lt; to translate to std::less for pairs of pointers, where
4173   do we draw the line?  The same issue applies to individual
4174   pointers, smart pointer wrappers, std::vector&lt;T*&gt;, and so
4175   on.</p>
4176
4177 <p>Andy Koenig suggests that the real issue here is that we aren't
4178   distinguishing adequately between two different orderings, a
4179   "useful ordering" and a "canonical ordering" that's used just
4180   because we sometimes need <i>some</i> ordering without caring much
4181   which ordering it is.  Another example of the later is typeinfo's
4182   <tt>before</tt>.</p>
4183
4184
4185
4186
4187
4188
4189 <hr>
4190 <h3><a name="350"></a>350. allocator&lt;&gt;::address</h3>
4191 <p><b>Section:</b> 20.6.1.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
4192  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2001-10-25</p>
4193 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
4194 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
4195 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#634">634</a></p>
4196 <p><b>Discussion:</b></p>
4197 <p>See c++std-lib-9006 and c++std-lib-9007.  This issue is taken
4198 verbatim from -9007.</p>
4199
4200 <p>
4201 The core language feature allowing definition of operator&amp;() applied
4202 to any non-builtin type makes that operator often unsafe to use in
4203 implementing libraries, including the Standard Library.  The result
4204 is that many library facilities fail for legal user code, such as
4205 the fragment</p>
4206 <pre>  class A { private: A* operator&amp;(); };
4207   std::vector&lt;A&gt; aa;
4208
4209   class B { };
4210   B* operator&amp;(B&amp;) { return 0; }
4211   std::vector&lt;B&gt; ba;
4212 </pre>
4213
4214 <p>
4215 In particular, the requirements table for Allocator (Table 32) specifies
4216 no semantics at all for member address(), and allocator&lt;&gt;::address is
4217 defined in terms of unadorned operator &amp;.
4218 </p>
4219
4220
4221
4222 <p><b>Proposed resolution:</b></p>
4223 <p>
4224 In 20.6.1.1, Change the definition of allocator&lt;&gt;::address from:</p>
4225 <blockquote><p>
4226   Returns: &amp;x
4227 </p></blockquote>
4228
4229 <p>to:</p>
4230
4231 <p>
4232   Returns: The value that the built in operator&amp;(x) would return if not
4233   overloaded.
4234 </p>
4235
4236 <p>
4237 In 20.1.6, Table 32, add to the Notes column of the a.address(r) and
4238 a.address(s) lines, respectively:
4239 </p>
4240
4241 <pre>  allocator&lt;T&gt;::address(r)
4242   allocator&lt;T&gt;::address(s)
4243 </pre>
4244
4245 <p>In addition, in clause 17.4.1.1, add a statement:</p>
4246
4247 <blockquote><p>
4248  The Standard Library does not apply operator&amp; to any type for which
4249  operator&amp; may be overloaded.
4250 </p></blockquote>
4251
4252
4253
4254 <p><b>Rationale:</b></p>
4255 <p>The LWG believes both examples are ill-formed.  The contained type
4256 is required to be CopyConstructible (20.1.1 [utility.arg.requirements]), and that
4257 includes the requirement that &amp;t return the usual types and
4258 values. Since allocators are intended to be used in conjunction with
4259 containers, and since the CopyConstructible requirements appear to
4260 have been written to deal with the concerns of this issue, the LWG
4261 feels it is NAD unless someone can come up with a well-formed example
4262 exhibiting a problem.</p>
4263
4264 <p>It may well be that the CopyConstructible requirements are too
4265   restrictive and that either the container requirements or the
4266   CopyConstructive requirements should be relaxed, but that's a far
4267   larger issue.  Marking this issue as "future" as a pointer to that
4268   larger issue.</p>
4269
4270
4271
4272
4273
4274 <hr>
4275 <h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3>
4276 <p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
4277  <b>Submitter:</b> Dale Riley <b>Date:</b> 2001-11-12</p>
4278 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#function.objects">active issues</a> in [function.objects].</p>
4279 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
4280 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
4281 <p><b>Discussion:</b></p>
4282 <p>
4283 In 20.5 [function.objects] the header &lt;functional&gt; synopsis declares
4284 the unary_negate and binary_negate function objects as struct.
4285 However in 20.5.9 [negators] the unary_negate and binary_negate
4286 function objects are defined as class.  Given the context, they are
4287 not "basic function objects" like negate, so this is either a typo or
4288 an editorial oversight.
4289 </p>
4290
4291 <p><i>[Taken from comp.std.c++]</i></p>
4292
4293
4294
4295 <p><b>Proposed resolution:</b></p>
4296 <p>Change the synopsis to reflect the useage in 20.5.9 [negators]</p>
4297
4298 <p><i>[Curaçao: Since the language permits "struct", the LWG
4299 views this as NAD. They suggest, however, that the Project Editor
4300 might wish to make the change as editorial.]</i></p>
4301
4302
4303
4304
4305
4306
4307
4308 <hr>
4309 <h3><a name="353"></a>353. <tt>std::pair</tt> missing template assignment</h3>
4310 <p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
4311  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</p>
4312 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
4313 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
4314 <p><b>Discussion:</b></p>
4315 <p>
4316 The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but
4317 no template assignment operator. This may lead to inefficient code since
4318 assigning an object of <tt>pair&lt;C, D&gt;</tt> to <tt>pair&lt;A, B&gt;</tt>
4319 where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to
4320 <tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy
4321 ctor to construct an unnamed temporary of type <tt>pair&lt;A, B&gt;</tt>
4322 followed by an ordinary (perhaps implicitly defined) assignment operator,
4323 instead of just a straight assignment.
4324 </p>
4325
4326
4327 <p><b>Proposed resolution:</b></p>
4328 <p>
4329 Add the following declaration to the definition of <tt>std::pair</tt>:
4330 </p>
4331 <pre>    template&lt;class U, class V&gt;
4332     pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
4333 </pre>
4334 <p>
4335 And also add a paragraph describing the effects of the function template to the
4336 end of 20.2.2:
4337 </p>
4338 <pre>    template&lt;class U, class V&gt;
4339     pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
4340 </pre>
4341 <p>
4342     <b>Effects</b>: <tt>first = p.first;</tt>
4343                     <tt>second = p.second;</tt>
4344     <b>Returns</b>: <tt>*this</tt>
4345 </p>
4346
4347 <p><i>[Curaçao: There is no indication this is was anything other than
4348 a design decision, and thus NAD.&nbsp; May be appropriate for a future
4349 standard.]</i></p>
4350
4351
4352
4353
4354
4355
4356 <hr>
4357 <h3><a name="356"></a>356. Meaning of ctype_base::mask enumerators</h3>
4358 <p><b>Section:</b> 22.2.1 [category.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4359  <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-01-23</p>
4360 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</p>
4361 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4362 <p><b>Discussion:</b></p>
4363
4364 <p>What should the following program print?</p>
4365
4366 <pre>  #include &lt;locale&gt;
4367   #include &lt;iostream&gt;
4368
4369   class my_ctype : public std::ctype&lt;char&gt;
4370   {
4371     typedef std::ctype&lt;char&gt; base;
4372   public:
4373     my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
4374     {
4375       std::copy(base::classic_table(), base::classic_table() + base::table_size,
4376                 my_table);
4377       my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
4378     }
4379   private:
4380     mask my_table[base::table_size];
4381   };
4382
4383   int main()
4384   {
4385     my_ctype ct;
4386     std::cout &lt;&lt; "isspace: " &lt;&lt; ct.is(std::ctype_base::space, '_') &lt;&lt; "    "
4387               &lt;&lt; "isalpha: " &lt;&lt; ct.is(std::ctype_base::alpha, '_') &lt;&lt; std::endl;
4388   }
4389 </pre>
4390
4391 <p>The goal is to create a facet where '_' is treated as whitespace.</p>
4392
4393 <p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0".  On
4394 Microsoft C++ it prints "isspace: 1 isalpha: 1".</p>
4395
4396 <p>
4397 I believe that both implementations are legal, and the standard does not
4398 give enough guidance for users to be able to use std::ctype's
4399 protected interface portably.</p>
4400
4401 <p>
4402 The above program assumes that ctype_base::mask enumerators like
4403 <tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
4404 say that a character is both a space and a printing character is to or
4405 those two enumerators together.  This is suggested by the "exposition
4406 only" values in 22.2.1 [category.ctype], but it is nowhere specified in
4407 normative text.  An alternative interpretation is that the more
4408 specific categories subsume the less specific.  The above program
4409 gives the results it does on the Microsoft compiler because, on that
4410 compiler, <tt>print</tt> has all the bits set for each specific
4411 printing character class.
4412 </p>
4413
4414 <p>From the point of view of std::ctype's public interface, there's no
4415 important difference between these two techniques.  From the point of
4416 view of the protected interface, there is.  If I'm defining a facet
4417 that inherits from std::ctype&lt;char&gt;, I'm the one who defines the
4418 value that table()['a'] returns.  I need to know what combination of
4419 mask values I should use.  This isn't so very esoteric: it's exactly
4420 why std::ctype has a protected interface.  If we care about users
4421 being able to write their own ctype facets, we have to give them a
4422 portable way to do it.
4423 </p>
4424
4425 <p>
4426 Related reflector messages:
4427 lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
4428 lib-9277, lib-9279.
4429 </p>
4430
4431 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical.  The
4432 proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that
4433 ctype_base::mask must be a bitmask type. It does not say that the
4434 ctype_base::mask elements are bitmask elements, so it doesn't
4435 directly affect this issue.</p>
4436
4437 <p>More comments from Benjamin Kosnik, who believes that
4438 that C99 compatibility essentially requires what we're
4439 calling option 1 below.</p>
4440
4441 <blockquote>
4442 <pre>I think the C99 standard is clear, that isspace -&gt; !isalpha.
4443 --------
4444
4445 #include &lt;locale&gt;
4446 #include &lt;iostream&gt;
4447
4448 class my_ctype : public std::ctype&lt;char&gt;
4449 {
4450 private:
4451   typedef std::ctype&lt;char&gt; base;
4452   mask my_table[base::table_size];
4453
4454 public:
4455   my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
4456   {
4457     std::copy(base::classic_table(), base::classic_table() + base::table_size,
4458               my_table);
4459     mask both = base::print | base::space;
4460     my_table[static_cast&lt;mask&gt;('_')] = both;
4461   }
4462 };
4463
4464 int main()
4465 {
4466   using namespace std;
4467   my_ctype ct;
4468   cout &lt;&lt; "isspace: " &lt;&lt; ct.is(ctype_base::space, '_') &lt;&lt; endl;
4469   cout &lt;&lt; "isprint: " &lt;&lt; ct.is(ctype_base::print, '_') &lt;&lt; endl;
4470
4471   // ISO C99, isalpha iff upper | lower set, and !space.
4472   // 7.5, p 193
4473   // -&gt; looks like g++ behavior is correct.
4474   // 356 -&gt; bitmask elements are required for ctype_base
4475   // 339 -&gt; bitmask type required for mask
4476   cout &lt;&lt; "isalpha: " &lt;&lt; ct.is(ctype_base::alpha, '_') &lt;&lt; endl;
4477 }
4478 </pre>
4479 </blockquote>
4480
4481
4482
4483 <p><b>Proposed resolution:</b></p>
4484 <p>Informally, we have three choices:</p>
4485 <ol>
4486 <li>Require that the enumerators are disjoint (except for alnum and
4487 graph)</li>
4488 <li>Require that the enumerators are not disjoint, and specify which
4489 of them subsume which others.  (e.g. mandate that lower includes alpha
4490 and print)</li>
4491 <li>Explicitly leave this unspecified, which the result that the above
4492 program is not portable.</li>
4493 </ol>
4494
4495 <p>Either of the first two options is just as good from the standpoint
4496 of portability.  Either one will require some implementations to
4497 change.</p>
4498
4499
4500 <p><b>Rationale:</b></p>
4501 <p>The LWG agrees that this is a real ambiguity, and that both
4502 interpretations are conforming under the existing standard. However,
4503 there's no evidence that it's causing problems for real users. Users
4504 who want to define ctype facets portably can test the ctype_base masks
4505 to see which interpretation is being used.</p>
4506
4507
4508
4509
4510
4511 <hr>
4512 <h3><a name="357"></a>357. &lt;cmath&gt; float functions cannot return HUGE_VAL</h3>
4513 <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
4514  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-02-26</p>
4515 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
4516 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
4517 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
4518 <p><b>Discussion:</b></p>
4519 <p>
4520 The float versions of the math functions have no meaningful value to return
4521 for a range error. The long double versions have a value they can return,
4522 but it isn't necessarily the most reasonable value.
4523 </p>
4524
4525 <p>
4526 Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long
4527 double overloaded versions of these functions, with the same semantics,"
4528 referring to the math functions from the C90 standard.
4529 </p>
4530
4531 <p>
4532 The C90 standard, in section 7.5.1, paragraph 3, says that functions return
4533 "the value of the macro HUGE_VAL" when they encounter a range error.
4534 Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a
4535 positive double expression, not necessarily representable as a float."
4536 </p>
4537
4538 <p>
4539 Therefore, the float versions of the math functions have no way to
4540 signal a range error. <i>[Curaçao: The LWG notes that this isn't
4541 strictly correct, since errno is set.]</i> The semantics require that they
4542 return HUGE_VAL, but they cannot because HUGE_VAL might not be
4543 representable as a float.
4544 </p>
4545
4546 <p>
4547 The problem with long double functions is less severe because HUGE_VAL is
4548 representable as a long double. On the other hand, it might not be a "huge"
4549 long double value, and might fall well within the range of normal return
4550 values for a long double function. Therefore, it does not make sense for a
4551 long double function to return a double (HUGE_VAL) for a range error.
4552 </p>
4553
4554
4555 <p><b>Proposed resolution:</b></p>
4556 <p>Curaçao: C99 was faced with a similar problem, which they fixed by
4557 adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p>
4558
4559 <p>C++ must also fix, but it should be done in the context of the
4560 general C99 based changes to C++, not via DR. Thus the LWG in Curaçao
4561 felt the resolution should be NAD, FUTURE, but the issue is being held
4562 open for one more meeting to ensure LWG members not present during the
4563 discussion concur.</p>
4564
4565
4566 <p><b>Rationale:</b></p>
4567 <p>Will be fixed as part of more general work in the TR.</p>
4568
4569
4570
4571
4572
4573 <hr>
4574 <h3><a name="361"></a>361. num_get&lt;&gt;::do_get (..., void*&amp;) checks grouping</h3>
4575 <p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4576  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
4577 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
4578 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4579 <p><b>Discussion:</b></p>
4580 <p>
4581 22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only
4582 for integral types (issue 282 suggests that this should be done for
4583 all arithmetic types).
4584 </p>
4585
4586 <p>
4587 22.2.2.1.2, p12 requires that grouping be checked for all extractors
4588 including that for <tt>void*</tt>.
4589 </p>
4590
4591 <p>
4592 I don't think that's right. <tt>void*</tt> values should not be checked for
4593 grouping, should they? (Although if they should, then <tt>num_put</tt> needs
4594 to write them out, otherwise their extraction will fail.)
4595 </p>
4596
4597
4598 <p><b>Proposed resolution:</b></p>
4599 <p>
4600 Change the first sentence of 22.2.2.2.2, p12 from
4601 </p>
4602 <blockquote><p>
4603     Digit grouping is checked. That is, the positions of discarded
4604     separators is examined for consistency with
4605     use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().
4606     If they are not consistent then ios_base::failbit is assigned
4607     to err.
4608 </p></blockquote>
4609
4610 <p>to</p>
4611 <blockquote><p>
4612     Except for conversions to void*, digit grouping is checked...
4613 </p></blockquote>
4614
4615
4616
4617 <p><b>Rationale:</b></p>
4618 <p>This would be a change: as it stands, the standard clearly
4619   specifies that grouping applies to void*.  A survey of existing
4620   practice shows that most existing implementations do that, as they
4621   should.</p>
4622
4623
4624
4625
4626
4627 <hr>
4628 <h3><a name="366"></a>366. Excessive const-qualification</h3>
4629 <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4630  <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
4631 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
4632 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4633 <p><b>Discussion:</b></p>
4634 <p>
4635 The following member functions are declared const, yet return non-const
4636 pointers. We believe they are should be changed, because they allow code
4637 that may surprise the user. See document N1360 for details and
4638 rationale.
4639 </p>
4640
4641 <p><i>[Santa Cruz: the real issue is that we've got const member
4642 functions that return pointers to non-const, and N1360 proposes
4643 replacing them by overloaded pairs.  There isn't a consensus about
4644 whether this is a real issue, since we've never said what our
4645 constness policy is for iostreams.  N1360 relies on a distinction
4646 between physical constness and logical constness; that distinction, or
4647 those terms, does not appear in the standard.]</i></p>
4648
4649
4650
4651
4652 <p><b>Proposed resolution:</b></p>
4653 <p>In 27.4.4 and 27.4.4.2</p>
4654 <p>Replace</p>
4655 <pre>  basic_ostream&lt;charT,traits&gt;* tie() const;
4656 </pre>
4657 <p>with</p>
4658 <pre>  basic_ostream&lt;charT,traits&gt;* tie();
4659   const basic_ostream&lt;charT,traits&gt;* tie() const;
4660 </pre>
4661
4662 <p>and replace</p>
4663 <pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
4664 </pre>
4665 <p>with</p>
4666 <pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf();
4667   const basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
4668 </pre>
4669
4670 <p>In 27.5.2 and 27.5.2.3.1</p>
4671 <p>Replace</p>
4672 <pre>  char_type* eback() const;
4673 </pre>
4674 <p>with</p>
4675 <pre>  char_type* eback();
4676   const char_type* eback() const;
4677 </pre>
4678
4679 <p>Replace</p>
4680 <pre>  char_type gptr() const;
4681 </pre>
4682 <p>with</p>
4683 <pre>  char_type* gptr();
4684   const char_type* gptr() const;
4685 </pre>
4686
4687 <p>Replace</p>
4688 <pre>  char_type* egptr() const;
4689 </pre>
4690 <p>with</p>
4691 <pre>  char_type* egptr();
4692   const char_type* egptr() const;
4693 </pre>
4694
4695 <p>In 27.5.2 and 27.5.2.3.2</p>
4696 <p>Replace</p>
4697 <pre>  char_type* pbase() const;
4698 </pre>
4699 <p>with</p>
4700 <pre>  char_type* pbase();
4701   const char_type* pbase() const;
4702 </pre>
4703
4704 <p>Replace</p>
4705 <pre>  char_type* pptr() const;
4706 </pre>
4707 <p>with</p>
4708 <pre>  char_type* pptr();
4709   const char_type* pptr() const;
4710 </pre>
4711
4712 <p>Replace</p>
4713 <pre>  char_type* epptr() const;
4714 </pre>
4715 <p>with</p>
4716 <pre>  char_type* epptr();
4717   const char_type* epptr() const;
4718 </pre>
4719
4720 <p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
4721 <p>Replace</p>
4722 <pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
4723 </pre>
4724 <p>with</p>
4725 <pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf();
4726   const basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
4727 </pre>
4728
4729 <p>In  27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
4730 <p>Replace</p>
4731 <pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
4732 </pre>
4733 <p>with</p>
4734 <pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf();
4735   const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
4736 </pre>
4737
4738
4739 <p><b>Rationale:</b></p>
4740 <p>The existing specification is a bit sloppy, but there's no
4741   particular reason to change this other than tidiness, and there are
4742   a number of ways in which streams might have been designed
4743   differently if we were starting today.  There's no evidence that the
4744   existing constness policy is harming users.  We might consider
4745   a different constness policy as part of a full stream redesign.</p>
4746
4747
4748
4749
4750
4751 <hr>
4752 <h3><a name="367"></a>367. remove_copy/remove_copy_if and Input Iterators</h3>
4753 <p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4754  <b>Submitter:</b> Anthony Williams <b>Date:</b> 2002-05-13</p>
4755 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
4756 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4757 <p><b>Discussion:</b></p>
4758 <p>
4759 remove_copy and remove_copy_if (25.2.8 [alg.remove]) permit their
4760 input range to be marked with Input Iterators. However, since two
4761 operations are required against the elements to copy (comparison and
4762 assigment), when the input range uses Input Iterators, a temporary
4763 copy must be taken to avoid dereferencing the iterator twice. This
4764 therefore requires the value type of the InputIterator to be
4765 CopyConstructible. If the iterators are at least Forward Iterators,
4766 then the iterator can be dereferenced twice, or a reference to the
4767 result maintained, so the temporary is not required.
4768 </p>
4769
4770
4771 <p><b>Proposed resolution:</b></p>
4772 <p>
4773 Add "If InputIterator does not meet the requirements of forward
4774 iterator, then the value type of InputIterator must be copy
4775 constructible. Otherwise copy constructible is not required." to
4776 25.2.8 [alg.remove] paragraph 6.
4777 </p>
4778
4779
4780 <p><b>Rationale:</b></p>
4781 <p>The assumption is that an input iterator can't be dereferenced
4782   twice.  There's no basis for that assumption in the Standard.</p>
4783
4784
4785
4786
4787
4788 <hr>
4789 <h3><a name="368"></a>368. basic_string::replace has two "Throws" paragraphs</h3>
4790 <p><b>Section:</b> 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
4791  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2002-06-03</p>
4792 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
4793 <p><b>Discussion:</b></p>
4794 <p>
4795 21.3.6.6 [string::replace] basic_string::replace, second
4796 signature, given in paragraph 1, has two "Throws" paragraphs (3 and
4797 5).
4798 </p>
4799
4800 <p>
4801 In addition, the second "Throws" paragraph (5) includes specification
4802 (beginning with "Otherwise, the function replaces ...") that should be
4803 part of the "Effects" paragraph.
4804 </p>
4805
4806
4807 <p><b>Proposed resolution:</b></p>
4808
4809
4810 <p><b>Rationale:</b></p>
4811 <p>This is editorial. Both "throws" statements are true. The bug is
4812   just that the second one should be a sentence, part of the "Effects"
4813   clause, not a separate "Throws".  The project editor has been
4814   notified.</p>
4815
4816
4817
4818
4819
4820 <hr>
4821 <h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3>
4822 <p><b>Section:</b> 17.4.4.8 [res.on.exception.handling], 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4823  <b>Submitter:</b> Randy Maddox <b>Date:</b> 2002-07-22</p>
4824 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
4825 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4826 <p><b>Discussion:</b></p>
4827
4828 <p>Paragraph 3 under clause 17.4.4.8 [res.on.exception.handling], Restrictions on
4829 Exception Handling, states that "Any other functions defined in the
4830 C++ Standard Library that do not have an exception-specification may
4831 throw implementation-defined exceptions unless otherwise specified."
4832 This statement is followed by a reference to footnote 178 at the
4833 bottom of that page which states, apparently in reference to the C++
4834 Standard Library, that "Library implementations are encouraged (but
4835 not required) to report errors by throwing exceptions from (or derived
4836 from) the standard exceptions."</p>
4837
4838 <p>These statements appear to be in direct contradiction to clause
4839 18.6.1 [type.info], which states "The class exception defines the
4840 base class for the types of objects thrown as exceptions by the C++
4841 Standard library components ...".</p>
4842
4843 <p>Is this inconsistent?</p>
4844
4845
4846
4847 <p><b>Proposed resolution:</b></p>
4848
4849
4850 <p><b>Rationale:</b></p>
4851 <p>Clause 17 is setting the overall library requirements, and it's
4852   clear and consistent.  This sentence from Clause 18 is descriptive,
4853   not setting a requirement on any other class.
4854 </p>
4855
4856
4857
4858
4859
4860 <hr>
4861 <h3><a name="374"></a>374. moneypunct::frac_digits returns int not unsigned</h3>
4862 <p><b>Section:</b> 22.2.6.3.1 [locale.moneypunct.members], 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4863  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-08</p>
4864 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4865 <p><b>Discussion:</b></p>
4866 <p>
4867 In section 22.2.6.3.1 [locale.moneypunct.members], frac_digits() returns type
4868 "int". This implies that frac_digits() might return a negative value,
4869 but a negative value is nonsensical. It should return "unsigned".
4870 </p>
4871
4872 <p>
4873 Similarly, in section 22.2.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
4874 should return "unsigned".
4875 </p>
4876
4877
4878
4879 <p><b>Proposed resolution:</b></p>
4880
4881
4882 <p><b>Rationale:</b></p>
4883 <p>Regardless of whether the return value is int or unsigned, it's
4884 always conceivable that frac_digits might return a nonsensical
4885 value. (Is 4294967295 really any better than -1?)  The clients of
4886 moneypunct, the get and put facets, can and do perform range
4887 checks.</p>
4888
4889
4890
4891
4892
4893 <hr>
4894 <h3><a name="377"></a>377. basic_string::insert and length_error</h3>
4895 <p><b>Section:</b> 21.3.6.4 [string::insert] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4896  <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-16</p>
4897 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
4898 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4899 <p><b>Discussion:</b></p>
4900 <p>
4901 Section 21.3.6.4 [string::insert], paragraph 4, contains the following,
4902 "Then throws length_error if size() &gt;= npos - rlen."
4903 </p>
4904
4905 <p>
4906 Related to DR 83, this sentence should probably be removed.
4907 </p>
4908
4909
4910 <p><b>Proposed resolution:</b></p>
4911
4912
4913 <p><b>Rationale:</b></p><p>This requirement is redundant but correct.  No change is
4914 needed.</p>
4915
4916
4917
4918
4919 <hr>
4920 <h3><a name="378"></a>378. locale immutability and locale::operator=()</h3>
4921 <p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
4922  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
4923 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
4924 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
4925 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a></p>
4926 <p><b>Discussion:</b></p>
4927 <p>
4928 I think there is a problem with 22.1.1, p6 which says that
4929 </p>
4930 <pre>    -6- An instance of locale is immutable; once a facet reference
4931         is obtained from it, that reference remains usable as long
4932         as the locale value itself exists.
4933 </pre>
4934 <p>
4935 and 22.1.1.2, p4:
4936 </p>
4937 <pre>    const locale&amp; operator=(const locale&amp; other) throw();
4938
4939     -4- Effects: Creates a copy of other, replacing the current value.
4940 </pre>
4941 <p>
4942 How can a reference to a facet obtained from a locale object remain
4943 valid after an assignment that clearly must replace all the facets
4944 in the locale object? Imagine a program such as this
4945 </p>
4946 <pre>    std::locale loc ("de_DE");
4947     const std::ctype&lt;char&gt; &amp;r0 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
4948     loc = std::locale ("en_US");
4949     const std::ctype&lt;char&gt; &amp;r1 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
4950 </pre>
4951 <p>
4952 Is r0 really supposed to be preserved and destroyed only when loc goes
4953 out of scope?
4954 </p>
4955
4956
4957 <p><b>Proposed resolution:</b></p>
4958 <p><i>[Summer '04 mid-meeting mailing: Martin and Dietmar believe this
4959   is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a> and recommend that it be
4960   closed.
4961 ]</i></p>
4962
4963
4964
4965
4966
4967
4968 <hr>
4969 <h3><a name="385"></a>385. Does call by value imply the CopyConstructible requirement?</h3>
4970 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4971  <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</p>
4972 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
4973 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4974 <p><b>Discussion:</b></p>
4975 <p>
4976 Many function templates have parameters that are passed by value;
4977 a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
4978 25.1.2 [alg.find].  Are the corresponding template parameters
4979 (<tt>Predicate</tt> in this case) implicitly required to be
4980 CopyConstructible, or does that need to be spelled out explicitly?
4981 </p>
4982
4983 <p>
4984 This isn't quite as silly a question as it might seem to be at first
4985 sight.  If you call <tt>find_if</tt> in such a way that template
4986 argument deduction applies, then of course you'll get call by value
4987 and you need to provide a copy constructor.  If you explicitly provide
4988 the template arguments, however, you can force call by reference by
4989 writing something like <tt>find_if&lt;my_iterator,
4990 my_predicate&amp;&gt;</tt>.  The question is whether implementation
4991 are required to accept this, or whether this is ill-formed because
4992 my_predicate&amp; is not CopyConstructible.
4993 </p>
4994
4995 <p>
4996 The scope of this problem, if it is a problem, is unknown.  Function
4997 object arguments to generic algorithms in clauses 25 [algorithms]
4998 and 26 [numerics] are obvious examples.  A review of the whole
4999 library is necessary.
5000 </p>
5001 <p><i>[
5002 This is really two issues.  First, predicates are typically passed by
5003 value but we don't say they must be Copy Constructible.  They should
5004 be. Second: is specialization allowed to transform value arguments
5005 into references? References aren't copy constructible, so this should
5006 not be allowed.
5007 ]</i></p>
5008
5009 <p><i>[
5010 2007-01-12, Howard: First, despite the note above, references <b>are</b>
5011 copy constructible. They just aren't assignable.  Second, this is very
5012 closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> and should be consistent with that.
5013 That issue already says that implementations are allowed to copy
5014 function objects.  If one passes in a reference, it is copyable, but
5015 susceptible to slicing if one passes in a reference to a base.  Third,
5016 with rvalue reference in the language one only needs to satisfy
5017 MoveConstructible to pass an rvalue "by value".  Though the function
5018 might still copy the function object internally (requiring
5019 CopyConstructible). Finally (and fwiw), if we wanted to, it is easy to
5020 code all of the std::algorithms such that they do not copy function
5021 objects internally.  One merely passes them by reference internally if
5022 desired (this has been fully implemented and shipped for several years).
5023  If this were mandated, it would reverse <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, allowing
5024 function objects to reliably maintain state.  E.g. the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> would reliably remove only the third element.
5025 ]</i></p>
5026
5027
5028
5029 <p><b>Proposed resolution:</b></p>
5030 <p>
5031 Recommend NAD.
5032 </p>
5033
5034
5035 <p><b>Rationale:</b></p>
5036 <p>
5037 Generic algorithms will be marked with concepts and these will imply a requirement
5038 of MoveConstructible (not CopyConstructible).  The signature of the function will
5039 then precisely describe and enforce the precise requirements.
5040 </p>
5041
5042
5043
5044
5045
5046 <hr>
5047 <h3><a name="388"></a>388. Use of complex as a key in associative containers</h3>
5048 <p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
5049  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
5050 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.numbers">active issues</a> in [complex.numbers].</p>
5051 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
5052 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
5053 <p><b>Discussion:</b></p>
5054 <p>
5055 Practice with std::complex&lt;&gt; and the associative containers
5056 occasionally reveals artificial and distracting issues with constructs
5057 resembling: std::set&lt;std::complex&lt;double&gt; &gt; s;
5058 </p>
5059
5060 <p>
5061 The main reason for the above to fail is the absence of an approriate
5062 definition for std::less&lt;std::complex&lt;T&gt; &gt;. That in turn comes from
5063 the definition of the primary template std::less&lt;&gt; in terms of
5064 operator&lt;.
5065 </p>
5066
5067 <p>
5068 The usual argument goes as follows: Since there is no ordering over
5069 the complex field compatible with field operations it makes little
5070 sense to define a function operator&lt; operating on the datatype
5071 std::complex&lt;T&gt;.  That is fine. However, that reasoning does not carry
5072 over to std::less&lt;T&gt; which is used, among other things, by associative
5073 containers as an ordering useful to meet complexity requirements.
5074 </p>
5075
5076 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p>
5077
5078
5079
5080 <p><b>Proposed resolution:</b></p>
5081 <p>Informally: Add a specialization of std::less for std::complex.</p>
5082
5083
5084 <p><b>Rationale:</b></p>
5085 <p>Discussed in Santa Cruz.  An overwhelming majority of the LWG
5086 believes this should not be treated a DR: it's a request for a design
5087 change, not a defect in the existing standard.  Most people (10-3)
5088 believed that we probably don't want this change, period: as with
5089 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, it's hard to know where to draw the line.
5090 The LWG noted that users who want to put objects into an associative
5091 container for which <tt>operator&lt;</tt> isn't defined can simply
5092 provide their own comparison function object.</p>
5093
5094
5095
5096
5097
5098 <hr>
5099 <h3><a name="390"></a>390. CopyConstructible requirements too strict</h3>
5100 <p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
5101  <b>Submitter:</b> Doug Gregor <b>Date:</b> 2002-10-24</p>
5102 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
5103 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
5104 <p><b>Discussion:</b></p>
5105 <p>
5106 The CopyConstructible requirements in Table 30 state that for an
5107 object t of type T (where T is CopyConstructible), the expression &amp;t
5108 returns the address of t (with type T*). This requirement is overly
5109 strict, in that it disallows types that overload operator&amp; to not
5110 return a value of type T*. This occurs, for instance, in the <a href="http://www.boost.org/libs/lambda">Boost.Lambda</a> library, where
5111 operator&amp; is overloaded for a Boost.Lambda function object to return
5112 another function object.
5113 </p>
5114
5115 <p>Example:</p>
5116
5117 <pre>  std::vector&lt;int&gt; u, v;
5118   int x;
5119   // ...
5120   std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
5121 </pre>
5122
5123 <p>
5124 _1 * x returns an unnamed function object with operator&amp; overloaded to
5125 not return T* , therefore rendering the std::transform call ill-formed.
5126 However, most standard library implementations will compile this code
5127 properly, and the viability of such binder libraries is severely hindered
5128 by the unnecessary restriction in the CopyConstructible requirements.
5129 </p>
5130
5131 <p>
5132 For reference, the address of an object can be retrieved without using
5133 the address-of operator with the following function template:
5134 </p>
5135
5136 <pre>  template &lt;typename T&gt; T* addressof(T&amp; v)
5137   {
5138     return reinterpret_cast&lt;T*&gt;(
5139          &amp;const_cast&lt;char&amp;&gt;(reinterpret_cast&lt;const volatile char &amp;&gt;(v)));
5140   }
5141 </pre>
5142
5143 <p>
5144 Note: this relates directly to library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, which
5145 will need to be reexamined if the CopyConstructible requirements
5146 change.
5147 </p>
5148
5149
5150 <p><b>Proposed resolution:</b></p>
5151 <p>
5152 Remove the last two rows of Table 30, eliminating the requirements
5153 that &amp;t and &amp;u return the address of t and u, respectively.
5154 </p>
5155
5156
5157 <p><b>Rationale:</b></p>
5158 <p>This was a deliberate design decision.  Perhaps it should be
5159    reconsidered for C++0x. </p>
5160
5161
5162
5163
5164
5165 <hr>
5166 <h3><a name="392"></a>392. 'equivalence' for input iterators</h3>
5167 <p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5168  <b>Submitter:</b> Corwin Joy <b>Date:</b> 2002-12-11</p>
5169 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
5170 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5171 <p><b>Discussion:</b></p>
5172
5173 <p>
5174 In section 24.1.1 [input.iterators] table 72 -
5175 'Input Iterator Requirements' we have as a postcondition of *a:
5176 "If a==b and (a, b) is in the domain of == then *a is equivalent to *b".
5177 </p>
5178
5179 <p>
5180 In section 24.5.3.5 [istreambuf.iterator::equal] it states that
5181 "istreambuf_iterator::equal returns true if and only if both iterators
5182 are at end-of-stream, or neither is at end-of-stream, <i>regardless of
5183 what streambuf object they use</i>."  (My emphasis).
5184 </p>
5185
5186 <p>
5187 The defect is that either 'equivalent' needs to be more precisely
5188 defined or the conditions for equality in 24.5.3.5 [istreambuf.iterator::equal]
5189 are incorrect. (Or both).
5190 </p>
5191
5192 <p>Consider the following example:</p>
5193 <pre>   #include &lt;iostream&gt;
5194    #include &lt;fstream&gt;
5195    #include &lt;iterator&gt;
5196    using namespace std;
5197
5198    int main() {
5199     ifstream file1("file1.txt"), file2("file2.txt");
5200     istreambuf_iterator&lt;char&gt; f1(file1), f2(file2);
5201     cout &lt;&lt; "f1 == f2 : " &lt;&lt; boolalpha &lt;&lt; (f1 == f2) &lt;&lt; endl;
5202     cout &lt;&lt; "f1 = " &lt;&lt; *f1 &lt;&lt; endl;
5203     cout &lt;&lt; "f2 = " &lt;&lt; *f2 &lt;&lt; endl;
5204     return 0;
5205    }
5206 </pre>
5207
5208 <p>Now assuming that neither f1 or f2 are at the end-of-stream then
5209 f1 == f2 by 24.5.3.5 [istreambuf.iterator::equal].</p>
5210
5211 <p>However, it is unlikely that *f1 will give the same value as *f2 except
5212 by accident.</p>
5213
5214 <p>So what does *f1 'equivalent' to *f2 mean?  I think the standard should
5215 be clearer on this point, or at least be explicit that this does not
5216 mean that *f1 and *f2 are required to have the same value in the case
5217 of input iterators.</p>
5218
5219
5220 <p><b>Proposed resolution:</b></p>
5221
5222
5223 <p><b>Rationale:</b></p><p>The two iterators aer not in the domain of ==</p>
5224
5225
5226
5227
5228
5229
5230 <hr>
5231 <h3><a name="399"></a>399. volations of unformatted input function requirements</h3>
5232 <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5233  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
5234 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</p>
5235 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
5236 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5237 <p><b>Discussion:</b></p>
5238     <p>
5239 The Effects clauses for the two functions below violate the
5240 general requirements on unformatted input functions outlined
5241 in 27.6.1.3: they do not begin by constructing a sentry object.
5242 Instead, they begin by calling widen ('\n'), which may throw
5243 an exception. The exception is then allowed to propagate from
5244 the unformatted input function irrespective of the setting of
5245 exceptions().
5246     </p>
5247     <p>
5248 Note that in light of 27.6.1.1, p3 and p4, the fact that the
5249 functions allow exceptions thrown from widen() to propagate
5250 may not strictly speaking be a defect (but the fact that the
5251 functions do not start by constructing a sentry object still
5252 is). However, since an exception thrown from ctype&lt;charT&gt;
5253 ::widen() during any other input operation (say, from within
5254 a call to num_get&lt;charT&gt;::get()) will be caught and cause
5255 badbit to be set, these two functions should not be treated
5256 differently for the sake of consistency.
5257     </p>
5258
5259
5260 <p><b>Proposed resolution:</b></p>
5261
5262
5263 <p><b>Rationale:</b></p>
5264 <p>
5265 Not a defect.  The standard is consistent, and the behavior required
5266 by the standard is unambiguous.  Yes, it's theoretically possible for
5267 widen to throw.  (Not that this will happen for the default ctype
5268 facet or for most real-world replacement ctype facets.)  Users who
5269 define ctype facets that can throw, and who care about this behavior,
5270 can use alternative signatures that don't call widen.
5271 </p>
5272
5273
5274
5275
5276
5277
5278 <hr>
5279 <h3><a name="429"></a>429. typo in basic_ios::clear(iostate)</h3>
5280 <p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5281  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
5282 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
5283 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5284 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a></p>
5285 <p><b>Discussion:</b></p>
5286         <p>
5287
5288 The Effects clause in 27.4.4.3, p5 describing the effects of a call to
5289 the ios_base member function clear(iostate state) says that the function
5290 only throws if the respective bits are already set prior to the function
5291 call. That's obviously not the intent. If it was, a call to clear(badbit)
5292 on an object for which (rdstate() == goodbit &amp;&amp; exceptions() == badbit)
5293 holds would not result in an exception being thrown.
5294
5295         </p>
5296
5297     <p><b>Proposed resolution:</b></p>
5298         <p>
5299
5300 The text ought to be changed from
5301 <br>
5302
5303 "If (rdstate() &amp; exceptions()) == 0, returns. ..."
5304 <br>
5305
5306 to
5307 <br>
5308
5309 "If (state &amp; exceptions()) == 0, returns. ..."
5310         </p>
5311
5312
5313 <p><b>Rationale:</b></p>
5314
5315
5316
5317
5318
5319
5320 <hr>
5321 <h3><a name="433"></a>433. Contradiction in specification of unexpected()</h3>
5322 <p><b>Section:</b> 18.7.2.4 [unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5323  <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Date:</b> 2003-09-29</p>
5324 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5325 <p><b>Discussion:</b></p>
5326 <p>
5327 Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected();
5328 is called (18.7.2) immediately after completing the stack unwinding
5329 for the former function", but 18.7.2.4 (Effects) says that "void
5330 unexpected(); . . . Calls the unexpected_handler function in effect
5331 immediately after evaluating the throwexpression (18.7.2.2),".  Isn't
5332 here a contradiction: 15.5.2 requires stack have been unwound when in
5333 void unexpected() and therefore in unexpected_handler but 18.7.2.4
5334 claims that unexpected_handler is called "in effect immediately" after
5335 evaluation of throw expression is finished, so there is no space left
5336 for stack to be unwound therefore?  I think the phrase "in effect
5337 immediately" should be removed from the standard because it brings
5338 ambiguity in understanding.
5339 </p>
5340
5341
5342 <p><b>Proposed resolution:</b></p>
5343
5344
5345 <p><b>Rationale:</b></p>
5346 <p>There is no contradiction.  The phrase "in effect immediately" is
5347   just to clarify which handler is to be called.</p>
5348
5349
5350
5351
5352
5353 <hr>
5354 <h3><a name="437"></a>437. Formatted output of function pointers is confusing</h3>
5355 <p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5356  <b>Submitter:</b> Ivan Godard <b>Date:</b> 2003-10-24</p>
5357 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
5358 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5359 <p><b>Discussion:</b></p>
5360 <p>
5361 Given:
5362 </p>
5363 <pre>void f(int) {}
5364 void(*g)(int) = f;
5365 cout &lt;&lt; g;
5366 </pre>
5367
5368 <p>
5369 (with the expected #include and usings), the value printed is a rather
5370 surprising "true". Rather useless too.
5371 </p>
5372
5373 <p>The standard defines:</p>
5374
5375 <pre>ostream&amp; operator&lt;&lt;(ostream&amp;, void*);</pre>
5376
5377 <p>which picks up all data pointers and prints their hex value, but does
5378 not pick up function pointers because there is no default conversion
5379 from function pointer to void*. Absent that, we fall back to legacy
5380 conversions from C and the function pointer is converted to bool.
5381 </p>
5382
5383 <p>There should be an analogous inserter that prints the address of a
5384   function pointer.</p>
5385
5386
5387 <p><b>Proposed resolution:</b></p>
5388
5389
5390 <p><b>Rationale:</b></p>
5391 <p>This is indeed a wart, but there is no good way to solve it.  C
5392   doesn't provide a portable way of outputting the address of a
5393   function point either.</p>
5394
5395
5396
5397
5398
5399 <hr>
5400 <h3><a name="439"></a>439. Should facets be copyable?</h3>
5401 <p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5402  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-02</p>
5403 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
5404 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
5405 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5406 <p><b>Discussion:</b></p>
5407 <p>The following facets classes have no copy constructors described in
5408   the standard, which, according to the standard, means that they are
5409   supposed to use the compiler-generated defaults.  Default copy
5410   behavior is probably inappropriate.  We should either make these
5411   classes uncopyable or else specify exactly what their constructors do.</p>
5412
5413 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#421">421</a>.</p>
5414
5415 <pre>        ctype_base
5416         ctype
5417         ctype_byname
5418         ctype&lt;char&gt;
5419         ctype_byname&lt;char&gt;
5420         codecvt_base
5421         codecvt
5422         codecvt_byname
5423         num_get
5424         num_put
5425         numpunct
5426         numpunct_byname
5427         collate
5428         collate_byname
5429         time_base
5430         time_get
5431         time_get_byname
5432         time_put
5433         time_put_byname
5434         money_get
5435         money_put
5436         money_base
5437         moneypunct
5438         moneypunct_byname
5439         messages_base
5440         messages
5441         messages_byname
5442 </pre>
5443
5444
5445
5446 <p><b>Proposed resolution:</b></p>
5447
5448
5449 <p><b>Rationale:</b></p>
5450 <p>The copy constructor in the base class is private.</p>
5451
5452
5453
5454
5455
5456 <hr>
5457 <h3><a name="440"></a>440. Should std::complex use unqualified transcendentals?</h3>
5458 <p><b>Section:</b> 26.3.8 [complex.transcendentals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5459  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-05</p>
5460 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5461 <p><b>Discussion:</b></p>
5462 <p>
5463 Operations like <tt>pow</tt> and <tt>exp</tt> on
5464 <tt>complex&lt;T&gt;</tt> are typically implemented in terms of
5465 operations like <tt>sin</tt> and <tt>cos</tt> on <tt>T</tt>.
5466 Should implementations write this as <tt>std::sin</tt>, or as plain
5467 unqualified <tt>sin</tt>?
5468 </p>
5469
5470 <p>The issue, of course, is whether we want to use
5471 argument-dependent lookup in the case where <tt>T</tt> is a
5472 user-defined type.  This is similar to the issue of valarray
5473 transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>.</p>
5474
5475 <p>This issue differs from valarray transcendentals in two important
5476 ways.  First, "the effect of instantiating the template
5477 <tt>complex</tt> for types other than float, double or long double is
5478 unspecified." (26.3.1 [complex.synopsis]) Second, the standard does not
5479 dictate implementation, so there is no guarantee that a particular
5480 real math function is used in the implementation of a particular
5481 complex function.</p>
5482
5483
5484
5485 <p><b>Proposed resolution:</b></p>
5486
5487
5488 <p><b>Rationale:</b></p>
5489 <p>If you instantiate std::complex for user-defined types, all bets
5490 are off.</p>
5491
5492
5493
5494
5495
5496 <hr>
5497 <h3><a name="447"></a>447. Wrong template argument for time facets</h3>
5498 <p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5499  <b>Submitter:</b> Pete Becker <b>Date:</b> 2003-12-26</p>
5500 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
5501 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5502 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a></p>
5503 <p><b>Discussion:</b></p>
5504 <p>
5505 22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others:
5506 </p>
5507 <pre>    time_get&lt;char,InputIterator&gt;
5508     time_get_byname&lt;char,InputIterator&gt;
5509     time_get&lt;wchar_t,OutputIterator&gt;
5510     time_get_byname&lt;wchar_t,OutputIterator&gt;
5511 </pre>
5512
5513 <p>
5514 The second argument to the last two should be InputIterator, not
5515 OutputIterator.
5516 </p>
5517
5518
5519 <p><b>Proposed resolution:</b></p>
5520 <p>
5521 Change the second template argument to InputIterator.
5522 </p>
5523
5524
5525 <p><b>Rationale:</b></p>
5526
5527
5528
5529
5530
5531
5532 <hr>
5533 <h3><a name="450"></a>450. set::find is inconsistent with associative container requirements</h3>
5534 <p><b>Section:</b> 23.3.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5535  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
5536 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</p>
5537 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5538 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a></p>
5539 <p><b>Discussion:</b></p>
5540 <p>map/multimap have:</p>
5541
5542 <pre>   iterator find(const key_type&amp; x) const;
5543         const_iterator find(const key_type&amp; x) const;
5544 </pre>
5545
5546 <p>
5547 which is consistent with the table of associative container requirements.
5548 But set/multiset have:
5549 </p>
5550 <pre>   iterator find(const key_type&amp;) const;
5551 </pre>
5552
5553 <p>
5554 set/multiset should look like map/multimap, and honor the requirements
5555 table, in this regard.
5556 </p>
5557
5558
5559 <p><b>Proposed resolution:</b></p>
5560
5561
5562 <p><b>Rationale:</b></p>
5563
5564
5565
5566
5567
5568
5569 <hr>
5570 <h3><a name="451"></a>451. Associative erase should return an iterator</h3>
5571 <p><b>Section:</b> 23.1.2 [associative.reqmts], 23.3 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5572  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
5573 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
5574 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5575 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p>
5576 <p><b>Discussion:</b></p>
5577 <p>map/multimap/set/multiset have:</p>
5578 <pre>   void erase(iterator);
5579         void erase(iterator, iterator);
5580 </pre>
5581
5582 <p>But there's no good reason why these can't return an iterator, as for
5583 vector/deque/list:</p>
5584 <pre>   iterator erase(iterator);
5585         iterator erase(iterator, iterator);
5586 </pre>
5587
5588
5589
5590 <p><b>Proposed resolution:</b></p>
5591 <p>
5592 Informally: The table of associative container requirements, and the
5593 relevant template classes, should return an iterator designating the
5594 first element beyond the erased subrange.
5595 </p>
5596
5597
5598 <p><b>Rationale:</b></p>
5599
5600
5601
5602
5603
5604
5605 <hr>
5606 <h3><a name="452"></a>452.  locale::combine should be permitted to generate a named locale</h3>
5607 <p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5608  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
5609 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p>
5610 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5611 <p><b>Discussion:</b></p>
5612 <pre>template&lt;class Facet&gt;
5613         locale::combine(const locale&amp;) const;
5614 </pre>
5615 <p>
5616 is obliged to create a locale that has no name. This is overspecification
5617 and overkill. The resulting locale should follow the usual rules -- it
5618 has a name if the locale argument has a name and Facet is one of the
5619 standard facets.
5620 </p>
5621
5622 <p><i>[
5623  Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440,
5624  c++std-lib-13443): agreed that it's overkill to say that the locale
5625  is obligated to be nameless.  However, we also can't require it to
5626  have a name.  At the moment, locale names are based on categories
5627  and not on individual facets.  If a locale contains two different
5628  facets of different names from the same category, then this would
5629  not fit into existing naming schemes.  We need to give
5630  implementations more freedom.  Bill will provide wording.
5631 ]</i></p>
5632
5633
5634
5635
5636 <p><b>Rationale:</b></p>
5637 <p>After further discussion the LWG decided to close this as NAD.
5638   The fundamental problem is that names right now are per-category,
5639   not per-facet.  The <tt>combine</tt> member function works at the
5640   wrong level of granularity.</p>
5641
5642
5643
5644
5645
5646 <hr>
5647 <h3><a name="463"></a>463. auto_ptr usability issues</h3>
5648 <p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5649  <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p>
5650 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
5651 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5652 <p><b>Discussion:</b></p>
5653
5654 <p>
5655 TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
5656 member of auto_ptr (20.4.5.3/4) obsolete.
5657 </p>
5658
5659 <p>
5660 The sole purpose of this obsolete conversion member is to enable copy
5661 initialization base from r-value derived (or any convertible types like
5662 cv-types) case:
5663 </p>
5664 <pre>#include &lt;memory&gt;
5665 using std::auto_ptr;
5666
5667 struct B {};
5668 struct D : B {};
5669
5670 auto_ptr&lt;D&gt; source();
5671 int sink(auto_ptr&lt;B&gt;);
5672 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
5673 </pre>
5674
5675 <p>
5676 The excellent analysis of conversion operations that was given in the final
5677 auto_ptr proposal
5678 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
5679 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
5680 wrong and actually comes to forbid the loophole that was exploited by the
5681 auto_ptr designers.
5682 </p>
5683
5684 <p>
5685 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
5686 ever allowed this case. This is probably because it requires 3 user defined
5687 conversions and in fact current compilers conform to DR #84.
5688 </p>
5689
5690 <p>
5691 I was surprised to discover that the obsolete conversion member actually has
5692 negative impact of the copy initialization base from l-value derived
5693 case:</p>
5694 <pre>auto_ptr&lt;D&gt; dp;
5695 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
5696 </pre>
5697
5698 <p>
5699 I'm sure that the original intention was allowing this initialization using
5700 the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
5701 since in this copy initialization it's merely user defined conversion (UDC)
5702 and the obsolete conversion member is UDC with the same rank (for the early
5703 overloading stage) there is an ambiguity between them.
5704 </p>
5705
5706 <p>
5707 Removing the obsolete member will have impact on code that explicitly
5708 invokes it:
5709 </p>
5710 <pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
5711 </pre>
5712
5713 <p>
5714 IMHO no one ever wrote such awkward code and the reasonable workaround for
5715 #1 is:
5716 </p>
5717 <pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
5718 </pre>
5719
5720 <p>
5721 I was even more surprised to find out that after removing the obsolete
5722 conversion member the initialization was still ill-formed:
5723 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
5724 </p>
5725
5726 <p>
5727 This copy initialization semantically requires copy constructor which means
5728 that both template conversion constructor and the auto_ptr_ref conversion
5729 member (20.4.5.3/3) are required which is what was explicitly forbidden in
5730 DR #84. This is a bit amusing case in which removing ambiguity results with
5731 no candidates.
5732 </p>
5733
5734 <p>
5735 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
5736 </p>
5737 <pre>int f(auto_ptr&lt;B&gt;, std::string);
5738 auto_ptr&lt;B&gt; source2();
5739
5740 // string constructor throws while auto_ptr_ref
5741 // "holds" the pointer
5742 int x4 = f(source2(), "xyz"); // #4
5743 </pre>
5744
5745 <p>
5746 The theoretic execution sequence that will cause a leak:
5747 </p>
5748 <ol>
5749 <li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
5750 <li>call string::string(char const*) and throw</li>
5751 </ol>
5752
5753 <p>
5754 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
5755 returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
5756 the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
5757 library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
5758 is much more reasonable. Other vendor implemented auto_ptr_ref as
5759 defectively required and it results with awkward and catastrophic code:
5760 int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
5761 paths
5762 </p>
5763
5764 <p>
5765 Dave Abrahams noticed that there is no specification saying that
5766 auto_ptr_ref copy constructor can't throw.
5767 </p>
5768
5769 <p>
5770 My proposal comes to solve all the above issues and significantly simplify
5771 auto_ptr implementation. One of the fundamental requirements from auto_ptr
5772 is that it can be constructed in an intuitive manner (i.e. like ordinary
5773 pointers) but with strict ownership semantics which yield that source
5774 auto_ptr in initialization must be non-const. My idea is to add additional
5775 constructor template with sole propose to generate ill-formed, diagnostic
5776 required, instance for const auto_ptr arguments during instantiation of
5777 declaration. This special constructor will not be instantiated for other
5778 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
5779 in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
5780 legitimate since the actual argument can't be const yet non const r-value
5781 are acceptable.
5782 </p>
5783
5784 <p>
5785 This implementation technique makes the "private auxiliary class"
5786 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
5787 GCC and VC) consume the new implementation as expected and allow all
5788 intuitive initialization and assignment cases while rejecting illegal cases
5789 that involve const auto_ptr arguments.
5790 </p>
5791
5792 <p>The proposed auto_ptr interface:</p>
5793
5794 <pre>namespace std {
5795     template&lt;class X&gt; class auto_ptr {
5796     public:
5797         typedef X element_type;
5798
5799         // 20.4.5.1 construct/copy/destroy:
5800         explicit auto_ptr(X* p=0) throw();
5801         auto_ptr(auto_ptr&amp;) throw();
5802         template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
5803         auto_ptr&amp; operator=(auto_ptr&amp;) throw();
5804         template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
5805         ~auto_ptr() throw();
5806
5807         // 20.4.5.2 members:
5808         X&amp; operator*() const throw();
5809         X* operator-&gt;() const throw();
5810         X* get() const throw();
5811         X* release() throw();
5812         void reset(X* p=0) throw();
5813
5814     private:
5815         template&lt;class U&gt;
5816         auto_ptr(U&amp; rhs, typename
5817 unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
5818     };
5819 }
5820 </pre>
5821
5822 <p>
5823 One compliant technique to implement the unspecified_error_on_const_auto_ptr
5824 helper class is using additional private auto_ptr member class template like
5825 the following:
5826 </p>
5827 <pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
5828
5829 template&lt;typename T&gt;
5830 struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
5831 { typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
5832 </pre>
5833
5834 <p>
5835 There are other techniques to implement this helper class that might work
5836 better for different compliers (i.e. better diagnostics) and therefore I
5837 suggest defining its semantic behavior without mandating any specific
5838 implementation. IMO, and I didn't found any compiler that thinks otherwise,
5839 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
5840 verifying this with core language experts.
5841 </p>
5842
5843 <p><b>Further changes in standard text:</b></p>
5844 <p>Remove section 20.4.5.3</p>
5845
5846 <p>Change 20.4.5/2 to read something like:
5847 Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
5848 ill-formed declaration that will require unspecified diagnostic.</p>
5849
5850 <p>Change 20.4.5.1/4,5,6 to read:</p>
5851
5852 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
5853 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
5854 <p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
5855 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
5856
5857 <p>Change 20.4.5.1/10</p>
5858 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
5859 </pre>
5860 <p>
5861 10 Requires: Y* can be implicitly converted to X*. The expression delete
5862 get() is well formed.
5863 </p>
5864
5865 <p>LWG TC DR #127 is obsolete.</p>
5866
5867 <p>
5868 Notice that the copy constructor and copy assignment operator should remain
5869 as before and accept non-const auto_ptr&amp; since they have effect on the form
5870 of the implicitly declared copy constructor and copy assignment operator of
5871 class that contains auto_ptr as member per 12.8/5,10:
5872 </p>
5873 <pre>struct X {
5874     // implicit X(X&amp;)
5875     // implicit X&amp; operator=(X&amp;)
5876     auto_ptr&lt;D&gt; aptr_;
5877 };
5878 </pre>
5879
5880 <p>
5881 In most cases this indicates about sloppy programming but preserves the
5882 current auto_ptr behavior.
5883 </p>
5884
5885 <p>
5886 Dave Abrahams encouraged me to suggest fallback implementation in case that
5887 my suggestion that involves removing of auto_ptr_ref will not be accepted.
5888 In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
5889 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
5890 cases. The two constructors that I suggested will co exist with the current
5891 members but will make auto_ptr_ref obsolete in initialization contexts.
5892 auto_ptr_ref will be effective in assignment contexts as suggested in DR
5893 #127 and I can't see any serious exception safety issues in those cases
5894 (although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
5895 have to be revised to say that it strictly holds pointer of type X and not
5896 reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
5897 constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
5898 from r-value derived to base).
5899 </p>
5900
5901
5902
5903 <p><b>Proposed resolution:</b></p>
5904 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
5905   want to fix auto_ptr for C++-0x, or remove it and replace it with
5906   move_ptr and unique_ptr.]</i></p>
5907
5908
5909
5910 <p><b>Rationale:</b></p>
5911 <p>
5912 Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
5913 and people know how to deal with it.  Going forward <tt>unique_ptr</tt> is the recommended
5914 tool.
5915 </p>
5916
5917
5918
5919
5920
5921 <hr>
5922 <h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3>
5923 <p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5924  <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-06-10</p>
5925 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
5926 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5927 <p><b>Discussion:</b></p>
5928 <p>
5929 Today, my colleagues and me wasted a lot of time. After some time, I
5930 found the problem. It could be reduced to the following short example:
5931 </p>
5932
5933 <pre>  #include &lt;string&gt;
5934   int main() { std::string( 0 ); }
5935 </pre>
5936
5937 <p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
5938 Comeau online) compile the above without errors or warnings! The
5939 programs (at least for the GCC) resulted in a SEGV.</p>
5940
5941 <p>I know that the standard explicitly states that the ctor of string
5942 requires a char* which is not zero. STLs could easily detect the above
5943 case with a private ctor for basic_string which takes a single 'int'
5944 argument. This would catch the above code at compile time and would not
5945 ambiguate any other legal ctors.</p>
5946
5947 <p><i>[Redmond: No great enthusiasm for doing this.  If we do,
5948   however, we want to do it for all places that take <tt>charT*</tt>
5949   pointers, not just the single-argument constructor.  The other
5950   question is whether we want to catch this at compile time (in which
5951   case we catch the error of a literal 0, but not an expression whose
5952   value is a null pointer), at run time, or both.]</i></p>
5953
5954
5955
5956
5957 <p><b>Proposed resolution:</b></p>
5958
5959
5960 <p><b>Rationale:</b></p>
5961 <p>
5962 Recommend NAD.  Relegate this functionality to debugging implementations.
5963 </p>
5964
5965
5966
5967
5968
5969 <hr>
5970 <h3><a name="470"></a>470. accessing containers from their elements' special functions</h3>
5971 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5972  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
5973 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
5974 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5975 <p><b>Discussion:</b></p>
5976
5977 <p>
5978 The standard doesn't prohibit the destructors (or any other special
5979 functions) of containers' elements invoked from a member function
5980 of the container from "recursively" calling the same (or any other)
5981 member function on the same container object, potentially while the
5982 container is in an intermediate state, or even changing the state
5983 of the container object while it is being modified. This may result
5984 in some surprising (i.e., undefined) behavior.
5985 </p>
5986
5987 <p>Read email thread starting with c++std-lib-13637 for more.</p>
5988
5989
5990
5991 <p><b>Proposed resolution:</b></p>
5992
5993 <p>Add to Container Requirements the following new paragraph:</p>
5994
5995 <pre>    Unless otherwise specified, the behavior of a program that
5996     invokes a container member function f from a member function
5997     g of the container's value_type on a container object c that
5998     called g from its mutating member function h, is undefined.
5999     I.e., if v is an element of c, directly or indirectly calling
6000     c.h() from v.g() called from c.f(), is undefined.
6001 </pre>
6002
6003 <p><i>[Redmond: This is a real issue, but it's probably a clause 17
6004   issue, not clause 23.  We get the same issue, for example, if we
6005   try to destroy a stream from one of the stream's callback functions.]</i></p>
6006
6007
6008
6009
6010 <p><b>Rationale:</b></p>
6011 <p>
6012 Recommend NAD.  We agree this is an issue, but not a defect.
6013 We believe that there is no wording we can put in the standard
6014 that will cover all cases without introducing unfortunate
6015 corner cases.
6016 </p>
6017
6018
6019
6020
6021
6022 <hr>
6023 <h3><a name="472"></a>472. Missing "Returns" clause in std::equal_range</h3>
6024 <p><b>Section:</b> 25.3.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6025  <b>Submitter:</b> Prateek R Karandikar <b>Date:</b> 2004-06-30</p>
6026 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</p>
6027 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6028 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a></p>
6029 <p><b>Discussion:</b></p>
6030 <p>
6031 There is no "Returns:" clause for std::equal_range, which returns non-void.
6032 </p>
6033
6034
6035 <p><b>Proposed resolution:</b></p>
6036
6037
6038 <p><b>Rationale:</b></p>
6039 <p>Fixed as part of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>.</p>
6040
6041
6042
6043
6044
6045
6046 <hr>
6047 <h3><a name="476"></a>476. Forward Iterator implied mutability</h3>
6048 <p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6049  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-09</p>
6050 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
6051 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6052 <p><b>Discussion:</b></p>
6053
6054 <p>24.1/3 says:</p>
6055 <blockquote><p>
6056   Forward iterators satisfy all the requirements of the input and
6057   output iterators and can be used whenever either kind is specified
6058 </p></blockquote>
6059
6060 <p>
6061 The problem is that satisfying the requirements of output iterator
6062 means that you can always assign *something* into the result of
6063 dereferencing it.  That makes almost all non-mutable forward
6064 iterators non-conforming.  I think we need to sever the refinement
6065 relationship between forward iterator and output iterator.
6066 </p>
6067
6068 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.  But this is not a dup.</p>
6069
6070
6071
6072 <p><b>Proposed resolution:</b></p>
6073
6074
6075 <p><b>Rationale:</b></p>
6076 <p>Yes, 24.1/3 does say that. But it's introductory material. The
6077 precise specification is in 24.1.3, and the requrements table there is
6078 right.  We don't need to fine-tune introductory wording.  (Especially
6079 since this wording is likely to be changed as part of the iterator
6080 overhaul.)</p>
6081
6082
6083
6084
6085
6086 <hr>
6087 <h3><a name="477"></a>477. Operator-&gt; for const forward iterators</h3>
6088 <p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6089  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-11</p>
6090 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
6091 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6092 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
6093 <p><b>Discussion:</b></p>
6094 <p>
6095 The Forward Iterator requirements table contains the following:
6096 </p>
6097 <pre> expression  return type         operational  precondition
6098                                   semantics
6099   ==========  ==================  ===========  ==========================
6100   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
6101               otherwise const U&amp;
6102
6103   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
6104 </pre>
6105
6106 <p>
6107 The first line is exactly right.  The second line is wrong.  Basically
6108 it implies that the const-ness of the iterator affects the const-ness
6109 of referenced members.  But Paragraph 11 of [lib.iterator.requirements] says:
6110 </p>
6111
6112 <blockquote><p>
6113    In the following sections, a and b denote values of type const X, n
6114    denotes a value of the difference type Distance, u, tmp, and m
6115    denote identifiers, r denotes a value of X&amp;, t denotes a value of
6116    value type T, o denotes a value of some type that is writable to
6117    the output iterator.
6118 </p></blockquote>
6119
6120 <p>AFAICT if we need the second line at all, it should read the same
6121 as the first line.</p>
6122
6123 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
6124
6125
6126 <p><b>Proposed resolution:</b></p>
6127
6128
6129 <p><b>Rationale:</b></p>
6130 <p>The LWG agrees that this is a real problem.  Marked as a DUP
6131   because the LWG chose to adopt the solution proposed in
6132   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
6133 </p>
6134
6135
6136
6137
6138
6139 <hr>
6140 <h3><a name="479"></a>479. Container requirements and placement new</h3>
6141 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6142  <b>Submitter:</b> Herb Sutter <b>Date:</b> 2004-08-01</p>
6143 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
6144 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
6145 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6146 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a></p>
6147 <p><b>Discussion:</b></p>
6148 <p>Nothing in the standard appears to make this program ill-formed:</p>
6149
6150 <pre>  struct C {
6151     void* operator new( size_t s ) { return ::operator new( s ); }
6152     // NOTE: this hides in-place and nothrow new
6153   };
6154
6155   int main() {
6156     vector&lt;C&gt; v;
6157     v.push_back( C() );
6158   }
6159 </pre>
6160
6161 <p>Is that intentional?  We should clarify whether or not we intended
6162   to require containers to support types that define their own special
6163   versions of <tt>operator new</tt>.</p>
6164
6165 <p><i>[
6166 Lillehammer: A container will definitely never use this overridden
6167 operator new, but whether it will fail to compile is unclear from the
6168 standard.  Are containers supposed to use qualified or unqualified
6169 placement new?  20.4.1.1 is somewhat relevant, but the standard
6170 doesn't make it completely clear whether containers have to use
6171 Allocator::construct(). If containers don't use it, the details of how
6172 containers use placement new are unspecified. That is the real bug,
6173 but it needs to be fixed as part of the allocator overhaul.  Weak
6174 support that the eventual solution should make this code well formed.
6175 ]</i></p>
6176
6177
6178
6179
6180 <p><b>Proposed resolution:</b></p>
6181
6182
6183
6184
6185
6186
6187
6188 <hr>
6189 <h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3>
6190 <p><b>Section:</b> 20.5.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6191  <b>Submitter:</b> Joe Gottman <b>Date:</b> 2004-08-19</p>
6192 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
6193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6194 <p><b>Discussion:</b></p>
6195 <p>The classes std::unary_function and std::binary_function are both
6196 designed to be inherited from but contain no virtual functions.  This
6197 makes it too easy for a novice programmer to write code like
6198 binary_function&lt;int, int, int&gt; *p = new plus&lt;int&gt;; delete p;</p>
6199
6200 <p>There are two common ways to prevent this source of undefined
6201 behavior: give the base class a public virtual destructor, or give it
6202 a protected nonvirtual destructor.  Since unary_function and
6203 binary_function have no other virtual functions, (note in particular
6204 the absence of an operator()() ), it would cost too much to give them
6205 public virtual destructors.  Therefore, they should be given protected
6206 nonvirtual destructors.</p>
6207
6208
6209 <p><b>Proposed resolution:</b></p>
6210 <p>Change Paragraph 20.3.1 of the Standard from</p>
6211 <pre>    template &lt;class Arg, class Result&gt;
6212     struct unary_function {
6213         typedef Arg argument_type;
6214         typedef Result result_type;
6215     };
6216
6217     template &lt;class Arg1, class Arg2, class Result&gt;
6218     struct binary_function {
6219         typedef Arg1 first_argument_type;
6220         typedef Arg2 second_argument_type;
6221         typedef Result result_type;
6222     };
6223 </pre>
6224
6225 <p>to</p>
6226 <pre>    template &lt;class Arg, class Result&gt;
6227         struct unary_function {
6228         typedef Arg argument_type;
6229         typedef Result result_type;
6230     protected:
6231         ~unary_function() {}
6232     };
6233
6234     template &lt;class Arg1, class Arg2, class Result&gt;
6235     struct binary_function {
6236         typedef Arg1 first_argument_type;
6237         typedef Arg2 second_argument_type;
6238         typedef Result result_type;
6239     protected:
6240         ~binary_function() {}
6241     };
6242 </pre>
6243
6244
6245 <p><b>Rationale:</b></p>
6246 <p>The LWG doesn't believe the existing definition causes anybody any
6247   concrete harm.</p>
6248
6249
6250
6251
6252
6253 <hr>
6254 <h3><a name="481"></a>481. unique's effects on the range [result, last)</h3>
6255 <p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6256  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-08-30</p>
6257 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
6258 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6259 <p><b>Discussion:</b></p>
6260 <p>
6261 The standard says that unique(first, last) "eliminates all but the
6262 first element from every consecutive group of equal elements" in
6263 [first, last) and returns "the end of the resulting range".  So a
6264 postcondition is that [first, result) is the same as the old [first,
6265 last) except that duplicates have been eliminated.
6266 </p>
6267
6268 <p>What postconditions are there on the range [result, last)?  One
6269   might argue that the standard says nothing about those values, so
6270   they can be anything.  One might also argue that the standard
6271   doesn't permit those values to be changed, so they must not be.
6272   Should the standard say something explicit one way or the other?</p>
6273
6274
6275
6276 <p><b>Proposed resolution:</b></p>
6277 <p>
6278 </p>
6279
6280
6281 <p><b>Rationale:</b></p>
6282 <p>We don't want to make many guarantees about what's in [result,
6283 end). Maybe we aren't being quite explicit enough about not being
6284 explicit, but it's hard to think that's a major problem.</p>
6285
6286
6287
6288
6289
6290 <hr>
6291 <h3><a name="482"></a>482. Swapping pairs</h3>
6292 <p><b>Section:</b> 20.2.3 [pairs], 20.3 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
6293  <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-09-14</p>
6294 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
6295 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
6296 <p><b>Discussion:</b></p>
6297 <p>(Based on recent comp.std.c++ discussion)</p>
6298
6299 <p>Pair (and tuple) should specialize std::swap to work in terms of
6300 std::swap on their components.  For example, there's no obvious reason
6301 why swapping two objects of type pair&lt;vector&lt;int&gt;,
6302 list&lt;double&gt; &gt; should not take O(1).</p>
6303
6304 <p><i>[Lillehammer: We agree it should be swappable.  Howard will
6305   provide wording.]</i></p>
6306
6307
6308 <p><i>[
6309 Post Oxford:  We got <tt>swap</tt> for <tt>pair</tt> but accidently
6310 missed <tt>tuple</tt>.  <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
6311 ]</i></p>
6312
6313
6314
6315
6316 <p><b>Proposed resolution:</b></p>
6317 <p>
6318 Wording provided in
6319 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
6320 </p>
6321
6322 <p><b>Rationale:</b></p>
6323 <p>
6324 Recommend NAD, fixed by
6325 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
6326 </p>
6327
6328
6329
6330
6331
6332 <hr>
6333 <h3><a name="483"></a>483. Heterogeneous equality and EqualityComparable</h3>
6334 <p><b>Section:</b> 25.1 [alg.nonmodifying], 25.2 [alg.modifying.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6335  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2004-09-20</p>
6336 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6337 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a></p>
6338 <p><b>Discussion:</b></p>
6339 <p>c++std-lib-14262</p>
6340
6341 <p>[lib.alg.find] requires T to be EqualityComparable:</p>
6342
6343 <pre>template &lt;class InputIterator, class T&gt;
6344    InputIterator find(InputIterator first, InputIterator last,
6345                       const T&amp; value);
6346 </pre>
6347
6348 <p>
6349 However the condition being tested, as specified in the Effects
6350 clause, is actually *i == value, where i is an InputIterator.
6351 </p>
6352
6353 <p>
6354 The two clauses are in agreement only if the type of *i is T, but this
6355 isn't necessarily the case. *i may have a heterogeneous comparison
6356 operator that takes a T, or a T may be convertible to the type of *i.
6357 </p>
6358
6359 <p>Further discussion (c++std-lib-14264): this problem affects a
6360   number of algorithsm in clause 25, not just <tt>find</tt>.  We
6361   should try to resolve this problem everywhere it appears.</p>
6362
6363
6364 <p><b>Proposed resolution:</b></p>
6365
6366 <p>[lib.alg.find]:</p>
6367 <blockquote><p>
6368    Remove [lib.alg.find]/1.
6369 </p></blockquote>
6370
6371 <p>[lib.alg.count]:</p>
6372 <blockquote><p>
6373    Remove [lib.alg.count]/1.
6374 </p></blockquote>
6375
6376 <p>[lib.alg.search]:</p>
6377 <blockquote><p>
6378    Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4.
6379 </p></blockquote>
6380
6381 <p>[lib.alg.replace]:</p>
6382
6383 <blockquote>
6384    <p>
6385    Remove [lib.alg.replace]/1.
6386    Replace [lb.alg.replace]/2 with:
6387    </p>
6388
6389        <blockquote><p>
6390        For every iterator i in the range [first, last) for which *i == value
6391        or pred(*i) holds perform *i = new_value.
6392        </p></blockquote>
6393
6394    <p>
6395    Remove the first sentence of /4.
6396    Replace the beginning of /5 with:
6397    </p>
6398
6399        <blockquote><p>
6400        For every iterator i in the range [result, result + (last -
6401        first)), assign to *i either...
6402        </p></blockquote>
6403
6404    <p>(Note the defect here, current text says assign to i, not *i).</p>
6405 </blockquote>
6406
6407 <p>[lib.alg.fill]:</p>
6408
6409 <blockquote>
6410    <p>
6411    Remove "Type T is Assignable (23.1), " from /1.
6412    Replace /2 with:
6413    </p>
6414
6415        <blockquote><p>
6416        For every iterator i in the range [first, last) or [first, first + n),
6417        perform *i = value.
6418        </p></blockquote>
6419 </blockquote>
6420
6421 <p>[lib.alg.remove]:</p>
6422 <blockquote><p>
6423    Remove /1.
6424    Remove the first sentence of /6.
6425 </p></blockquote>
6426
6427
6428
6429 <p><b>Rationale:</b></p>
6430 <p>Duplicate of (a subset of) issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>.</p>
6431
6432
6433
6434
6435
6436
6437 <hr>
6438 <h3><a name="486"></a>486. min/max CopyConstructible requirement is too strict</h3>
6439 <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6440  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-10-13</p>
6441 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
6442 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6443 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a></p>
6444 <p><b>Discussion:</b></p>
6445 <p>A straightforward implementation of these algorithms does not need to
6446 copy T.</p>
6447
6448
6449 <p><b>Proposed resolution:</b></p>
6450 <p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p>
6451
6452
6453 <p><b>Rationale:</b></p>
6454
6455
6456
6457
6458
6459
6460 <hr>
6461 <h3><a name="487"></a>487. Allocator::construct is too limiting</h3>
6462 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6463  <b>Submitter:</b> Dhruv Matani <b>Date:</b> 2004-10-17</p>
6464 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
6465 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
6466 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6467 <p><b>Discussion:</b></p>
6468 <p>
6469 The standard's version of allocator::construct(pointer,
6470 const_reference) severely limits what you can construct using this
6471 function.  Say you can construct a socket from a file descriptor. Now,
6472 using this syntax, I first have to manually construct a socket from
6473 the fd, and then pass the constructed socket to the construct()
6474 function so it will just to an uninitialized copy of the socket I
6475 manually constructed. Now it may not always be possible to copy
6476 construct a socket eh! So, I feel that the changes should go in the
6477 allocator::construct(), making it:
6478 </p>
6479 <pre>    template&lt;typename T&gt;
6480     struct allocator{
6481       template&lt;typename T1&gt;
6482       void construct(pointer T1 const&amp; rt1);
6483     };
6484 </pre>
6485
6486 <p>
6487 Now, the ctor of the class T which matches the one that takes a T1 can
6488 be called! Doesn't that sound great?
6489 </p>
6490
6491
6492 <p><b>Proposed resolution:</b></p>
6493
6494
6495 <p><b>Rationale:</b></p>
6496 <p>NAD. STL uses copying all the time, and making it possible for
6497   allocators to construct noncopyable objects is useless in the
6498   absence of corresponding container changes. We might consider this
6499   as part of a larger redesign of STL.</p>
6500
6501
6502
6503
6504
6505 <hr>
6506 <h3><a name="489"></a>489. std::remove / std::remove_if wrongly specified</h3>
6507 <p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6508  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
6509 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
6510 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6511 <p><b>Discussion:</b></p>
6512 <p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the
6513 behavior of the mutating sequence operations std::remove and
6514 std::remove_if. However, the wording does not reflect the intended
6515 behavior [Note: See definition of intended behavior below] of these
6516 algorithms, as it is known to the C++ community [1].
6517 </p>
6518
6519
6520
6521 <p>1) Analysis of current wording:</p>
6522
6523
6524 <p>25.2.7 [lib.alg.remove], paragraph 2:</p>
6525
6526 <p>Current wording says:
6527 "Effects: Eliminates all the elements referred to by iterator i in the
6528 range [first, last) for which the following corresponding conditions
6529 hold: *i == value, pred(*i) != false."</p>
6530
6531 <p>
6532 This sentences expresses specifically that all elements denoted by the
6533 (original) range [first, last) for which the corresponding condition
6534 hold will be eliminated. Since there is no formal definition of the term
6535 "eliminate" provided, the meaning of "eliminate" in everyday language
6536 implies that as postcondition, no element in the range denoted by
6537 [first, last) will hold the corresponding condition on reiteration over
6538 the range [first, last).
6539 </p>
6540
6541 <p>
6542 However, this is neither the intent [Note: See definition of intended
6543 behavior below] nor a general possible approach. It can be easily proven
6544 that if all elements of the original range[first, last) will hold the
6545 condition, it is not possible to substitute them by an element for which
6546 the condition will not hold.
6547 </p>
6548
6549
6550 <p>25.2.7 [lib.alg.remove], paragraph 3:</p>
6551
6552 <p>
6553 Current wording says:
6554 "Returns: The end of the resulting range."
6555 </p>
6556
6557 <p>
6558 The resulting range is not specified. In combination with 25.2.7
6559 [lib.alg.remove], paragraph 2, the only reasonable interpretation of
6560 this so-called resulting range is the range [first,last) - thus
6561 returning always the ForwardIterator 'last' parameter.
6562 </p>
6563
6564
6565 <p>
6566 25.2.7 [lib.alg.remove], paragraph 4:
6567 </p>
6568
6569 <p>
6570 Current wording says:
6571 "Notes: Stable: the relative order of the elements that are not removed
6572 is the same as their relative order in the original range"
6573 </p>
6574
6575 <p>
6576 This sentences makes use of the term "removed", which is neither
6577 specified, nor used in a previous paragraph (which uses the term
6578 "eliminate"), nor unamgiuously separated from the name of the algorithm.
6579 </p>
6580
6581
6582 <p>2) Description of intended behavior:</p>
6583
6584 <p>
6585 For the rest of this Defect Report, it is assumed that the intended
6586 behavior was that all elements of the range [first, last) which do not
6587 hold the condition *i == value (std::remove) or  pred(*i) != false
6588 (std::remove_if)], call them s-elements [Note: s...stay], will be placed
6589 into a contiguous subrange of [first, last), denoted by the iterators
6590 [first, return value). The number of elements in the resulting range
6591 [first, return value) shall be equal to the number of s-elements in the
6592 original range [first, last). The relative order of the elements in the
6593 resulting subrange[first, return value) shall be the same as the
6594 relative order of the corresponding elements in the original range. It
6595 is undefined whether any elements in the resulting subrange [return
6596 value, last) will hold the corresponding condition, or not.
6597 </p>
6598
6599 <p>
6600 All implementations known to the author of this Defect Report comply
6601 with this intent. Since the intent  of the behavior (contrary to the
6602 current wording) is also described in various utility references serving
6603 the C++ community [1], it is not expected that fixing the paragraphs
6604 will influence current code - unless the code relies on the behavior as
6605 it is described by current wording and the implementation indeed
6606 reflects the current wording, and not the intent.
6607 </p>
6608
6609
6610
6611 <p>3) Proposed fixes:</p>
6612
6613
6614 <p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p>
6615
6616 <p>
6617 "Effect: Places all the elements referred to by iterator i in the range
6618 [first, last) for which the following corresponding conditions hold :
6619 !(*i == value), pred(*i) == false into the subrange [first, k) of the
6620 original range, where k shall denote a value of type ForwardIterator. It
6621 is undefined whether any elements in the resulting subrange [k, last)
6622 will hold the corresponding condition, or not."
6623 </p>
6624
6625 <p>Comments to the new wording:</p>
6626
6627 <p>
6628 a) "Places" has no special meaning, and the everyday language meaning
6629 should fit.
6630 b) The corresponding conditions were negated compared to the current
6631 wording, becaue the new wording requires it.
6632 c) The wording "of the original range" might be redundant, since any
6633 subrange starting at 'first' and containing no more elements than the
6634 original range is implicitly a subrange of the original range [first,
6635 last).
6636 d) The iterator k was introduced instead of "return value" in order to
6637 avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall
6638 denote a value of type ForwardIterator" might be redundant, because it
6639 follows implicitly by 25.2.7/3.
6640 e) "Places" does, in the author's opinion, explicitly forbid duplicating
6641 any element holding the corresponding condition in the original range
6642 [first, last) within the resulting range [first, k). If there is doubt
6643 this term might be not unambiguous regarding this, it is suggested that
6644 k is specified more closely by the following wording: "k shall denote a
6645 value of type ForwardIterator [Note: see d)] so that k - first is equal
6646 to the number of elements in the original range [first, last) for which
6647 the corresponding condition did hold". This could also be expressed as a
6648 separate paragraph "Postcondition:"
6649 f) The senctence "It is undefined whether any elements in the resulting
6650 subrange [k, last) will hold the corresponding condition, or not." was
6651 added consciously so the term "Places" does not imply if the original
6652 range [first, last) contains n elements holding the corresponding
6653 condition, the identical range[first, last) will also contain exactly n
6654 elements holding the corresponding condition after application of the
6655 algorithm.
6656 </p>
6657
6658 <p>
6659 Change 25.2.7 [lib.alg.remove], paragraph 3 to:
6660
6661 "Returns: The iterator k."
6662 </p>
6663
6664 <p>
6665 Change 25.2.7 [lib.alg.remove], paragraph 4 to:
6666
6667 "Notes: Stable: the relative order of the elements that are placed into
6668 the subrange [first, return value) shall be the same as their relative
6669 order was in the original range [first, last) prior to application of
6670 the algorithm."
6671 </p>
6672
6673 <p>
6674 Comments to the new wording:
6675 </p>
6676
6677 <p>
6678 a) the wording "was ...  prior to application of the algorithm" is used
6679 to explicitly distinguish the original range not only by means of
6680 iterators, but also by a 'chronological' factor from the resulting range
6681 [first, return value). It might be redundant.
6682 </p>
6683
6684 <p>
6685 [1]:
6686 The wording of these references is not always unambiguous, and provided
6687 examples partially contradict verbal description of the algorithms,
6688 because the verbal description resembles the problematic wording of
6689 ISO/IEC 14882:2003.
6690 </p>
6691
6692
6693 <p><b>Proposed resolution:</b></p>
6694
6695
6696 <p><b>Rationale:</b></p>
6697 <p>The LWG believes that the standard is sufficiently clear, and that
6698   there is no evidence of any real-world confusion about this point.</p>
6699
6700
6701
6702
6703
6704 <hr>
6705 <h3><a name="490"></a>490. std::unique wrongly specified</h3>
6706 <p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6707  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
6708 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
6709 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6710 <p><b>Discussion:</b></p>
6711 <p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the
6712 behavior of the mutating sequence operation std::unique. However, the
6713 wording does not reflect the intended behavior [Note: See definition of
6714 intended behavior below] of these algorithms, as it is known to the C++
6715 community [1].</p>
6716
6717
6718
6719 <p>1) Analysis of current wording:</p>
6720
6721
6722 <p>25.2.8 [lib.alg.unique], paragraph 1:</p>
6723
6724 <p>
6725 Current wording says:
6726 "Effects: Eliminates all but the first element from every consecutive
6727 group of equal elements referred to by the iterator i in the range
6728 [first, last) for which the following corresponding conditions hold: *i
6729 == *(i - 1) or pred(*i, *(i -1)) != false"
6730 </p>
6731
6732 <p>
6733 This sentences expresses specifically that all elements denoted by the
6734 (original) range [first, last) which are not but the first element from
6735 a consecutive group of equal elements (where equality is defined as *i
6736 == *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call
6737 them r-elements [Note: r...remove], will be eliminated. Since there is
6738 no formal definition of the term "eliminate" provided, it is undefined
6739 how this "elimination" takes place. But the meaning of "eliminate" in
6740 everyday language seems to disallow explicitly that after application of
6741 the algorithm, any r-element will remain at any position of the range
6742 [first, last) [2].
6743 </p>
6744
6745 <p>
6746 Another defect in the current wording concerns the iterators used to
6747 compare two elements for equality: The current wording contains the
6748 expression "(i - 1)", which is not covered by 25/9 [Note: See DR
6749 submitted by Thomas Mang regarding invalid iterator arithmetic
6750 expressions].
6751 </p>
6752
6753
6754 <p>
6755 25.2.8 [lib.alg.unique], paragraph 2:
6756 </p>
6757 <p>Current wording says:
6758 "Returns: The end of the resulting range."</p>
6759
6760 <p>
6761 The resulting range is not specified. In combination with 25.2.8
6762 [lib.alg.unique], paragraph 1, one reasonable interpretation (in the
6763 author's opinion even the only possible interpretation) of this
6764 so-called resulting range is the range [first, last) - thus returning
6765 always the ForwardIterator 'last' parameter.
6766 </p>
6767
6768 <p>2) Description of intended behavior:</p>
6769
6770 <p>
6771 For the rest of this Defect Report, it is assumed that the intended
6772 behavior was that all elements denoted by the original range [first,
6773 last) which are the first element from a consecutive group of elements
6774 for which the corresponding conditions: *(i-1) == *i (for the version of
6775 unique without a predicate argument) or pred(*(i-1), *i) ! = false (for
6776 the version of unique with a predicate argument) [Note: If such a group
6777 of elements consists of only a single element, this is also considered
6778 the first element] [Note: See resolutions of DR 202], call them
6779 s-elements [Note: s...stay], will be placed into a contiguous subrange
6780 of [first, last), denoted by the iterators [first, return value). The
6781 number of elements in the resulting range [first, return value) shall be
6782 equal to the number of s-elements in the original range [first, last).
6783 Invalid iterator arithmetic expressions are expected to be resolved as
6784 proposed in DR submitted by Thomas Mang regarding invalid iterator
6785 arithmetic expressions. It is also assumed by the author that the
6786 relative order of the elements in the resulting subrange [first, return
6787 value) shall be the same as the relative order of the corresponding
6788 elements (the s-elements) in the original range [Note: If this was not
6789 intended behavior, the additional proposed paragraph about stable order
6790 will certainly become obsolete].
6791 Furthermore, the resolutions of DR 202 are partially considered.
6792 </p>
6793
6794 <p>
6795 All implementations known to the author of this Defect Report comply
6796 with this intent [Note: Except possible effects of DR 202]. Since this
6797 intent of the behavior (contrary to the current wording) is also
6798 described in various utility references serving the C++ community [1],
6799 it is not expected that fixing the paragraphs will influence current
6800 code [Note: Except possible effects of DR 202] - unless the code relies
6801 on the behavior as it is described by current wording and the
6802 implementation indeed reflects the current wording, and not the intent.
6803 </p>
6804
6805
6806
6807 <p>3) Proposed fixes:</p>
6808
6809 <p>
6810 Change 25.2.8 [lib.alg.unique], paragraph 1 to:
6811 </p>
6812
6813 <p>
6814 "Effect: Places the first element from every consecutive group of
6815 elements, referred to by the iterator i in the range [first, last), for
6816 which the following conditions hold: *(i-1) == *i (for the version of
6817 unique without a predicate argument) or pred(*(i -1), *i) != false (for
6818 the version of unique with a predicate argument), into the subrange
6819 [first, k) of the original range, where k shall denote a value of type
6820 ForwardIterator."
6821 </p>
6822
6823 <p>Comments to the new wording:</p>
6824
6825 <p>
6826 a) The new wording was influenced by the resolutions of DR 202. If DR
6827 202 is resolved in another way, the proposed wording need also
6828 additional review.
6829 b) "Places" has no special meaning, and the everyday language meaning
6830 should fit.
6831 c) The expression "(i - 1)" was left, but is expected that DR submitted
6832 by Thomas Mang regarding invalid iterator arithmetic expressions will
6833 take this into account.
6834 d) The wording "(for the version of unique without a predicate
6835 argument)" and "(for the version of unique with a predicate argument)"
6836 was added consciously for clarity and is in resemblence with current
6837 23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.
6838 e) The wording "of the original range" might be redundant, since any
6839 subrange starting at first and containing no more elements than the
6840 original range is implicitly a subrange of the original range [first,
6841 last).
6842 f) The iterator k was introduced instead of "return value" in order to
6843 avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The
6844 wording ", where k shall denote a value of type ForwardIterator" might
6845 be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique],
6846 paragraph 2.
6847 g) "Places" does, in the author's opinion, explicitly forbid duplicating
6848 any s-element in the original range [first, last) within the resulting
6849 range [first, k). If there is doubt this term might be not unambiguous
6850 regarding this, it is suggested that k is specified more closely by the
6851 following wording: "k shall denote a value of type ForwardIterator
6852 [Note: See f)] so that k - first is equal to the number of elements in
6853 the original range [first, last) being the first element from every
6854 consecutive group of elements for which the corresponding condition did
6855 hold". This could also be expressed as a separate paragraph
6856 "Postcondition:".
6857 h) If it is considered that the wording is unclear whether it declares
6858 the element of a group which consists of only a single element
6859 implicitly to be the first element of this group [Note: Such an
6860 interpretation could eventually arise especially in case last - first ==
6861 1] , the following additional sentence is proposed: "If such a group of
6862 elements consists of only a single element, this element is also
6863 considered the first element."
6864 </p>
6865
6866 <p>
6867 Change 25.2.8 [lib.alg.unique], paragraph 2 to:
6868 "Returns: The iterator k."
6869 </p>
6870
6871 <p>
6872 Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph
6873 2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8
6874 [lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if
6875 the preceding expressions are used, or the preceding expressions shall
6876 be eliminated if wording inside {} is used):
6877 </p>
6878
6879 <p>
6880 "Notes:{Postcondition:} Stable: the relative order of the elements that
6881 are placed into the subrange [first, return value {k}) shall be the same
6882 as their relative order was in the original range [first, last) prior to
6883 application of the algorithm."
6884 </p>
6885
6886 <p>Comments to the new wording:</p>
6887
6888 <p>
6889 a) It is assumed by the author that the algorithm was intended to be
6890 stable.
6891 In case this was not the intent, this paragraph becomes certainly
6892 obsolete.
6893 b) The wording "was ...  prior to application of the algorithm" is used
6894 to explicitly distinguish the original range not only by means of
6895 iterators, but also by a 'chronological' factor from the resulting range
6896 [first, return value). It might be redundant.
6897 </p>
6898
6899 <p>
6900 25.2.8 [lib.alg.unique], paragraph 3:
6901 </p>
6902 <p>See DR 239.</p>
6903
6904 <p>
6905 4) References to other DRs:
6906 </p>
6907
6908 <p>
6909 See DR 202, but which does not address any of the problems described in
6910 this Defect Report [Note: This DR is supposed to complement DR 202].
6911 See DR 239.
6912 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
6913 expressions.
6914 </p>
6915
6916 <p>
6917 [1]:
6918 The wording of these references is not always unambiguous, and provided
6919 examples partially contradict verbal description of the algorithms,
6920 because the verbal description resembles the problematic wording of
6921 ISO/IEC 14882:2003.
6922 </p>
6923
6924 <p>
6925 [2]:
6926 Illustration of conforming implementations according to current wording:
6927 </p>
6928
6929 <p>
6930 One way the author of this DR considers how this "elimination" could be
6931 achieved by a conforming implementation according to current wording is
6932 by substituting each r-element by _any_ s-element [Note: s...stay; any
6933 non-r-element], since all r-elements are "eliminated".
6934 </p>
6935
6936 <p>
6937 In case of a sequence consisting of elements being all 'equal' [Note:
6938 See DR 202], substituting each r-element by the single s-element is the
6939 only possible solution according to current wording.
6940 </p>
6941
6942
6943 <p><b>Proposed resolution:</b></p>
6944
6945
6946 <p><b>Rationale:</b></p>
6947 <p>The LWG believes the standard is sufficiently clear. No
6948 implementers get it wrong, and changing it wouldn't cause any code to
6949 change, so there is no real-world harm here.</p>
6950
6951
6952
6953
6954
6955 <hr>
6956 <h3><a name="491"></a>491. std::list&lt;&gt;::unique incorrectly specified</h3>
6957 <p><b>Section:</b> 23.2.3.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6958  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
6959 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
6960 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6961 <p><b>Discussion:</b></p>
6962 <p>In Section 23.2.3.4 [list.ops], paragraphs 19 to 21 describe the
6963 behavior of the std::list&lt;T, Allocator&gt;::unique operation. However, the
6964 current wording is defective for various reasons.</p>
6965
6966
6967
6968 <p>
6969 1) Analysis of current wording:
6970 </p>
6971
6972 <p>23.2.3.4 [list.ops], paragraph 19:</p>
6973
6974 <p>
6975 Current wording says:
6976 "Effects:  Eliminates all but the first element from every consecutive
6977 group of equal elements referred to by the iterator i in the range
6978 [first + 1, last) for which *i == *(i - 1) (for the version of unique
6979 with no argument) or pred(*i, *(i -1)) (for the version of unique with a
6980 predicate argument) holds."</p>
6981
6982 <p>
6983 This sentences makes use of the undefined term "Eliminates". Although it
6984 is, to a certain degree, reasonable to consider the term "eliminate"
6985 synonymous with "erase", using "Erase" in the first place, as the
6986 wording of 23.2.3.4 [list.ops], paragraph 15 does, would be clearer.</p>
6987
6988 <p>
6989 The range of the elements referred to by iterator i is "[first + 1,
6990 last)". However, neither "first" nor "last" is defined.</p>
6991
6992 <p>
6993 The sentence makes three times use of iterator arithmetic expressions (
6994 "first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not
6995 defined for bidirectional iterator [see DR submitted by Thomas Mang
6996 regarding invalid iterator arithmetic expressions].</p>
6997
6998 <p>
6999 The same problems as pointed out in DR 202 (equivalence relation / order
7000 of arguments for pred()) apply to this paragraph.</p>
7001
7002 <p>
7003 23.2.3.4 [list.ops], paragraph 20:
7004 </p>
7005
7006 <p>
7007 Current wording says:
7008 "Throws: Nothing unless an exception in thrown by *i == *(i-1) or
7009 pred(*i, *(i - 1))"</p>
7010
7011 <p>
7012 The sentence makes two times use of invalid iterator arithmetic
7013 expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
7014 </p>
7015 <p>
7016 [Note: Minor typos: "in" / missing dot at end of sentence.]
7017 </p>
7018
7019 <p>
7020 23.2.3.4 [list.ops], paragraph 21:</p>
7021
7022 <p>
7023 Current wording says:
7024 "Complexity: If the range (last - first) is not empty, exactly (last -
7025 first) - 1 applications of the corresponding predicate, otherwise no
7026 application of the predicate.</p>
7027
7028 <p>
7029 See DR 315 regarding "(last - first)" not yielding a range.</p>
7030
7031 <p>
7032 Invalid iterator arithmetic expression "(last - first) - 1" left .</p>
7033
7034
7035 <p>2) Description of intended behavior:</p>
7036
7037 <p>
7038 For the rest of this Defect Report, it is assumed that "eliminate" is
7039 supposed to be synonymous to "erase", that "first" is equivalent to an
7040 iterator obtained by a call to begin(), "last" is equivalent to an
7041 iterator obtained by a call to end(), and that all invalid iterator
7042 arithmetic expressions are resolved as described in DR submitted by
7043 Thomas Mang regarding invalid iterator arithmetic expressions.</p>
7044
7045 <p>
7046 Furthermore, the resolutions of DR 202 are considered regarding
7047 equivalence relation and order of arguments for a call to pred.</p>
7048
7049 <p>
7050 All implementations known to the author of this Defect Report comply
7051 with these assumptions, apart from the impact of the alternative
7052 resolution of DR 202. Except for the changes implied by the resolutions
7053 of DR 202, no impact on current code is expected.</p>
7054
7055 <p>
7056 3) Proposed fixes:</p>
7057
7058 <p>
7059 Change 23.2.3.4 [list.ops], paragraph 19 to:</p>
7060
7061 <p>
7062 "Effect: Erases all but the first element from every consecutive group
7063 of elements, referred to by the iterator i in the range [begin(),
7064 end()), for which the following conditions hold: *(i-1) == *i (for the
7065 version of unique with no argument) or pred(*(i-1), *i) != false (for
7066 the version of unique with a predicate argument)."</p>
7067
7068 <p>
7069 Comments to the new wording:</p>
7070
7071 <p>
7072 a) The new wording was influenced by DR 202 and the resolutions
7073 presented there. If DR 202 is resolved in another way, the proposed
7074 wording need also additional review.
7075 b) "Erases" refers in the author's opinion unambiguously to the member
7076 function "erase". In case there is doubt this might not be unamgibuous,
7077 a direct reference to the member function "erase" is suggested [Note:
7078 This would also imply a change of 23.2.3.4 [list.ops], paragraph
7079 15.].
7080 c) The expression "(i - 1)" was left, but is expected that DR submitted
7081 by Thomas Mang regarding invalid iterator arithmetic expressions will
7082 take this into account.
7083 d) The wording "(for the version of unique with no argument)" and "(for
7084 the version of unique with a predicate argument)" was kept consciously
7085 for clarity.
7086 e) "begin()" substitutes "first", and "end()" substitutes "last". The
7087 range need adjustment from "[first + 1, last)" to "[begin(), end())" to
7088 ensure a valid range in case of an empty list.
7089 f) If it is considered that the wording is unclear whether it declares
7090 the element of a group which consists of only a single element
7091 implicitly to be the first element of this group [Note: Such an
7092 interpretation could eventually arise especially in case size() == 1] ,
7093 the following additional sentence is proposed: "If such a group of
7094 elements consists of only a single element, this element is also
7095 considered the first element."</p>
7096
7097 <p>
7098 Change 23.2.3.4 [list.ops], paragraph 20 to:</p>
7099
7100 <p>
7101 "Throws: Nothing unless an exception is thrown by *(i-1) == *i or
7102 pred(*(i-1), *i)."</p>
7103
7104 <p>
7105 Comments to the new wording:</p>
7106
7107 <p>
7108 a) The wording regarding the conditions is identical to proposed
7109 23.2.3.4 [list.ops], paragraph 19. If 23.2.3.4 [list.ops],
7110 paragraph 19 is resolved in another way, the proposed wording need also
7111 additional review.
7112 b) The expression "(i - 1)" was left, but is expected that DR submitted
7113 by Thomas Mang regarding invalid iterator arithmetic expressions will
7114 take this into account.
7115 c) Typos fixed.</p>
7116
7117 <p>
7118 Change 23.2.3.4 [list.ops], paragraph 21 to:</p>
7119
7120 <p>
7121 "Complexity: If empty() == false, exactly size() - 1 applications of the
7122 corresponding predicate, otherwise no applications of the corresponding
7123 predicate."</p>
7124
7125 <p>
7126 Comments to the new wording:</p>
7127
7128 <p>
7129 a) The new wording is supposed to also replace the proposed resolution
7130 of DR 315, which suffers from the problem of undefined "first" / "last".
7131 </p>
7132
7133 <p>
7134 5) References to other DRs:</p>
7135
7136 <p>See DR 202.
7137 See DR 239.
7138 See DR 315.
7139 See DR submitted by Thomas Mang regarding invalid iterator arithmetic
7140 expressions.</p>
7141
7142
7143
7144 <p><b>Proposed resolution:</b></p>
7145
7146
7147 <p><b>Rationale:</b></p>
7148 <p>"All implementations known to the author of this Defect Report
7149 comply with these assumption", and "no impact on current code is
7150 expected", i.e. there is no evidence of real-world confusion or
7151 harm.</p>
7152
7153
7154
7155
7156
7157 <hr>
7158 <h3><a name="493"></a>493. Undefined Expression in Input Iterator Note Title</h3>
7159 <p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7160  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-12-13</p>
7161 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
7162 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7163 <p><b>Discussion:</b></p>
7164 <p>1) In 24.1.1/3, the following text is currently present.</p>
7165
7166 <p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does
7167 not guarantee the substitution property or referential transparency)."</p>
7168
7169 <p>However, when in Table 72, part of the definition of ++r is given as:</p>
7170
7171 <p>"pre: r is dereferenceable.
7172 post: any copies of the previous value of r are no longer required
7173 either to be dereferenceable ..."</p>
7174
7175 <p>While a==b does not imply that b is a copy of a, this statement should
7176 perhaps still be made more clear.</p>
7177
7178 <p>2) There are no changes to intended behaviour</p>
7179
7180 <p>
7181 3) This Note should be altered to say "Note: For input iterators a==b,
7182 when its behaviour is defined ++a==++b may still be false (Equality does
7183 not guarantee the substitution property or referential transparency).</p>
7184
7185
7186
7187 <p><b>Proposed resolution:</b></p>
7188
7189
7190 <p><b>Rationale:</b></p>
7191 <p>This is descriptive text, not normative, and the meaning is clear.</p>
7192
7193
7194
7195
7196
7197 <hr>
7198 <h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3>
7199 <p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7200  <b>Submitter:</b> Hans B os <b>Date:</b> 2004-12-19</p>
7201 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
7202 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7203 <p><b>Discussion:</b></p>
7204 <p>According to [lib.associative.reqmts] table 69, the runtime comlexity
7205 of insert(p, t) and erase(q) can be done in amortized constant time.</p>
7206
7207 <p>It was my understanding that an associative container could be
7208 implemented as a balanced binary tree.</p>
7209
7210 <p>For inser(p, t), you 'll have to iterate to p's next node to see if t
7211 can be placed next to p.  Furthermore, the insertion usually takes
7212 place at leaf nodes. An insert next to the root node will be done at
7213 the left of the root next node</p>
7214
7215 <p>So when p is the root node you 'll have to iterate from the root to
7216 its next node, which  takes O(log(size)) time in a balanced tree.</p>
7217
7218 <p>If you insert all values with insert(root, t) (where root is the
7219 root of the tree before insertion) then each insert takes O(log(size))
7220 time.  The amortized complexity per insertion will be O(log(size))
7221 also.</p>
7222
7223 <p>For erase(q), the normal algorithm for deleting a node that has no
7224 empty left or right subtree, is to iterate to the next (or previous),
7225 which is a leaf node. Then exchange the node with the next and delete
7226 the leaf node.  Furthermore according to DR 130, erase should return
7227 the next node of the node erased.  Thus erasing the root node,
7228 requires iterating to the next node.</p>
7229
7230 <p>Now if you empty a map by deleting the root node until the map is
7231 empty, each operation will take O(log(size)), and the amortized
7232 complexity is still O(log(size)).</p>
7233
7234 <p>The operations can be done in amortized constant time if iterating
7235 to the next node can be done in (non amortized) constant time.  This
7236 can be done by putting all nodes in a double linked list.  This
7237 requires two extra links per node.  To me this is a bit overkill since
7238 you can already efficiently insert or erase ranges with erase(first,
7239 last) and insert(first, last).</p>
7240
7241
7242
7243 <p><b>Proposed resolution:</b></p>
7244
7245
7246 <p><b>Rationale:</b></p>
7247 <p>Only "amortized constant" in special circumstances, and we believe
7248   that's implementable. That is: doing this N times will be O(N), not
7249   O(log N).</p>
7250
7251
7252
7253
7254
7255 <hr>
7256 <h3><a name="499"></a>499. Std. doesn't seem to require stable_sort() to be stable!</h3>
7257 <p><b>Section:</b> 25.3.1.2 [stable.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7258  <b>Submitter:</b> Prateek Karandikar <b>Date:</b> 2005-04-12</p>
7259 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7260 <p><b>Discussion:</b></p>
7261 <blockquote><p>
7262 17.3.1.1 Summary</p>
7263
7264 <p>
7265 1 The Summary provides a synopsis of the category, and introduces the
7266 first-level subclauses. Each subclause also provides a summary, listing
7267 the headers specified in the subclause and the library entities
7268 provided in each header.
7269 </p>
7270 <p>
7271 2 Paragraphs labelled "Note(s):" or "Example(s):" are informative,
7272 other paragraphs are normative.
7273 </p></blockquote>
7274
7275 <p>So this means that a "Notes" paragraph wouldn't be normative. </p>
7276
7277 <blockquote><p>
7278 25.3.1.2 stable_sort
7279 </p>
7280 <pre>template&lt;class RandomAccessIterator&gt;
7281 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last);
7282
7283 template&lt;class RandomAccessIterator, class Compare&gt;
7284 void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
7285 </pre>
7286 <p>
7287 1 Effects: Sorts the elements in the range [first, last).
7288 </p>
7289 <p>
7290 2 Complexity: It does at most N(log N)^2 (where N == last - first)
7291 comparisons; if enough extra memory is available, it is N log N.
7292 </p>
7293 <p>
7294 3 Notes: Stable: the relative order of the equivalent elements is
7295 preserved.
7296 </p></blockquote>
7297
7298 <p>
7299 The Notes para is informative, and nowhere else is stability mentioned above.
7300 </p>
7301
7302 <p>
7303 Also, I just searched for the word "stable" in my copy of the Standard.
7304 and the phrase "Notes: Stable: the relative order of the elements..."
7305 is repeated several times in the Standard library clauses for
7306 describing various functions. How is it that stability is talked about
7307 in the informative paragraph? Or am I missing something obvious?
7308 </p>
7309
7310
7311 <p><b>Proposed resolution:</b></p>
7312 <p>
7313 </p>
7314
7315
7316 <p><b>Rationale:</b></p>
7317 <p>
7318 This change has already been made.
7319 </p>
7320
7321
7322
7323
7324
7325 <hr>
7326 <h3><a name="500"></a>500. do_length cannot be implemented correctly</h3>
7327 <p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7328  <b>Submitter:</b> Krzysztof &#379;elechowski <b>Date:</b> 2005-05-24</p>
7329 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
7330 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7331 <p><b>Discussion:</b></p>
7332 <ol>
7333 <li>codecvt::do_length is of type int;</li>
7334 <li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li>
7335 <li>ptrdiff_t cannot be cast to an int without data loss.</li>
7336 </ol>
7337 <p>
7338 Contradiction.
7339 </p>
7340
7341
7342 <p><b>Proposed resolution:</b></p>
7343 <p>
7344 </p>
7345
7346
7347
7348
7349
7350 <hr>
7351 <h3><a name="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3>
7352 <p><b>Section:</b> 20.5.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7353  <b>Submitter:</b> Me &lt;anti_spam_email2003@yahoo.com&gt; <b>Date:</b> 2005-06-07</p>
7354 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
7355 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7356 <p><b>Discussion:</b></p>
7357 <blockquote><p>
7358 "For templates greater, less, greater_equal, and less_equal,
7359 the specializations for any pointer type yield a total order, even if
7360 the built-in operators &lt;, &gt;, &lt;=, &gt;= do not."
7361 </p></blockquote>
7362
7363 <p>
7364 The standard should do much better than guarantee that these provide a
7365 total order, it should guarantee that it can be used to test if memory
7366 overlaps, i.e. write a portable memmove. You can imagine a platform
7367 where the built-in operators use a uint32_t comparison (this tests for
7368 overlap on this platform) but the less&lt;T*&gt; functor is allowed to be
7369 defined to use a int32_t comparison. On this platform, if you use
7370 std::less with the intent of making a portable memmove, comparison on
7371 an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give
7372 incorrect results.
7373 </p>
7374
7375
7376 <p><b>Proposed resolution:</b></p>
7377 <p>
7378 Add a footnote to 20.5.3/8 saying:
7379 </p>
7380
7381 <blockquote><p>
7382 Given a p1 and p2 such that p1 points to N objects of type T and p2
7383 points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),
7384 less returns the same value when comparing all pointers in [p1,p1+N) to
7385 all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R
7386 such that less returns the same value when comparing all pointers in
7387 [p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when
7388 comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).
7389 For the sake of completeness, the null pointer value (4.10) for T is
7390 considered to be an array of 1 object that doesn't overlap with any
7391 non-null pointer to T. less_equal, greater, greater_equal, equal_to,
7392 and not_equal_to give the expected results based on the total ordering
7393 semantics of less. For T of void, treat it as having similar semantics
7394 as T of char i.e. less&lt;cv T*&gt;(a, b) gives the same results as less&lt;cv
7395 void*&gt;(a, b) which gives the same results as less&lt;cv char*&gt;((cv
7396 char*)(cv void*)a, (cv char*)(cv void*)b).
7397 </p></blockquote>
7398
7399 <p>
7400 I'm also thinking there should be a footnote to 20.5.3/1 saying that if
7401 A and B are similar types (4.4/4), comp&lt;A&gt;(a,b) returns the same value
7402 as comp&lt;B&gt;(a,b) (where comp is less, less_equal, etc.). But this might
7403 be problematic if there is some really funky operator overloading going
7404 on that does different things based on cv (that should be undefined
7405 behavior if somebody does that though). This at least should be
7406 guaranteed for all POD types (especially pointers) that use the
7407 built-in comparison operators.
7408 </p>
7409
7410
7411
7412 <p><b>Rationale:</b></p>
7413 <p>
7414 less is already required to provide a strict weak ordering which is good enough
7415 to detect overlapping memory situations.
7416 </p>
7417
7418
7419
7420
7421
7422 <hr>
7423 <h3><a name="504"></a>504. Integer types in pseudo-random number engine requirements</h3>
7424 <p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7425  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7426 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
7427 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7428 <p><b>Discussion:</b></p>
7429 <p>
7430 In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type,
7431 g is an ... object returning values of unsigned integral type ..."
7432 </p>
7433
7434
7435 <p><b>Proposed resolution:</b></p>
7436 <p>
7437 In 5.1.1 [tr.rand.req], Paragraph 2 replace
7438 </p>
7439
7440 <blockquote><p>
7441 ... s is a value of integral type, g is an lvalue of a type other than X that
7442 defines a zero-argument function object returning values of <del>unsigned integral</del> type
7443 <ins><tt>unsigned long int</tt></ins>,
7444 ...
7445 </p></blockquote>
7446
7447 <p>
7448 In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
7449 </p>
7450
7451 <blockquote><p>
7452 creates an engine with the initial internal state
7453 determined by <ins><tt>static_cast&lt;unsigned long&gt;(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
7454 </p></blockquote>
7455
7456 <p><i>[
7457 Mont Tremblant:  Both s and g should be unsigned long.
7458 This should refer to the constructor signatures. Jens  provided wording post Mont Tremblant.
7459 ]</i></p>
7460
7461
7462 <p><i>[
7463 Berlin:  N1932 adopts the proposed resolution:  see 26.3.1.3/1e and Table 3 row 2. Moved
7464 to Ready.
7465 ]</i></p>
7466
7467
7468
7469
7470 <p><b>Rationale:</b></p>
7471 <p>
7472 Jens:  Just requiring X(unsigned long) still makes it possible
7473 for an evil library writer to also supply a X(int) that does something
7474 unexpected.  The wording above requires that X(s) always performs
7475 as if X(unsigned long) would have been called.  I believe that is
7476 sufficient and implements our intentions from Mont Tremblant.  I
7477 see no additional use in actually requiring a X(unsigned long)
7478 signature.  u.seed(s) is covered by its reference to X(s), same
7479 arguments.
7480 </p>
7481
7482
7483 <p><i>[
7484 Portland:  Subsumed by N2111.
7485 ]</i></p>
7486
7487
7488
7489
7490
7491 <hr>
7492 <h3><a name="506"></a>506. Requirements of Distribution parameter for variate_generator</h3>
7493 <p><b>Section:</b> 26.4 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7494  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7495 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
7496 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7497 <p><b>Discussion:</b></p>
7498 <p>
7499 Paragraph 3 requires that template argument U (which corresponds to template
7500 parameter Engine) satisfy all uniform random number generator requirements.
7501 However, there is no  analogous requirement regarding the template argument
7502 that corresponds to template parameter Distribution.  We believe there should
7503 be, and that it should require that this template argument satisfy all random
7504 distribution requirements.
7505 </p>
7506
7507
7508 <p><b>Proposed resolution:</b></p>
7509 <p>
7510 Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
7511 </p>
7512 <p>
7513 Consequence 2: Add max() and min() functions to those distributions that
7514 do not already have them.
7515 </p>
7516
7517 <p><i>[
7518 Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
7519 Marc supports having min and max to satisfy generic programming interface.
7520 ]</i></p>
7521
7522
7523
7524
7525 <p><b>Rationale:</b></p>
7526 <p>Berlin:  N1932 makes this moot: variate_generator has been eliminated.</p>
7527
7528
7529
7530
7531
7532 <hr>
7533 <h3><a name="509"></a>509. Uniform_int template parameters</h3>
7534 <p><b>Section:</b> 26.4.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7535  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7536 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7537 <p><b>Discussion:</b></p>
7538 <p>
7539 In [tr.rand.dist.iunif] the uniform_int distribution currently has a single
7540 template parameter, IntType, used as the input_type and as the result_type
7541 of the distribution.  We believe there is no reason to conflate these types
7542 in this way.
7543 </p>
7544
7545
7546 <p><b>Proposed resolution:</b></p>
7547 <p>
7548 We recommend that there be a second template  parameter to
7549 reflect the distribution's input_type, and that the existing first template
7550 parameter continue to reflect (solely) the result_type:
7551 </p>
7552 <blockquote><pre>template&lt; class IntType = int, UIntType = unsigned int &gt;
7553 class uniform_int
7554 {
7555 public:
7556   // types
7557   typedef  UIntType  input_type;
7558   typedef  IntType   result_type;
7559 </pre></blockquote>
7560
7561 <p><i>[
7562 Berlin: Moved to NAD.  N1932 makes this moot: the input_type template parameter has been
7563 eliminated.
7564 ]</i></p>
7565
7566
7567
7568
7569
7570
7571
7572 <hr>
7573 <h3><a name="510"></a>510. Input_type for bernoulli_distribution</h3>
7574 <p><b>Section:</b> 26.4.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7575  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7576 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7577 <p><b>Discussion:</b></p>
7578 <p>
7579 In [tr.rand.dist.bern] the distribution currently requires;
7580 </p>
7581 <blockquote><pre>typedef  int  input_type;
7582 </pre></blockquote>
7583
7584
7585 <p><b>Proposed resolution:</b></p>
7586 <p>
7587 We believe this is an unfortunate choice, and recommend instead:
7588 </p>
7589 <blockquote><pre>typedef  unsigned int  input_type;
7590 </pre></blockquote>
7591
7592 <p><i>[
7593 Berlin:  Moved to NAD. N1932 makes this moot: the input_type template parameter has been
7594 eliminated.
7595 ]</i></p>
7596
7597
7598
7599
7600
7601
7602
7603 <hr>
7604 <h3><a name="511"></a>511. Input_type for binomial_distribution</h3>
7605 <p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7606  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7607 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
7608 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7609 <p><b>Discussion:</b></p>
7610 <p>
7611 Unlike all other distributions in TR1, this binomial_distribution has an
7612 implementation-defined  input_type.  We believe this is an unfortunate choice,
7613 because it hinders users from writing portable code.  It also hinders the
7614 writing of compliance tests.  We recommend instead:
7615 </p>
7616 <blockquote><pre>typedef  RealType  input_type;
7617 </pre></blockquote>
7618 <p>
7619 While this choice is somewhat arbitrary (as it was for some of the other
7620 distributions), we make  this particular choice because (unlike all other
7621 distributions) otherwise this template would not publish its RealType
7622 argument and so users could not write generic code that accessed this
7623 second template parameter.  In this respect, the choice is consistent with
7624 the other distributions in  TR1.
7625 </p>
7626 <p>
7627 We have two reasons for recommending that a real type be specified instead.
7628 One reason is  based specifically on characteristics of binomial distribution
7629 implementations, while the other is based on mathematical characteristics of
7630 probability distribution functions in general.
7631 </p>
7632 <p>
7633 Implementations of binomial distributions commonly use Stirling approximations
7634 for values in certain ranges.  It is far more natural to use real values to
7635 represent these approximations than it would be to use integral values to do
7636 so.  In other ranges, implementations reply on the Bernoulli  distribution to
7637 obtain values.  While TR1's bernoulli_distribution::input_type is specified as
7638 int, we believe this would be better specified as double.
7639 </p>
7640 <p>
7641 This brings us to our main point:  The notion of a random distribution rests
7642 on the notion of a cumulative distribution function, which in turn mathematically
7643 depends on a continuous dependent variable.  Indeed, such a distribution function
7644 would be meaningless if it depended on  discrete values such as integers - and this
7645 remains true even if the distribution function were to take discrete steps.
7646 </p>
7647 <p>
7648 Although this note is specifically about binomial_distribution::input_type,
7649 we intend to recommend that all of the random distributions input_types be
7650 specified as a real type (either a RealType template parameter, or double,
7651 as appropriate).
7652 </p>
7653 <p>
7654 Of the nine distributions in TR1, four already have this characteristic
7655 (uniform_real, exponential_distribution, normal_distribution, and
7656 gamma_distribution).  We have already argued the case for the binomial the
7657 remaining four distributions.
7658 </p>
7659 <p>
7660 In the case of uniform_int, we believe that the calculations to produce an
7661 integer result in a  specified range from an integer in a different specified
7662 range is best done using real arithmetic.  This is because it involves a
7663 product, one of whose terms is the ratio of the extents of the two ranges.
7664 Without real arithmetic, the results become less uniform: some numbers become
7665 more  (or less) probable that they should be.  This is, of course, undesireable
7666 behavior in a uniform distribution.
7667 </p>
7668 <p>
7669 Finally, we believe that in the case of the bernoulli_distribution (briefly
7670 mentioned earlier), as well as the cases of the geometric_distribution and the
7671 poisson_distribution, it would be far more natural to have a real input_type.
7672 This is because the most natural computation involves the  random number
7673 delivered and the distribution's parameter p (in the case of bernoulli_distribution,
7674 for example, the computation is a comparison against p), and p is already specified
7675 in each case as having some real type.
7676 </p>
7677
7678
7679 <p><b>Proposed resolution:</b></p>
7680 <blockquote><pre>typedef  RealType  input_type;
7681 </pre></blockquote>
7682
7683 <p><i>[
7684 Berlin:  Moved to NAD.  N1932 makes this moot: the input_type template parameter has been
7685 eliminated.
7686 ]</i></p>
7687
7688
7689
7690
7691
7692
7693 <hr>
7694 <h3><a name="512"></a>512. Seeding subtract_with_carry_01 from a single unsigned long</h3>
7695 <p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7696  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7697 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
7698 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7699 <p><b>Discussion:</b></p>
7700 <p>
7701 Paragraph 8 specifies the algorithm by which a subtract_with_carry_01  engine
7702 is to be seeded given a single unsigned long.  This algorithm is seriously
7703 flawed in the case where the engine parameter w (also known as word_size)
7704 exceeds 31 [bits].  The key part of the paragraph reads:
7705 </p>
7706 <blockquote><p>
7707 sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
7708 </p></blockquote>
7709 <p>
7710 and so forth.
7711 </p>
7712 <p>
7713 Since the specified linear congruential engine, lcg, delivers numbers with
7714 a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
7715 example, 48, each of the x(i) will be less than 2**-17.  The consequence
7716 is that roughly the first 400 numbers delivered will be  conspicuously
7717 close to either zero or one.
7718 </p>
7719 <p>
7720 Unfortunately, this is not an innocuous flaw:  One of the predefined engines
7721 in [tr.rand.predef],  namely ranlux64_base_01, has w = 48 and would exhibit
7722 this poor behavior, while the original N1378 proposal states that these
7723 pre-defined engines are intended to be of "known good properties."
7724 </p>
7725
7726
7727 <p><b>Proposed resolution:</b></p>
7728 <p>
7729 In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
7730 void seed(unsigned long value = 19780503) by
7731 </p>
7732
7733 <blockquote><p>
7734 <i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
7735 case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
7736 <tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
7737 <tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
7738 sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) &#8230; x(-1)</tt>
7739 <ins>as if executing</ins></p>
7740
7741 <blockquote><pre><ins>
7742 linear_congruential&lt;unsigned long, 40014, 0, 2147483563&gt; lcg(value);
7743 seed(lcg);
7744 </ins></pre></blockquote>
7745
7746 <p>
7747 <del>to <tt>(<i>lcg</i>(1) · 2<sup>-<i>w</i></sup>) mod 1
7748 &#8230; (<i>lcg</i>(<i>r</i>) · 2<sup>-<i>w</i></sup>) mod 1</tt>,
7749 respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
7750 else sets carry<tt>(-1) = 0</tt>.</del></p>
7751 </blockquote>
7752
7753 <p><i>[
7754 Jens provided revised wording post Mont Tremblant.
7755 ]</i></p>
7756
7757
7758 <p><i>[
7759 Berlin: N1932 adopts the originally-proposed resolution of the issue.
7760 Jens's supplied wording is a clearer description of what is
7761 intended.  Moved to Ready.
7762 ]</i></p>
7763
7764
7765
7766
7767 <p><b>Rationale:</b></p>
7768 <p>
7769 Jens: I'm using an explicit type here, because fixing the
7770 prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a> even
7771 stricter) requirements we have for seed(Gen&amp;).
7772 </p>
7773
7774 <p><i>[
7775 Portland:  Subsumed by N2111.
7776 ]</i></p>
7777
7778
7779
7780
7781
7782
7783 <hr>
7784 <h3><a name="513"></a>513. Size of state for subtract_with_carry_01</h3>
7785 <p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7786  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7787 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
7788 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7789 <p><b>Discussion:</b></p>
7790 <p>
7791 Paragraph 3 begins:
7792 </p>
7793 <blockquote><p>
7794 The size of the state is r.
7795 </p></blockquote>
7796 <p>
7797 However, this is not quite consistent with the remainder of the paragraph
7798 which specifies a total  of nr+1 items in the textual representation of
7799 the state.  We recommend the sentence be corrected to match:
7800 </p>
7801 <blockquote><p>
7802 The size of the state is nr+1.
7803 </p></blockquote>
7804 <p>
7805 To give meaning to the coefficient n, it may be also desirable to move
7806 n's definition from later in the paragraph.  Either of the following
7807 seem reasonable formulations:
7808 </p>
7809 <blockquote><p>
7810 With n=..., the size of the state is nr+1.
7811 </p></blockquote>
7812 <blockquote><p>
7813 The size of the state is nr+1, where n=... .
7814 </p></blockquote>
7815
7816
7817
7818 <p><b>Proposed resolution:</b></p>
7819 <p><i>[
7820 Jens:  I plead for "NAD" on the grounds that "size of state" is only
7821 used as an argument for big-O complexity notation, thus
7822 constant factors and additions don't count.
7823 ]</i></p>
7824
7825
7826 <p><i>[
7827 Berlin: N1932 adopts the proposed NAD.
7828 ]</i></p>
7829
7830
7831
7832
7833
7834
7835
7836 <hr>
7837 <h3><a name="514"></a>514. Size of state for subtract_with_carry</h3>
7838 <p><b>Section:</b> 26.4.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7839  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7840 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7841 <p><b>Discussion:</b></p>
7842 <p>
7843 Paragraph 2 begins:
7844 </p>
7845 <blockquote><p>
7846 The size of the state is r.
7847 </p></blockquote>
7848 <p>
7849 However, the next sentence specifies a total of r+1 items in the textual
7850 representation of the state,  r specific x's as well as a specific carry.
7851 This makes a total of r+1 items that constitute the size of the state,
7852 rather than r.
7853 </p>
7854
7855
7856 <p><b>Proposed resolution:</b></p>
7857 <p>
7858 We recommend the sentence be corrected to match:
7859 </p>
7860 <blockquote><p>
7861  The size of the state is r+1.
7862 </p></blockquote>
7863
7864 <p><i>[
7865 Jens:  I plead for "NAD" on the grounds that "size of state" is only
7866 used as an argument for big-O complexity notation, thus
7867 constant factors and additions don't count.
7868 ]</i></p>
7869
7870
7871 <p><i>[
7872 Berlin: N1932 adopts the proposed NAD.
7873 ]</i></p>
7874
7875
7876
7877
7878
7879
7880
7881 <hr>
7882 <h3><a name="515"></a>515. Random number engine traits</h3>
7883 <p><b>Section:</b> 26.4.2 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7884  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7885 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
7886 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7887 <p><b>Discussion:</b></p>
7888 <p>
7889 To accompany the concept of a pseudo-random number engine as defined in Table 17,
7890 we propose and recommend an adjunct template, engine_traits, to be declared in
7891 [tr.rand.synopsis] as:
7892 </p>
7893 <blockquote><pre>template&lt; class PSRE &gt;
7894 class engine_traits;
7895 </pre></blockquote>
7896 <p>
7897 This template's primary purpose would be as an aid to generic programming involving
7898 pseudo-random number engines.  Given only the facilities described in tr1, it would
7899 be very difficult to produce any algorithms involving the notion of a generic engine.
7900 The intent of this proposal is to  provide, via engine_traits&lt;&gt;, sufficient
7901 descriptive information to allow an algorithm to employ a pseudo-random number engine
7902 without regard to its exact type, i.e., as a template parameter.
7903 </p>
7904 <p>
7905 For example, today it is not possible to write an efficient generic function that
7906 requires any specific number of random bits.  More specifically, consider a
7907 cryptographic application that internally needs 256 bits of randomness per call:
7908 </p>
7909 <blockquote><pre>template&lt; class Eng, class InIter, class OutIter &gt;
7910 void crypto( Eng&amp; e, InIter in, OutIter out );
7911 </pre></blockquote>
7912 <p>
7913 Without knowning the number of bits of randomness produced per call to a provided
7914 engine, the algorithm has no means of determining how many times to call the engine.
7915 </p>
7916 <p>
7917 In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
7918 template as:
7919 </p>
7920 <blockquote><pre>template&lt; class PSRE &gt;
7921 class engine_traits
7922 {
7923   static  std::size_t  bits_of_randomness = 0u;
7924   static  std::string  name()  { return "unknown_engine"; }
7925   // TODO: other traits here
7926 };
7927 </pre></blockquote>
7928 <p>
7929 Further, each engine described in [tr.rand.engine] would be accompanied by a
7930 complete specialization of this new engine_traits template.
7931 </p>
7932
7933
7934
7935 <p><b>Proposed resolution:</b></p>
7936 <p><i>[
7937 Berlin:  Walter: While useful for implementation per TR1, N1932 has no need for this
7938 feature.  Recommend close as NAD.
7939 ]</i></p>
7940
7941
7942
7943 <p><b>Rationale:</b></p>
7944 <p>
7945 Recommend NAD,
7946 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1932.pdf">N1932</a>,
7947 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
7948 covers this.  Already in WP.
7949 </p>
7950
7951
7952
7953
7954
7955 <hr>
7956 <h3><a name="516"></a>516. Seeding subtract_with_carry_01 using a generator</h3>
7957 <p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7958  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7959 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
7960 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7961 <p><b>Discussion:</b></p>
7962 <p>
7963 Paragraph 6 says:
7964 </p>
7965 <blockquote><p>
7966 ... obtained by successive invocations of g, ...
7967 </p></blockquote>
7968 <p>
7969 We recommend instead:
7970 </p>
7971 <blockquote><p>
7972 ... obtained by taking successive invocations of g mod 2**32, ...
7973 </p></blockquote>
7974 <p>
7975 as the context seems to require only 32-bit quantities be used here.
7976 </p>
7977
7978
7979 <p><b>Proposed resolution:</b></p>
7980 <p>
7981 Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7.  Moved to Ready.
7982 </p>
7983
7984 <p><i>[
7985 Portland:  Subsumed by N2111.
7986 ]</i></p>
7987
7988
7989
7990
7991
7992
7993 <hr>
7994 <h3><a name="517"></a>517. Should include name in external representation</h3>
7995 <p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7996  <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
7997 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
7998 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7999 <p><b>Discussion:</b></p>
8000 <p>
8001 The last two rows of Table 16 deal with the i/o requirements of an engine,
8002 specifying that the textual representation of an engine's state,
8003 appropriately formatted, constitute the engine's  external representation.
8004 </p>
8005 <p>
8006 This seems adequate when an engine's type is known.  However, it seems
8007 inadequate in the  context of generic code, where it becomes useful and
8008 perhaps even necessary to determine an engine's type via input.
8009 </p>
8010 <p>
8011 </p>
8012
8013
8014 <p><b>Proposed resolution:</b></p>
8015 <p>
8016 We therefore recommend that, in each of these two rows of Table 16, the
8017 text "textual representation" be expanded so as to read "engine name
8018 followed by the textual representation."
8019 </p>
8020
8021 <p><i>[
8022 Berlin: N1932 considers this NAD. This is a QOI issue.
8023 ]</i></p>
8024
8025
8026
8027
8028
8029
8030
8031 <hr>
8032 <h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3>
8033 <p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8034  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2005-09-14</p>
8035 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
8036 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8037 <p><b>Discussion:</b></p>
8038 <p>
8039 Problem: There are a number of places in the C++ standard library where
8040 it is possible to write what appear to be sensible ways of calling
8041 functions, but which can cause problems in some (or all)
8042 implementations, as they cause the values given to the function to be
8043 changed in a way not specified in standard (and therefore not coded to
8044 correctly work). These fall into two similar categories.
8045 </p>
8046
8047 <p>
8048 1) Parameters taken by const reference can be changed during execution
8049 of the function
8050 </p>
8051
8052 <p>
8053 Examples:
8054 </p>
8055
8056 <p>
8057 Given std::vector&lt;int&gt; v:
8058 </p>
8059 <p>
8060 v.insert(v.begin(), v[2]);
8061 </p>
8062 <p>
8063 v[2] can be changed by moving elements of vector
8064 </p>
8065
8066
8067 <p>
8068 Given std::list&lt;int&gt; l:
8069 </p>
8070 <p>
8071 l.remove(*l.begin());
8072 </p>
8073 <p>
8074 Will delete the first element, and then continue trying to access it.
8075 This is particularily vicious, as it will appear to work in almost all
8076 cases.
8077 </p>
8078
8079 <p>
8080 2) A range is given which changes during the execution of the function:
8081 Similarly,
8082 </p>
8083
8084 <p>
8085 v.insert(v.begin(), v.begin()+4, v.begin()+6);
8086 </p>
8087
8088 <p>
8089 This kind of problem has been partly covered in some cases. For example
8090 std::copy(first, last, result) states that result cannot be in the range
8091 [first, last). However, does this cover the case where result is a
8092 reverse_iterator built from some iterator in the range [first, last)?
8093 Also, std::copy would still break if result was reverse_iterator(last +
8094 1), yet this is not forbidden by the standard
8095 </p>
8096
8097 <p>
8098 Solution:
8099 </p>
8100
8101 <p>
8102 One option would be to try to more carefully limit the requirements of
8103 each function. There are many functions which would have to be checked.
8104 However as has been shown in the std::copy case, this may be difficult.
8105 A simpler, more global option would be to somewhere insert text similar to:
8106 </p>
8107
8108 <p>
8109 If the execution of any function would change either any values passed
8110 by reference or any value in any range passed to a function in a way not
8111 defined in the definition of that function, the result is undefined.
8112 </p>
8113
8114 <p>
8115 Such code would have to at least cover chapters 23 and 25 (the sections
8116 I read through carefully). I can see no harm on applying it to much of
8117 the rest of the standard.
8118 </p>
8119
8120 <p>
8121 Some existing parts of the standard could be improved to fit with this,
8122 for example the requires for 25.2.1 (Copy) could be adjusted to:
8123 </p>
8124
8125 <p>
8126 Requires: For each non-negative integer n &lt; (last - first), assigning to
8127 *(result + n) must not alter any value in the range [first + n, last).
8128 </p>
8129
8130 <p>
8131 However, this may add excessive complication.
8132 </p>
8133
8134 <p>
8135 One other benefit of clearly introducing this text is that it would
8136 allow a number of small optimisations, such as caching values passed
8137 by const reference.
8138 </p>
8139
8140 <p>
8141 Matt Austern adds that this issue also exists for the <tt>insert</tt> and
8142 <tt>erase</tt> members of the ordered and unordered associative containers.
8143 </p>
8144
8145 <p><i>[
8146 Berlin: Lots of controversey over how this should be solved. Lots of confusion
8147 as to whether we're talking about self referencing iterators or references.
8148 Needs a good survey as to the cases where this matters, for which
8149 implementations, and how expensive it is to fix each case.
8150 ]</i></p>
8151
8152
8153
8154
8155 <p><b>Proposed resolution:</b></p>
8156
8157
8158 <p><b>Rationale:</b></p>
8159 <p>
8160 Recommend NAD.
8161 </p>
8162 <ul>
8163 <li><tt>vector::insert(iter, value)</tt> is required to work because the standard
8164 doesn't give permission for it not to work.</li>
8165 <li><tt>list::remove(value)</tt> is required to work because the standard
8166 doesn't give permission for it not to work.</li>
8167 <li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because
8168 23.1.1 [sequence.reqmts], p4 says so.</li>
8169 <li><tt>copy</tt> has to work, except where 25.2.1 [alg.copy] says
8170 it doesn't have to work.  While a language lawyer can tear this wording apart,
8171 it is felt that the wording is not prone to accidental interpretation.</li>
8172 <li>The current working draft provide exceptions for the unordered associative
8173 containers similar to the containers requirements which exempt the member
8174 template insert functions from self referencing.</li>
8175 </ul>
8176
8177
8178
8179
8180
8181 <hr>
8182 <h3><a name="532"></a>532. Tuple comparison</h3>
8183 <p><b>Section:</b> 20.3.1.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
8184  <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-11-29</p>
8185 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
8186 <p><b>Discussion:</b></p>
8187 <p>
8188 Where possible, tuple comparison operators &lt;,&lt;=,=&gt;, and &gt; ought to be
8189 defined in terms of std::less rather than operator&lt;, in order to
8190 support comparison of tuples of pointers.
8191 </p>
8192
8193
8194 <p><b>Proposed resolution:</b></p>
8195 <p>
8196 change 6.1.3.5/5 from:
8197 </p>
8198
8199 <blockquote><p>
8200   Returns: The result of a lexicographical comparison between t and
8201   u. The result is defined as: (bool)(get&lt;0&gt;(t) &lt; get&lt;0&gt;(u)) ||
8202   (!(bool)(get&lt;0&gt;(u) &lt; get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for
8203   some tuple r is a tuple containing all but the first element of
8204   r. For any two zero-length tuples e and f, e &lt; f returns false.
8205 </p></blockquote>
8206
8207 <p>
8208 to:
8209 </p>
8210
8211 <blockquote>
8212 <p>
8213   Returns: The result of a lexicographical comparison between t and
8214   u. For any two zero-length tuples e and f, e &lt; f returns false.
8215   Otherwise, the result is defined as: cmp( get&lt;0&gt;(t), get&lt;0&gt;(u)) ||
8216   (!cmp(get&lt;0&gt;(u), get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for some
8217   tuple r is a tuple containing all but the first element of r, and
8218   cmp(x,y) is an unspecified function template defined as follows.
8219 </p>
8220 <p>
8221   Where T is the type of x and U is the type of y:
8222 </p>
8223
8224 <p>
8225      if T and U are pointer types and T is convertible to U, returns
8226      less&lt;U&gt;()(x,y)
8227 </p>
8228
8229 <p>
8230      otherwise, if T and U are pointer types, returns less&lt;T&gt;()(x,y)
8231 </p>
8232
8233 <p>
8234      otherwise, returns (bool)(x &lt; y)
8235 </p>
8236 </blockquote>
8237
8238 <p><i>[
8239 Berlin: This issue is much bigger than just tuple (pair, containers,
8240 algorithms). Dietmar will survey and work up proposed wording.
8241 ]</i></p>
8242
8243
8244
8245
8246 <p><b>Rationale:</b></p>
8247 <p>
8248 Recommend NAD.  This will be fixed with the next revision of concepts.
8249 </p>
8250
8251
8252
8253
8254
8255 <hr>
8256 <h3><a name="536"></a>536. Container iterator constructor and explicit convertibility</h3>
8257 <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
8258  <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2005-12-17</p>
8259 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
8260 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
8261 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8262 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a></p>
8263 <p><b>Discussion:</b></p>
8264 <p>
8265 The iterator constructor X(i,j) for containers as defined in 23.1.1 and
8266 23.2.2 does only require that i and j be input iterators but
8267 nothing is said about their associated value_type. There are three
8268 sensible
8269 options:
8270 </p>
8271 <ol>
8272 <li>iterator's value_type is exactly X::value_type (modulo cv).</li>
8273 <li>iterator's value_type is *implicitly* convertible to X::value_type.</li>
8274 <li>iterator's value_type is *explicitly* convertible to X::value_type.</li>
8275 </ol>
8276 <p>
8277 The issue has practical implications, and stdlib vendors have
8278 taken divergent approaches to it: Dinkumware follows 2,
8279 libstdc++ follows 3.
8280 </p>
8281 <p>
8282 The same problem applies to the definition of insert(p,i,j) for
8283 sequences and insert(i,j) for associative contianers, as well as
8284 assign.
8285 </p>
8286
8287 <p><i>[
8288 The following added by Howard and the example code was originally written by
8289 Dietmar.
8290 ]</i></p>
8291
8292 <p>
8293 Valid code below?
8294 </p>
8295
8296 <blockquote><pre>#include &lt;vector&gt;
8297 #include &lt;iterator&gt;
8298 #include &lt;iostream&gt;
8299
8300 struct foo
8301 {
8302     explicit foo(int) {}
8303 };
8304
8305 int main()
8306 {
8307     std::vector&lt;int&gt; v_int;
8308     std::vector&lt;foo&gt; v_foo1(v_int.begin(), v_int.end());
8309     std::vector&lt;foo&gt; v_foo2((std::istream_iterator&lt;int&gt;(std::cin)),
8310                              std::istream_iterator&lt;int&gt;());
8311 }
8312 </pre></blockquote>
8313 <p><i>[
8314 Berlin: Some support, not universal, for respecting the explicit qualifier.
8315 ]</i></p>
8316
8317
8318
8319
8320 <p><b>Proposed resolution:</b></p>
8321
8322
8323
8324
8325
8326
8327 <hr>
8328 <h3><a name="544"></a>544. minor NULL problems in C.2</h3>
8329 <p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8330  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-25</p>
8331 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8332 <p><b>Discussion:</b></p>
8333 <p>
8334 According to C.2.2.3, p1, "the macro NULL, defined in any of &lt;clocale&gt;,
8335 &lt;cstddef&gt;, &lt;cstdio&gt;, &lt;cstdlib&gt;, &lt;cstring&gt;, &lt;ctime&gt;,
8336 or &lt;cwchar&gt;." This is consistent with the C standard.
8337 </p>
8338 <p>
8339 However, Table 95 in C.2 fails to mention &lt;clocale&gt; and &lt;cstdlib&gt;.
8340 </p>
8341 <p>
8342 In addition, C.2, p2 claims that "The C++ Standard library provides
8343 54 standard macros from the C library, as shown in Table 95." While
8344 table 95 does have 54 entries, since a couple of them (including the
8345 NULL macro) are listed more than once, the actual number of macros
8346 defined by the C++ Standard Library may not be 54.
8347 </p>
8348
8349
8350 <p><b>Proposed resolution:</b></p>
8351 <p>
8352 I propose we add &lt;clocale&gt; and &lt;cstdlib&gt; to Table 96 and remove the
8353 number of macros from C.2, p2 and reword the sentence as follows:
8354 </p>
8355 <blockquote><p>
8356 The C++ Standard library <del>provides 54 standard macros from</del>
8357 <ins>defines a number macros corresponding to those defined by</ins> the C
8358 <ins>Standard</ins> library, as shown in Table 96.
8359 </p></blockquote>
8360
8361 <p><i>[
8362 Portland:  Resolution is considered editorial.  It will be incorporated into the WD.
8363 ]</i></p>
8364
8365
8366
8367
8368
8369
8370
8371 <hr>
8372 <h3><a name="547"></a>547. division should be floating-point, not integer</h3>
8373 <p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8374  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
8375 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
8376 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8377 <p><b>Discussion:</b></p>
8378 <p>
8379 Paragraph 10 describes how a variate generator uses numbers produced by an
8380 engine to pass to a generator. The sentence that concerns me is: "Otherwise, if
8381 the value for engine_value_type::result_type is true and the value for
8382 Distribution::input_type is false [i.e. if the engine produces integers and the
8383 engine wants floating-point values], then the numbers in s_eng are divided by
8384 engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the
8385 engine is producing integers, both the numerator and the denominator are
8386 integers and we'll be doing integer division, which I don't think is what we
8387 want. Shouldn't we be performing a conversion to a floating-point type first?
8388 </p>
8389
8390
8391 <p><b>Proposed resolution:</b></p>
8392
8393
8394 <p><b>Rationale:</b></p>
8395 <p>
8396 Recommend NAD as the affected section is now gone and so the issue is moot.
8397 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>.
8398 </p>
8399
8400
8401
8402
8403
8404 <hr>
8405 <h3><a name="549"></a>549. Undefined variable in binomial_distribution</h3>
8406 <p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8407  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
8408 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
8409 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8410 <p><b>Discussion:</b></p>
8411 <p>
8412 Paragraph 1 says that "A binomial distributon random distribution produces
8413 integer values i&gt;0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and
8414 p are the parameters of the distribution. OK, that tells us what t, p, and i
8415 are. What's n?
8416 </p>
8417
8418
8419 <p><b>Proposed resolution:</b></p>
8420 <p>
8421 Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
8422 </p>
8423
8424 <p><i>[
8425 Portland:  Subsumed by N2111.
8426 ]</i></p>
8427
8428
8429
8430
8431
8432
8433 <hr>
8434 <h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3>
8435 <p><b>Section:</b> 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
8436  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-01-30</p>
8437 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
8438 <p><b>Discussion:</b></p>
8439 <p>
8440 In the synopsis, some types are identified as optional: int8_t, int16_t,
8441 and so on, consistently with C99, indeed.
8442 </p>
8443 <p>
8444 On the other hand, intptr_t and uintptr_t, are not marked as such and
8445 probably should, consistently with C99, 7.18.1.4.
8446 </p>
8447
8448
8449 <p><b>Proposed resolution:</b></p>
8450 <p>
8451 Change 18.3.1 [cstdint.syn]:
8452 </p>
8453
8454 <blockquote><pre>...
8455 typedef <i>signed integer type</i> intptr_t;    <ins><i>// optional</i></ins>
8456 ...
8457 typedef <i>unsigned integer type</i> uintptr_t;    <ins><i>// optional</i></ins>
8458 ...
8459 </pre></blockquote>
8460
8461
8462
8463 <p><b>Rationale:</b></p>
8464 Recommend NAD and fix as editorial with the proposed resolution.
8465
8466
8467
8468
8469
8470 <hr>
8471 <h3><a name="554"></a>554. Problem with lwg DR 184 numeric_limits&lt;bool&gt;</h3>
8472 <p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8473  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-29</p>
8474 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
8475 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8476 <p><b>Discussion:</b></p>
8477 <p>
8478 I believe we have a bug in the resolution of:
8479 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a>
8480 (WP status).
8481 </p>
8482
8483 <p>
8484 The resolution spells out each member of <tt>numeric_limits&lt;bool&gt;</tt>.
8485 The part I'm having a little trouble with is:
8486 </p>
8487 <blockquote><pre>static const bool traps = false;
8488 </pre></blockquote>
8489
8490 <p>
8491 Should this not be implementation defined?  Given:
8492 </p>
8493
8494 <blockquote><pre>int main()
8495 {
8496      bool b1 = true;
8497      bool b2 = false;
8498      bool b3 = b1/b2;
8499 }
8500 </pre></blockquote>
8501
8502 <p>
8503 If this causes a trap, shouldn't <tt>numeric_limits&lt;bool&gt;::traps</tt> be
8504 <tt>true</tt>?
8505 </p>
8506
8507
8508 <p><b>Proposed resolution:</b></p>
8509 <p>
8510 Change 18.2.1.5p3:
8511 </p>
8512
8513 <blockquote><p>
8514 -3- The specialization for <tt>bool</tt> shall be provided as follows: </p>
8515 <blockquote><pre>namespace std {
8516    template &lt;&gt; class numeric_limits&lt;bool&gt; {
8517       ...
8518       static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>;
8519       ...
8520    };
8521 }
8522 </pre></blockquote>
8523 </blockquote>
8524
8525 <p><i>[
8526 Redmond:  NAD because traps refers to values, not operations.  There is no bool
8527 value that will trap.
8528 ]</i></p>
8529
8530
8531
8532
8533
8534
8535
8536 <hr>
8537 <h3><a name="555"></a>555. TR1, 8.21/1: typo</h3>
8538 <p><b>Section:</b> TR1 8.21 [tr.c99.boolh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8539  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-02</p>
8540 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8541 <p><b>Discussion:</b></p>
8542 <p>
8543 This one, if nobody noticed it yet, seems really editorial:
8544 s/cstbool/cstdbool/
8545 </p>
8546
8547
8548 <p><b>Proposed resolution:</b></p>
8549 <p>
8550 Change 8.21p1:
8551 </p>
8552 <blockquote><p>
8553 -1- The header behaves as if it defines the additional macro defined in
8554 <tt>&lt;cst<ins>d</ins>bool&gt;</tt> by including the header <tt>&lt;cstdbool&gt;</tt>.
8555 </p></blockquote>
8556
8557 <p><i>[
8558 Redmond:  Editorial.
8559 ]</i></p>
8560
8561
8562
8563
8564
8565
8566
8567 <hr>
8568 <h3><a name="558"></a>558. lib.input.iterators Defect</h3>
8569 <p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8570  <b>Submitter:</b> David Abrahams <b>Date:</b> 2006-02-09</p>
8571 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
8572 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8573 <p><b>Discussion:</b></p>
8574 <blockquote>
8575 <p>
8576   24.1.1 Input iterators [lib.input.iterators]
8577 </p>
8578 <p>
8579   1 A class or a built-in type X satisfies the requirements of an
8580   input iterator for the value type T if the following expressions are
8581   valid, where U is the type of any specified member of type T, as
8582   shown in Table 73.
8583 </p>
8584 </blockquote>
8585 <p>
8586 There is no capital U used in table 73.  There is a lowercase u, but
8587 that is clearly not meant to denote a member of type T.  Also, there's
8588 no description in 24.1.1 of what lowercase a means.  IMO the above
8589 should have been...Hah, a and b are already covered in 24.1/11, so maybe it
8590 should have just been:
8591 </p>
8592
8593
8594 <p><b>Proposed resolution:</b></p>
8595 <p>
8596 Change 24.1.1p1:
8597 </p>
8598 <blockquote><p>
8599 -1- A class or a built-in type <tt>X</tt> satisfies the requirements of an
8600 input iterator for the value type <tt>T</tt> if the following expressions
8601 are valid<del>, where <tt>U</tt> is the type of any specified member of type
8602 <tt>T</tt>,</del> as shown in Table 73.
8603 </p></blockquote>
8604
8605 <p><i>[
8606 Portland: Editorial.
8607 ]</i></p>
8608
8609
8610
8611
8612
8613
8614
8615 <hr>
8616 <h3><a name="560"></a>560. User-defined allocators without default constructor</h3>
8617 <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8618  <b>Submitter:</b> Sergey P. Derevyago <b>Date:</b> 2006-02-17</p>
8619 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
8620 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
8621 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8622 <p><b>Discussion:</b></p>
8623 <h4>1. The essence of the problem.</h4>
8624 <p>
8625 User-defined allocators without default constructor are not explicitly
8626 supported by the standard but they can be supported just like std::vector
8627 supports elements without default constructor.
8628 </p>
8629 <p>
8630 As a result, there exist implementations that work well with such allocators
8631 and implementations that don't.
8632 </p>
8633
8634 <h4>2. The cause of the problem.</h4>
8635 <p>
8636 1) The standard doesn't explicitly state this intent but it should. In
8637 particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator
8638 instances that compare non-equal. So it can similarly state the intent w.r.t.
8639 the user-defined allocators without default constructor.
8640 </p>
8641 <p>
8642 2) Some container operations are obviously underspecified. In particular,
8643 21.3.7.1p2 tells:
8644 </p>
8645 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
8646   basic_string&lt;charT,traits,Allocator&gt; operator+(
8647     const charT* lhs,
8648     const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs
8649   );
8650 </pre>
8651 <p>
8652 Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs) + rhs</tt>.
8653 </p>
8654 </blockquote>
8655 <p>
8656 That leads to the basic_string&lt;charT,traits,Allocator&gt;(lhs, Allocator()) call.
8657 Obviously, the right requirement is:
8658 </p>
8659 <blockquote><p>
8660 Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs, rhs.get_allocator()) + rhs</tt>.
8661 </p></blockquote>
8662 <p>
8663 It seems like a lot of DRs can be submitted on this "Absent call to
8664 get_allocator()" topic.
8665 </p>
8666
8667 <h4>3. Proposed actions.</h4>
8668 <p>
8669 1) Explicitly state the intent to allow for user-defined allocators without
8670 default constructor in 20.1.5 Allocator requirements.
8671 </p>
8672 <p>
8673 2) Correct all the places, where a correct allocator object is available
8674 through the get_allocator() call but default Allocator() gets passed instead.
8675 </p>
8676 <h4>4. Code sample.</h4>
8677 <p>
8678 Let's suppose that the following memory pool is available:
8679 </p>
8680 <blockquote><pre>class mem_pool {
8681       // ...
8682       void* allocate(size_t size);
8683       void deallocate(void* ptr, size_t size);
8684 };
8685 </pre></blockquote>
8686 <p>
8687 So the following allocator can be implemented via this pool:
8688 </p>
8689 <blockquote><pre>class stl_allocator {
8690       mem_pool&amp; pool;
8691
8692  public:
8693       explicit stl_allocator(mem_pool&amp; mp) : pool(mp) {}
8694       stl_allocator(const stl_allocator&amp; sa) : pool(sa.pool) {}
8695       template &lt;class U&gt;
8696       stl_allocator(const stl_allocator&lt;U&gt;&amp; sa)  : pool(sa.get_pool()) {}
8697       ~stl_allocator() {}
8698
8699       pointer allocate(size_type n, std::allocator&lt;void&gt;::const_pointer = 0)
8700       {
8701        return (n!=0) ? static_cast&lt;pointer&gt;(pool.allocate(n*sizeof(T))) : 0;
8702       }
8703
8704       void deallocate(pointer p, size_type n)
8705       {
8706        if (n!=0) pool.deallocate(p, n*sizeof(T));
8707       }
8708
8709       // ...
8710 };
8711 </pre></blockquote>
8712 <p>
8713 Then the following code works well on some implementations and doesn't work on
8714 another:
8715 </p>
8716 <blockquote><pre>typedef basic_string&lt;char, char_traits&lt;char&gt;, stl_allocator&lt;char&gt; &gt;
8717   tl_string;
8718 mem_pool mp;
8719 tl_string s1("abc", stl_allocator&lt;int&gt;(mp));
8720 printf("(%s)\n", ("def"+s1).c_str());
8721 </pre></blockquote>
8722 <p>
8723 In particular, on some implementations the code can't be compiled without
8724 default stl_allocator() constructor.
8725 </p>
8726 <p>
8727 The obvious way to solve the compile-time problems is to intentionally define
8728 a NULL pointer dereferencing default constructor
8729 </p>
8730 <blockquote><pre>stl_allocator() : pool(*static_cast&lt;mem_pool*&gt;(0)) {}
8731 </pre></blockquote>
8732 <p>
8733 in a hope that it will not be called. The problem is that it really gets
8734 called by operator+(const char*, const string&amp;) under the current 21.3.7.1p2
8735 wording.
8736 </p>
8737
8738
8739 <p><b>Proposed resolution:</b></p>
8740 <p>
8741 </p>
8742
8743
8744 <p><b>Rationale:</b></p>
8745 <p>
8746 Recommend NAD.  <tt>operator+()</tt> with <tt>string</tt> already requires the desired
8747 semantics of copying the allocator from one of the strings (<i>lhs</i> when there is a choice).
8748 </p>
8749
8750
8751
8752
8753
8754 <hr>
8755 <h3><a name="569"></a>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</h3>
8756 <p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
8757  <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-03-10</p>
8758 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
8759 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8760 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a></p>
8761 <p><b>Discussion:</b></p>
8762 <p>
8763 Section: 27.4.4.3 [lib.iostate.flags]
8764 </p>
8765 <p>
8766 Paragraph 4 says:
8767 </p>
8768 <blockquote>
8769 <blockquote><pre>void clear(iostate <i>state</i> = goodbit);
8770 </pre></blockquote>
8771 <p>
8772 <i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt>
8773 otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>.
8774 </p>
8775 </blockquote>
8776
8777 <p>
8778 The postcondition "rdstate()==state|ios_base::badbit" is parsed as
8779 "(rdstate()==state)|ios_base::badbit", which is probably what the
8780 committee meant.
8781 </p>
8782
8783
8784
8785
8786 <p><b>Rationale:</b></p>
8787
8788
8789
8790
8791
8792
8793 <hr>
8794 <h3><a name="571"></a>571. Update C90 references to C99?</h3>
8795 <p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
8796  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-08</p>
8797 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
8798 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
8799 <p><b>Discussion:</b></p>
8800 <p>
8801 1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC
8802 9899:1990, Programming languages - C. Should that be changed to ISO/IEC
8803 9899:1999?
8804 </p>
8805 <p>
8806 What impact does this have on the library?
8807 </p>
8808
8809
8810 <p><b>Proposed resolution:</b></p>
8811 <p>
8812 In 1.2/1 [intro.refs] of the WP, change:
8813 </p>
8814 <blockquote>
8815 <ul>
8816 <li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i></li>
8817 </ul>
8818 </blockquote>
8819
8820
8821
8822 <p><b>Rationale:</b></p>
8823 Recommend NAD, fixed editorially.
8824
8825
8826
8827
8828
8829 <hr>
8830 <h3><a name="572"></a>572. Oops, we gave 507 WP status</h3>
8831 <p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8832  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-04-11</p>
8833 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
8834 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8835 <p><b>Discussion:</b></p>
8836 <p>
8837 In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot:
8838 variate_generator has been eliminated.  Then in full committee we voted to give
8839 this issue WP status (mistakenly).
8840 </p>
8841
8842
8843 <p><b>Proposed resolution:</b></p>
8844 <p>
8845 Strike the proposed resolution of issue 507.
8846 </p>
8847 <p><i>[
8848 post-Portland:  Walter and Howard recommend NAD.  The proposed resolution of 507 no longer
8849 exists in the current WD.
8850 ]</i></p>
8851
8852
8853
8854 <p><b>Rationale:</b></p>
8855 <p>
8856 NAD.  Will be moot once
8857 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf">N2135</a>
8858 is adopted.
8859 </p>
8860
8861
8862
8863
8864
8865 <hr>
8866 <h3><a name="587"></a>587. iststream ctor missing description</h3>
8867 <p><b>Section:</b> D.7.2.1 [depr.istrstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8868  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p>
8869 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8870 <p><b>Discussion:</b></p>
8871         <p>
8872
8873 The  <code>iststream(char*, streamsize)</code>  ctor is  in  the class
8874 synopsis  in D.7.2  but its  signature is  missing in  the description
8875 below (in D.7.2.1).
8876
8877         </p>
8878
8879
8880     <p><b>Proposed resolution:</b></p>
8881         <p>
8882
8883 This seems like a simple editorial issue and the missing signature can
8884 be added to the one for <code>const char*</code> in paragraph 2.
8885
8886         </p>
8887
8888 <p><i>[
8889 post Oxford: Noted that it is already fixed in
8890 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
8891 ]</i></p>
8892
8893
8894
8895
8896
8897
8898 <hr>
8899 <h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3>
8900 <p><b>Section:</b> 20.4 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
8901  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-08-10</p>
8902 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
8903 <p><b>Discussion:</b></p>
8904 <p>
8905 20.4.9 [lib.meta.req], Implementation requirements, provides latitude for type
8906 traits implementers that is not needed in C++0x. It includes the wording:
8907 </p>
8908
8909 <blockquote><p>
8910 [<i>Note:</i> the latitude granted to implementers in this clause is temporary,
8911 and is expected to be removed in future revisions of this document. -- <i>end note</i>]
8912 </p></blockquote>
8913
8914 <p>
8915 Note:
8916 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">N2157: Minor Modifications to the type traits Wording</a>
8917 also has the intent of removing this wording from the WP.
8918 </p>
8919
8920
8921
8922 <p><b>Proposed resolution:</b></p>
8923 <p>
8924 Remove 20.4.9 [lib.meta.req] in its entirety from the WP.
8925 </p>
8926
8927 <p><i>[
8928 post-Oxford: Recommend NAD Editorial.  This resolution is now in the
8929 current working draft.
8930 ]</i></p>
8931
8932
8933
8934
8935
8936
8937
8938 <hr>
8939 <h3><a name="591"></a>591. Misleading "built-in</h3>
8940 <p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
8941  <b>Submitter:</b> whyglinux <b>Date:</b> 2006-08-08</p>
8942 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
8943 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
8944 <p><b>Discussion:</b></p>
8945 <p>
8946 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
8947 Paragraph 7:
8948 </p>
8949 <blockquote><p>
8950 "For built-in integer types, the number of non-sign bits in the
8951 representation."
8952 </p></blockquote>
8953
8954 <p>
8955 26.1 Numeric type requirements [lib.numeric.requirements]
8956 Footnote:
8957 </p>
8958
8959 <blockquote><p>
8960 "In other words, value types. These include built-in arithmetic types,
8961 pointers, the library class complex, and instantiations of valarray for
8962 value types."
8963 </p></blockquote>
8964
8965 <p>
8966 Integer types (which are bool, char, wchar_t, and the signed and
8967 unsigned integer types) and arithmetic types (which are integer and
8968 floating types) are all built-in types and thus there are no
8969 non-built-in (that is, user-defined) integer or arithmetic types. Since
8970 the redundant "built-in" in the above 2 sentences can mislead that
8971 there may be built-in or user-defined integer and arithmetic types
8972 (which is not correct), the "built-in" should be removed.
8973 </p>
8974
8975
8976 <p><b>Proposed resolution:</b></p>
8977 <p>
8978 18.2.1.2 numeric_limits members [lib.numeric.limits.members]
8979 Paragraph 7:
8980 </p>
8981 <blockquote><p>
8982 "For <del>built-in</del> integer types, the number of non-sign bits in the
8983 representation."
8984 </p></blockquote>
8985
8986 <p>
8987 26.1 Numeric type requirements [lib.numeric.requirements]
8988 Footnote:
8989 </p>
8990
8991 <blockquote><p>
8992 "In other words, value types. These include <del>built-in</del> arithmetic types,
8993 pointers, the library class complex, and instantiations of valarray for
8994 value types."
8995 </p></blockquote>
8996
8997
8998 <p><b>Rationale:</b></p>
8999 <p>
9000 Recommend NAD / Editorial.  The proposed resolution is accepted as editorial.
9001 </p>
9002
9003
9004
9005
9006
9007 <hr>
9008 <h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</h3>
9009 <p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
9010  <b>Submitter:</b> Niels Dekker <b>Date:</b> 2006-11-02</p>
9011 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
9012 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9013 <p><b>Discussion:</b></p>
9014 <p>
9015 It seems undesirable to define the Swappable requirement in terms of
9016 CopyConstructible and Assignable requirements. And likewise, once the
9017 MoveConstructible and MoveAssignable requirements (N1860) have made it
9018 into the Working Draft, it seems undesirable to define the Swappable
9019 requirement in terms of those requirements. Instead, it appears
9020 preferable to have the Swappable requirement defined exclusively in
9021 terms of the existence of an appropriate swap function.
9022 </p>
9023 <p>
9024 Section 20.1.4 [lib.swappable] of the current Working Draft (N2009)
9025 says:
9026 </p>
9027 <blockquote><p>
9028 The Swappable requirement is met by satisfying one or more of the
9029 following conditions:</p>
9030 <ul>
9031 <li>
9032 T is Swappable if T satisfies the CopyConstructible requirements
9033 (20.1.3) and the Assignable requirements (23.1);
9034 </li>
9035 <li>
9036 T is Swappable if a namespace scope function named swap exists in the
9037 same namespace as the definition of T, such that the expression
9038 swap(t,u) is valid and has the semantics described in Table 33.
9039 </li>
9040 </ul>
9041 </blockquote>
9042 I can think of three disadvantages of this definition:
9043 <ol>
9044 <li>
9045 If a client's type T satisfies the first condition (T is both
9046 CopyConstructible and Assignable), the client cannot stop T from
9047 satisfying the Swappable requirement without stopping T from
9048 satisfying the first condition.
9049 <p>
9050 A client might want to stop T from satisfying the Swappable
9051 requirement, because swapping by means of copy construction and
9052 assignment might throw an exception, and she might find a throwing
9053 swap unacceptable for her type. On the other hand, she might not feel
9054 the need to fully implement her own swap function for this type. In
9055 this case she would want to be able to simply prevent algorithms that
9056 would swap objects of type T from being used, e.g., by declaring a
9057 swap function for T, and leaving this function purposely undefined.
9058 This would trigger a link error, if an attempt would be made to use
9059 such an algorithm for this type. For most standard library
9060 implementations, this practice would indeed have the effect of
9061 stopping T from satisfying the Swappable requirement.
9062 </p>
9063 </li>
9064 <li>
9065 A client's type T that does not satisfy the first condition can not be
9066 made Swappable by providing a specialization of std::swap for T.
9067 <p>
9068 While I'm aware about the fact that people have mixed feelings about
9069 providing a specialization of std::swap, it is well-defined to do so.
9070 It sounds rather counter-intuitive to say that T is not Swappable, if
9071 it has a valid and semantically correct specialization of std::swap.
9072 Also in practice, providing such a specialization will have the same
9073 effect as satisfying the Swappable requirement.
9074 </p>
9075 </li>
9076 <li>
9077 For a client's type T that satisfies both conditions of the Swappable
9078 requirement, it is not specified which of the two conditions prevails.
9079 After reading section 20.1.4 [lib.swappable], one might wonder whether
9080 objects of T will be swapped by doing copy construction and
9081 assignments, or by calling the swap function of T.
9082 <p>
9083 I'm aware that the intention of the Draft is to prefer calling the
9084 swap function of T over doing copy construction and assignments. Still
9085 in my opinion, it would be better to make this clear in the wording of
9086 the definition of Swappable.
9087 </p>
9088 </li>
9089 </ol>
9090 <p>
9091 I would like to have the Swappable requirement defined in such a way
9092 that the following code fragment will correctly swap two objects of a
9093 type T, if and only if T is Swappable:
9094 </p>
9095 <pre>   using std::swap;
9096    swap(t, u);  // t and u are of type T.
9097 </pre>
9098 <p>
9099 This is also the way Scott Meyers recommends calling a swap function,
9100 in Effective C++, Third Edition, item 25.
9101 </p>
9102 <p>
9103 Most aspects of this issue have been dealt with in a discussion on
9104 comp.std.c++ about the Swappable requirement, from 13 September to 4
9105 October 2006, including valuable input by David Abrahams, Pete Becker,
9106 Greg Herlihy, Howard Hinnant and others.
9107 </p>
9108
9109 <p><b>Proposed resolution:</b></p>
9110 <p>
9111 Change section 20.1.4 [lib.swappable] as follows:
9112 </p>
9113 <blockquote><p>
9114 The Swappable requirement is met by satisfying
9115 <del>one or more of the following conditions:</del>
9116 <ins>the following condition:</ins></p>
9117 <ul>
9118
9119 <li>
9120 <del>T is Swappable if T satisfies the CopyConstructible requirements
9121 (20.1.3) and the Assignable requirements (23.1);</del>
9122 </li>
9123 <li>
9124 <del>
9125 T is Swappable if a namespace scope function named swap exists in the
9126 same namespace as the definition of T, such that the expression
9127 swap(t,u) is valid and has the semantics described in Table 33.
9128 </del>
9129 T is Swappable if an unqualified function call swap(t,u) is valid
9130 within the namespace std, and has the semantics described in Table 33.
9131 </li>
9132 </ul>
9133 </blockquote>
9134
9135
9136 <p><b>Rationale:</b></p>
9137 <p>
9138 Recommend NAD.  Concepts, specifically
9139 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2082.pdf">N2082</a>
9140 and
9141 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2084.pdf">N2084</a>,
9142 will essentially rewrite this section and provide the desired semantics.
9143 </p>
9144
9145
9146
9147
9148
9149 <hr>
9150 <h3><a name="615"></a>615. Inconsistencies in Section 21.4</h3>
9151 <p><b>Section:</b> 21.4 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9152  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-11</p>
9153 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p>
9154 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9155 <p><b>Discussion:</b></p>
9156 <p>
9157 In the current draft N2134, 21.4/1 says
9158 </p>
9159 <p>
9160 "Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers &lt;cctype&gt;,
9161 &lt;cwctype&gt;, &lt;cstring&gt;, &lt;cwchar&gt;, and &lt;cstdlib&gt; (character conversions),
9162 respectively."
9163 </p>
9164 <p>
9165 Here footnote 229 applies to table 62, not table 63.
9166 </p>
9167 <p>
9168 Also, footnote 230 lists the new functions in table 63, "atoll, strtoll,
9169 strtoull, strtof, and strtold added by TR1". However, strtof is not present
9170 in table 63.
9171 </p>
9172
9173
9174 <p><b>Proposed resolution:</b></p>
9175 <p>
9176 </p>
9177
9178
9179 <p><b>Rationale:</b></p>
9180 <p>
9181 Recommend NAD, editorial.  Send to Pete.
9182 </p>
9183
9184
9185
9186
9187
9188 <hr>
9189 <h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3>
9190 <p><b>Section:</b> 20.5.14.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
9191  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p>
9192 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9193 <p><b>Discussion:</b></p>
9194 <p>
9195 20.5.14.2.5 [func.wrap.func.targ], p4 says:
9196 </p>
9197 <blockquote><p>
9198 <i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
9199 function target; otherwise a null pointer.
9200 </p></blockquote>
9201
9202 <ol>
9203 <li>
9204 There exists neither a type, a typedef <tt>type</tt>, nor member
9205 function <tt>type()</tt> in class template function nor in the global or
9206 <tt>std</tt> namespace.
9207 </li>
9208 <li>
9209 Assuming that <tt>type</tt> should have been <tt>target_type()</tt>,
9210 this description would lead to false results, if <tt>T = <i>cv</i>
9211 void</tt> due to returns clause 20.5.14.2.5 [func.wrap.func.targ], p1.
9212 </li>
9213 </ol>
9214
9215
9216
9217 <p><b>Proposed resolution:</b></p>
9218 <p>
9219 Change 20.5.14.2.5 [func.wrap.func.targ], p4:
9220 </p>
9221
9222 <blockquote><p>
9223 <i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&amp;&amp; typeid(T) !=
9224 typeid(void)</ins></tt>, a pointer to the stored function target;
9225 otherwise a null pointer.
9226 </p></blockquote>
9227
9228 <p><i>[
9229 Pete: Agreed. It's editorial, so I'll fix it.
9230 ]</i></p>
9231
9232
9233
9234
9235
9236
9237
9238 <hr>
9239 <h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3>
9240 <p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
9241  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-11</p>
9242 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
9243 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9244 <p><b>Discussion:</b></p>
9245 <p>
9246 The signature of the const operator[] has been changed to return a const
9247 reference.
9248 </p>
9249 <p>
9250 The description in paragraph 1 still says that the operator returns by
9251 value.
9252 </p>
9253 <p><i>[
9254 Pete recommends editorial fix.
9255 ]</i></p>
9256
9257
9258
9259 <p><b>Proposed resolution:</b></p>
9260 <p>
9261 </p>
9262
9263
9264
9265
9266
9267 <hr>
9268 <h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</h3>
9269 <p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
9270  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-18</p>
9271 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
9272 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9273 <p><b>Discussion:</b></p>
9274 <p>
9275 The function <tt>f</tt> in para 4 (27.6.4 [ext.manip]) references an unknown <tt>strm</tt>
9276 in the following line:
9277 </p>
9278
9279 <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
9280 </pre></blockquote>
9281
9282
9283 <p><b>Proposed resolution:</b></p>
9284 <p>
9285 Change 27.6.4 [ext.manip], p4:
9286 </p>
9287
9288 <blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon);
9289 </pre></blockquote>
9290
9291 <p><i>[
9292 Oxford:  Editorial.
9293 ]</i></p>
9294
9295
9296
9297
9298
9299
9300
9301 <hr>
9302 <h3><a name="642"></a>642. Invalidated fstream footnotes in N2134</h3>
9303 <p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
9304  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p>
9305 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
9306 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9307 <p><b>Discussion:</b></p>
9308 <p>
9309 The standard wording of N2134 has extended the 14882:2003(E)
9310 wording for the ifstream/ofstream/fstream open function to fix
9311 a long standing problem, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>.
9312 </p>
9313
9314 <p>
9315 Now it's properly written as
9316 </p>
9317
9318 <blockquote><p>
9319 "If that function does not return a null pointer calls clear(),
9320 otherwise
9321 calls setstate(failbit)[..]"
9322 </p></blockquote>
9323
9324 <p>
9325 instead of the previous
9326 </p>
9327
9328 <blockquote><p>
9329 "If that function returns a null pointer, calls setstate(failbit)[..]
9330 </p></blockquote>
9331
9332 <p>
9333 While the old footnotes saying
9334 </p>
9335
9336 <blockquote><p>
9337 "A successful open does not change the error state."
9338 </p></blockquote>
9339
9340 <p>
9341 where correct and important, they are invalid now for ifstream and
9342 ofstream (because clear *does* indeed modify the error state) and
9343 should be removed (Interestingly fstream itself never had these,
9344 although
9345 they where needed for that time).
9346 </p>
9347
9348
9349 <p><b>Proposed resolution:</b></p>
9350 <p>
9351 In 27.8.1.9 [ifstream.members], remove footnote:
9352 </p>
9353
9354 <blockquote><p>
9355 <del><sup>334)</sup> A successful open does not change the error state.</del>
9356 </p></blockquote>
9357
9358 <p>
9359 In 27.8.1.13 [ofstream.members], remove footnote:
9360 </p>
9361
9362 <blockquote><p>
9363 <del><sup>335)</sup> A successful open does not change the error state.</del>
9364 </p></blockquote>
9365
9366
9367
9368
9369
9370
9371 <hr>
9372 <h3><a name="648"></a>648. regex_iterator c'tor needs clarification/editorial fix</h3>
9373 <p><b>Section:</b> 28.12.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
9374  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p>
9375 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9376 <p><b>Discussion:</b></p>
9377 <p>
9378 In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
9379 </p>
9380
9381 <blockquote>
9382 <p>
9383 <i>Effects:</i> Initializes begin and end to point to the beginning and the
9384 end of the target sequence, sets pregex to &amp;re, sets flags to f,[..]
9385 </p></blockquote>
9386
9387 <p>
9388 There are two issues with this description:
9389 </p>
9390
9391 <ol>
9392 <li>
9393 The meaning of very first part of this quote is unclear, because
9394 there is no target sequence provided, instead there are given two
9395 parameters a and b, both of type BidirectionalIterator. The mentioned
9396 part does not explain what a and b represent.
9397 </li>
9398 <li>
9399 There does not exist any parameter f, but instead a parameter
9400 m in the constructor declaration, so this is actually an editorial
9401 fix.
9402 </li>
9403 </ol>
9404
9405
9406 <p><b>Proposed resolution:</b></p>
9407 <p>
9408 In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by
9409 </p>
9410
9411 <blockquote><p>
9412 <i>Effects:</i> Initializes <tt>begin</tt> and <tt>end</tt> to point to
9413 the beginning and the end of the target sequence <ins>designated by the
9414 iterator range <tt>[a, b)</tt></ins>, sets <tt>pregex</tt> to
9415 <tt>&amp;re</tt>, sets <tt>flags</tt> to <tt><del>f</del>
9416 <ins>m</ins></tt>, then calls <tt>regex_search(begin, end, match,
9417 *pregex, flags)</tt>. If this call returns <tt>false</tt> the
9418 constructor sets <tt>*this</tt> to the end-of-sequence iterator.
9419 </p></blockquote>
9420
9421
9422
9423
9424
9425 <hr>
9426 <h3><a name="649"></a>649. Several typos in regex_token_iterator constructors</h3>
9427 <p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
9428  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p>
9429 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
9430 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9431 <p><b>Discussion:</b></p>
9432 <p>
9433 In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
9434 and the following text shows some obvious typos:
9435 </p>
9436 <p>
9437 1) The third constructor form is written as
9438 </p>
9439 <blockquote><pre>template &lt;std::size_t N&gt;
9440   regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
9441                        const regex_type&amp; re,
9442                        const int (&amp;submatches)[R],
9443                        regex_constants::match_flag_type m =
9444                          regex_constants::match_default);
9445 </pre></blockquote>
9446
9447 <p>
9448 where the dimensions of submatches are specified by an
9449 unknown value R, which should be N.
9450 </p>
9451 <p>
9452 2) Paragraph 2 of the same section says in its last sentence:
9453 </p>
9454
9455 <blockquote><p>
9456 The third constructor initializes the member <tt>subs</tt> to hold a
9457 copy of the sequence of integer values pointed to by the iterator range
9458 <tt>[&amp;submatches, &amp;submatches + R)</tt>.
9459 </p></blockquote>
9460
9461 <p>
9462 where again R must be replaced by N.
9463 </p>
9464
9465 <p>
9466 3) Paragraph 3 of the same section says in its first sentence:
9467 </p>
9468
9469 <blockquote><p>
9470 Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
9471 <tt>position</tt> to <tt>position_iterator(a, b, re, f)</tt>.
9472 </p></blockquote>
9473
9474 <p>
9475 where a non-existing parameter "f" is mentioned, which must be
9476 replaced
9477 by the parameter "m".
9478 </p>
9479
9480
9481 <p><b>Proposed resolution:</b></p>
9482 <p>
9483 Change 28.12.2.1 [re.tokiter.cnstr]/1:
9484 </p>
9485 <blockquote><pre>template &lt;std::size_t N&gt;
9486   regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
9487                        const regex_type&amp; re,
9488                        const int (&amp;submatches)[<del>R</del> <ins>N</ins>],
9489                        regex_constants::match_flag_type m =
9490                          regex_constants::match_default);
9491 </pre></blockquote>
9492
9493 <p>
9494 Change 28.12.2.1 [re.tokiter.cnstr]/2:
9495 </p>
9496
9497 <blockquote><p>
9498 <i>Effects:</i> The first constructor initializes the member
9499 <tt>subs</tt> to hold the single value <tt>submatch</tt>. The second
9500 constructor initializes the member <tt>subs</tt> to hold a copy of the
9501 argument <tt>submatches</tt>. The third constructor initializes the
9502 member <tt>subs</tt> to hold a copy of the sequence of integer values
9503 pointed to by the iterator range <tt>[&amp;submatches, &amp;submatches +
9504 <del>R</del> <ins>N</ins>)</tt>.
9505 </p></blockquote>
9506
9507 <p>
9508 Change 28.12.2.1 [re.tokiter.cnstr]/3:
9509 </p>
9510
9511 <blockquote><p>
9512 Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
9513 <tt>position</tt> to <tt>position_iterator(a, b, re, <del>f</del>
9514 <ins>m</ins>)</tt>. If <tt>position</tt> is not an end-of-sequence
9515 iterator the constructor sets <tt>result</tt> to the address of the
9516 current match. Otherwise if any of the values stored in <tt>subs</tt> is
9517 equal to <tt>-1</tt> the constructor sets <tt>*this</tt> to a suffix
9518 iterator that points to the range <tt>[a, b)</tt>, otherwise the
9519 constructor sets <tt>*this</tt> to an end-of-sequence iterator.
9520 </p></blockquote>
9521
9522
9523
9524
9525
9526
9527 <hr>
9528 <h3><a name="656"></a>656. Typo in subtract_with_carry_engine declaration</h3>
9529 <p><b>Section:</b> 26.4.2 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
9530  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
9531 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
9532 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9533 <p><b>Discussion:</b></p>
9534 <p>
9535 26.4.2 [rand.synopsis] the header <tt>&lt;random&gt;</tt> synopsis
9536 contains an unreasonable closing curly brace inside the
9537 <tt>subtract_with_carry_engine</tt> declaration.
9538 </p>
9539
9540
9541 <p><b>Proposed resolution:</b></p>
9542 <p>
9543 Change the current declaration in 26.4.2 [rand.synopsis]
9544 </p>
9545
9546 <blockquote><pre>template &lt;class UIntType, size_t w<del>}</del>, size_t s, size_t r&gt;
9547 class subtract_with_carry_engine;
9548 </pre></blockquote>
9549
9550
9551 <p><i>[
9552 Pete: Recommends editorial.
9553 ]</i></p>
9554
9555
9556
9557
9558
9559 <hr>
9560 <h3><a name="683"></a>683. regex_token_iterator summary error</h3>
9561 <p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
9562  <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-02</p>
9563 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
9564 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
9565 <p><b>Discussion:</b></p>
9566 <p>
9567 28.12.2 [re.tokiter], p3 says:
9568 </p>
9569 <blockquote>
9570 <p>
9571 After it is constructed, the iterator finds and stores a value
9572 <tt>match_results&lt;BidirectionalIterator&gt;</tt> position and sets the
9573 internal count <tt>N</tt> to zero.
9574 </p>
9575 </blockquote>
9576
9577 <p>
9578 Should read:
9579 </p>
9580
9581 <blockquote>
9582 <p>
9583 After it is constructed, the iterator finds and stores a value
9584 <tt><del>match_results</del><ins>regex_iterator</ins>&lt;BidirectionalIterator<ins>, charT, traits</ins>&gt;</tt>
9585 position and sets the internal count <tt>N</tt> to zero.
9586 </p>
9587 </blockquote>
9588
9589 <p><i>[
9590 John adds:
9591 ]</i></p>
9592
9593
9594 <blockquote><p>
9595 Yep, looks like a typo/administrative fix to me.
9596 </p></blockquote>
9597
9598
9599
9600 <p><b>Proposed resolution:</b></p>
9601 <p>
9602 </p>
9603
9604
9605
9606
9607
9608 </body></html>