| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> |
| <html><head> |
| <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> |
| |
| |
| <title>C++ Standard Library Active Issues List</title> |
| <style type="text/css"> |
| p {text-align:justify} |
| li {text-align:justify} |
| ins {background-color:#A0FFA0} |
| del {background-color:#FFA0A0} |
| </style> |
| </head><body> |
| <table> |
| <tbody><tr> |
| <td align="left">Doc. no.</td> |
| <td align="left">N2727=08-0237</td> |
| </tr> |
| <tr> |
| <td align="left">Date:</td> |
| <td align="left">2008-08-24</td> |
| </tr> |
| <tr> |
| <td align="left">Project:</td> |
| <td align="left">Programming Language C++</td> |
| </tr> |
| <tr> |
| <td align="left">Reply to:</td> |
| <td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td> |
| </tr> |
| </tbody></table> |
| <h1>C++ Standard Library Active Issues List (Revision R59)</h1> |
| |
| <p>Reference ISO/IEC IS 14882:1998(E)</p> |
| <p>Also see:</p> |
| <ul> |
| <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li> |
| <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li> |
| <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li> |
| <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li> |
| <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li> |
| </ul> |
| <p>The purpose of this document is to record the status of issues |
| which have come before the Library Working Group (LWG) of the ANSI |
| (J16) and ISO (WG21) C++ Standards Committee. Issues represent |
| potential defects in the ISO/IEC IS 14882:1998(E) document. Issues |
| are not to be used to request new features. </p> |
| |
| <p>This document contains only library issues which are actively being |
| considered by the Library Working Group. That is, issues which have a |
| status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>. See |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p> |
| |
| <p>The issues in these lists are not necessarily formal ISO Defect |
| Reports (DR's). While some issues will eventually be elevated to |
| official Defect Report status, other issues will be disposed of in |
| other ways. See <a href="#Status">Issue Status</a>.</p> |
| |
| <p>This document is in an experimental format designed for both |
| viewing via a world-wide web browser and hard-copy printing. It |
| is available as an HTML file for browsing or PDF file for |
| printing.</p> |
| |
| <p>Prior to Revision 14, library issues lists existed in two slightly |
| different versions; a Committee Version and a Public |
| Version. Beginning with Revision 14 the two versions were combined |
| into a single version.</p> |
| |
| <p>This document includes <i>[bracketed italicized notes]</i> as a |
| reminder to the LWG of current progress on issues. Such notes are |
| strictly unofficial and should be read with caution as they may be |
| incomplete or incorrect. Be aware that LWG support for a particular |
| resolution can quickly change if new viewpoints or killer examples are |
| presented in subsequent discussions.</p> |
| |
| <p>For the most current official version of this document see |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>. |
| Requests for further information about this document should include |
| the document number above, reference ISO/IEC 14882:1998(E), and be |
| submitted to Information Technology Industry Council (ITI), 1250 Eye |
| Street NW, Washington, DC 20005.</p> |
| |
| <p>Public information as to how to obtain a copy of the C++ Standard, |
| join the standards committee, submit an issue, or comment on an issue |
| can be found in the comp.std.c++ FAQ. |
| Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c++">news:comp.std.c++</a>. |
| </p> |
| |
| <p>For committee members, files available on the committee's private |
| web site include the HTML version of the Standard itself. HTML |
| hyperlinks from this issues list to those files will only work for |
| committee members who have downloaded them into the same disk |
| directory as the issues list files. </p> |
| |
| <h2>Revision History</h2> |
| <ul> |
| <li>R59: |
| 2008-08-22 pre-San Francisco mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>192 open issues, up by 9.</li> |
| <li>686 closed issues, up by 0.</li> |
| <li>878 issues total, up by 9.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R58: |
| 2008-07-28 mid-term mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>183 open issues, up by 12.</li> |
| <li>686 closed issues, down by 4.</li> |
| <li>869 issues total, up by 8.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li> |
| <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> |
| <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li> |
| <li>Changed the following issues from WP to Ready: <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-active.html#629">629</a>.</li> |
| <li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R57: |
| 2008-06-27 post-Sophia Antipolis mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>171 open issues, down by 20.</li> |
| <li>690 closed issues, up by 43.</li> |
| <li>861 issues total, up by 23.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li> |
| <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li> |
| <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li> |
| <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li> |
| <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li> |
| <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li> |
| <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li> |
| <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li> |
| <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li> |
| <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li> |
| <li>Changed the following issues from Review to Open: <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#711">711</a>.</li> |
| <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li> |
| <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</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#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li> |
| <li>Changed the following issues from Review to Ready: <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#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> |
| <li>Changed the following issues from New to Review: <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#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li> |
| <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</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#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> |
| <li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li> |
| <li>Changed the following issues from Ready to WP: <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#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</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-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R56: |
| 2008-05-16 pre-Sophia Antipolis mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>191 open issues, up by 24.</li> |
| <li>647 closed issues, up by 1.</li> |
| <li>838 issues total, up by 25.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li> |
| <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R55: |
| 2008-03-14 post-Bellevue mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>167 open issues, down by 39.</li> |
| <li>646 closed issues, up by 65.</li> |
| <li>813 issues total, up by 26.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li> |
| <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li> |
| <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> |
| <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li> |
| <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li> |
| <li>Changed the following issues from NAD Future to NAD: <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#323">323</a>.</li> |
| <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li> |
| <li>Changed the following issues from Open to NAD: <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#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li> |
| <li>Changed the following issues from NAD Future to NAD Editorial: <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#390">390</a>.</li> |
| <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> |
| <li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li> |
| <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li> |
| <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li> |
| <li>Changed the following issues from Ready to Open: <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>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li> |
| <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> |
| <li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li> |
| <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li> |
| <li>Changed the following issues from Open to Ready: <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-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</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-defects.html#673">673</a>.</li> |
| <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li> |
| <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> |
| <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li> |
| <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> |
| <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R54: |
| 2008-02-01 pre-Bellevue mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>206 open issues, up by 23.</li> |
| <li>581 closed issues, up by 0.</li> |
| <li>787 issues total, up by 23.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li> |
| <li>Changed the following issues from NAD Future to Dup: <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#348">348</a>.</li> |
| <li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li> |
| <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li> |
| <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li> |
| <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R53: |
| 2007-12-09 mid-term mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>183 open issues, up by 11.</li> |
| <li>581 closed issues, down by 1.</li> |
| <li>764 issues total, up by 10.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li> |
| <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li> |
| <li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R52: |
| 2007-10-19 post-Kona mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>172 open issues, up by 4.</li> |
| <li>582 closed issues, up by 27.</li> |
| <li>754 issues total, up by 31.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li> |
| <li>Changed the following issues from NAD Future to Dup: <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#350">350</a>.</li> |
| <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li> |
| <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li> |
| <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</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#632">632</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#653">653</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#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-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> |
| <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#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> |
| <li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> |
| <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> |
| <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li> |
| <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li> |
| <li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li> |
| <li>Changed the following issues from Open to WP: <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-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li> |
| <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R51: |
| 2007-09-09 pre-Kona mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>168 open issues, up by 15.</li> |
| <li>555 closed issues, up by 0.</li> |
| <li>723 issues total, up by 15.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R50: |
| 2007-08-05 post-Toronto mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>153 open issues, down by 5.</li> |
| <li>555 closed issues, up by 17.</li> |
| <li>708 issues total, up by 12.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> |
| <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li> |
| <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li> |
| <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li> |
| <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>.</li> |
| <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <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#633">633</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-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-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-closed.html#656">656</a>.</li> |
| <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</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-defects.html#680">680</a>.</li> |
| <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li> |
| <li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li> |
| <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li> |
| <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li> |
| <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li> |
| <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li> |
| <li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li> |
| <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R49: |
| 2007-06-23 pre-Toronto mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>158 open issues, up by 13.</li> |
| <li>538 closed issues, up by 7.</li> |
| <li>696 issues total, up by 20.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> |
| <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> |
| <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> |
| <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> |
| <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> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R48: |
| 2007-05-06 post-Oxford mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>145 open issues, down by 33.</li> |
| <li>531 closed issues, up by 53.</li> |
| <li>676 issues total, up by 20.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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> |
| <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> |
| <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-active.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> |
| <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> |
| <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> |
| <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-active.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-active.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-active.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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#646">646</a>.</li> |
| <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li> |
| <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> |
| <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> |
| <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> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R47: |
| 2007-03-09 pre-Oxford mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>178 open issues, up by 37.</li> |
| <li>478 closed issues, up by 0.</li> |
| <li>656 issues total, up by 37.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> |
| <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> |
| <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li> |
| <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> |
| <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-active.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> |
| <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> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R46: |
| 2007-01-12 mid-term mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>141 open issues, up by 11.</li> |
| <li>478 closed issues, down by 1.</li> |
| <li>619 issues total, up by 10.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <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> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R45: |
| 2006-11-03 post-Portland mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>130 open issues, up by 0.</li> |
| <li>479 closed issues, up by 17.</li> |
| <li>609 issues total, up by 17.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <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> |
| <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> |
| <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li> |
| <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-closed.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> |
| <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> |
| <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li> |
| <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> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R44: |
| 2006-09-08 pre-Portland mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>130 open issues, up by 6.</li> |
| <li>462 closed issues, down by 1.</li> |
| <li>592 issues total, up by 5.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R43: |
| 2006-06-23 mid-term mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>124 open issues, up by 14.</li> |
| <li>463 closed issues, down by 1.</li> |
| <li>587 issues total, up by 13.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <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> |
| <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li> |
| <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> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R42: |
| 2006-04-21 post-Berlin mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>110 open issues, down by 16.</li> |
| <li>464 closed issues, up by 24.</li> |
| <li>574 issues total, up by 8.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> |
| <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> |
| <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-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#548">548</a> to Open.</li> |
| <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-defects.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> |
| <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> |
| <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R41: |
| 2006-02-24 pre-Berlin mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>126 open issues, up by 31.</li> |
| <li>440 closed issues, up by 0.</li> |
| <li>566 issues total, up by 31.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <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-defects.html#566">566</a>.</li> |
| <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li> |
| <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R40: |
| 2005-12-16 mid-term mailing. |
| <ul> |
| <li><b>Summary:</b><ul> |
| <li>95 open issues.</li> |
| <li>440 closed issues.</li> |
| <li>535 issues total.</li> |
| </ul></li> |
| <li><b>Details:</b><ul> |
| <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li> |
| </ul></li> |
| </ul> |
| </li> |
| <li>R39: |
| 2005-10-14 post-Mont Tremblant mailing. |
| 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-closed.html#528">528</a>. |
| 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. |
| 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. |
| 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. |
| 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. |
| Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD. |
| Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review. |
| </li> |
| <li>R38: |
| 2005-07-03 pre-Mont Tremblant mailing. |
| 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>. |
| 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> |
| </li> |
| <li>R37: |
| 2005-06 mid-term mailing. |
| 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>. |
| </li> |
| <li>R36: |
| 2005-04 post-Lillehammer mailing. All issues in "ready" status except |
| 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 |
| previously in "DR" status were moved to "WP". |
| </li> |
| <li>R35: |
| 2005-03 pre-Lillehammer mailing. |
| </li> |
| <li>R34: |
| 2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>. |
| </li> |
| <li>R33: |
| 2004-11 post-Redmond mailing. Reflects actions taken in Redmond. |
| </li> |
| <li>R32: |
| 2004-09 pre-Redmond mailing: reflects new proposed resolutions and |
| new issues received after the 2004-07 mailing. Added |
| 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>. |
| </li> |
| <li>R31: |
| 2004-07 mid-term mailing: reflects new proposed resolutions and |
| new issues received after the post-Sydney mailing. Added |
| new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. |
| </li> |
| <li>R30: |
| Post-Sydney mailing: reflects decisions made at the Sydney meeting. |
| Voted all "Ready" issues from R29 into the working paper. |
| 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-closed.html#462">462</a>. |
| </li> |
| <li>R29: |
| 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>. |
| </li> |
| <li>R28: |
| Post-Kona mailing: reflects decisions made at the Kona meeting. |
| 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>. |
| </li> |
| <li>R27: |
| 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>. |
| </li> |
| <li>R26: |
| Post-Oxford mailing: reflects decisions made at the Oxford meeting. |
| All issues in Ready status were voted into DR status. All issues in |
| DR status were voted into WP status. |
| </li> |
| <li>R25: |
| 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>. |
| </li> |
| <li>R24: |
| Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz |
| 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 |
| 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 |
| 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 |
| concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording. |
| </li> |
| <li>R23: |
| 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>. |
| Moved issues in the TC to TC status. |
| </li> |
| <li>R22: |
| 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>. |
| </li> |
| <li>R21: |
| 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>. |
| </li> |
| <li>R20: |
| Post-Redmond mailing; reflects actions taken in Redmond. Added |
| 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 |
| <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 |
| not discussed at the meeting. |
| |
| All Ready issues were moved to DR status, with the exception of issues |
| <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>. |
| |
| Noteworthy issues discussed at Redmond include |
| <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>, |
| <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>. |
| </li> |
| <li>R19: |
| Pre-Redmond mailing. Added new issues |
| <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>. |
| </li> |
| <li>R18: |
| Post-Copenhagen mailing; reflects actions taken in Copenhagen. |
| 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 |
| 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>. |
| |
| Changed status of 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#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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a> |
| to DR. |
| |
| Changed status of 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#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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <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> |
| <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> |
| to Ready. |
| |
| Closed issues |
| <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> |
| <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> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a> |
| as NAD. |
| |
| </li> |
| <li>R17: |
| Pre-Copenhagen mailing. Converted issues list to XML. Added proposed |
| resolutions for issues <a href="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>. |
| 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>. |
| </li> |
| <li>R16: |
| post-Toronto mailing; reflects actions taken in Toronto. Added new |
| 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 |
| <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>, |
| <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>, |
| <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>, |
| <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>, |
| <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>, |
| <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>, |
| <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>, |
| <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>, |
| <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>, |
| <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>, |
| <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>, |
| <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>, |
| <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 |
| 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 |
| <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 |
| 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 |
| 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 |
| the bug in enough places. |
| </li> |
| <li>R15: |
| pre-Toronto mailing. Added issues |
| <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 |
| changes so that we pass Weblint tests. |
| </li> |
| <li>R14: |
| post-Tokyo II mailing; reflects committee actions taken in |
| 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) |
| </li> |
| <li>R13: |
| 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>. |
| </li> |
| <li>R12: |
| pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to |
| <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 |
| of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>. |
| </li> |
| <li>R11: |
| post-Kona mailing: Updated to reflect LWG and full committee actions |
| in Kona (99-0048/N1224). Note changed resolution of issues |
| <a href="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> |
| 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 |
| "closed" documents. Changed the proposed resolution of issue |
| <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 |
| of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. |
| </li> |
| <li>R10: |
| pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</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#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, |
| <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-active.html#190">190</a> to |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99) |
| </li> |
| <li>R9: |
| pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and |
| "closed" documents. (99-0030/N1206, 25 Aug 99) |
| </li> |
| <li>R8: |
| post-Dublin mailing. Updated to reflect LWG and full committee actions |
| in Dublin. (99-0016/N1193, 21 Apr 99) |
| </li> |
| <li>R7: |
| pre-Dublin updated: Added issues <a href="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>, |
| <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>, |
| <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>, |
| <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) |
| </li> |
| <li>R6: |
| 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-active.html#128">128</a>, |
| and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99) |
| </li> |
| <li>R5: |
| 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 |
| <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 |
| for making list public. (30 Dec 98) |
| </li> |
| <li>R4: |
| post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</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-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several |
| issues corrected. (22 Oct 98) |
| </li> |
| <li>R3: |
| 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> |
| added, many issues updated to reflect LWG consensus (12 Oct 98) |
| </li> |
| <li>R2: |
| 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, |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98) |
| </li> |
| <li>R1: |
| 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 |
| format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98) |
| </li> |
| </ul> |
| |
| <h2><a name="Status"></a>Issue Status</h2> |
| |
| <p><b><a name="New">New</a></b> - The issue has not yet been |
| reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a |
| suggestion from the issue submitter, and should not be construed as |
| the view of LWG.</p> |
| |
| <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue |
| but is not yet ready to move the issue forward. There are several |
| possible reasons for open status:</p> |
| <ul> |
| <li>Consensus may have not yet have been reached as to how to deal |
| with the issue.</li> |
| <li>Informal consensus may have been reached, but the LWG awaits |
| exact <b>Proposed Resolution</b> wording for review.</li> |
| <li>The LWG wishes to consult additional technical experts before |
| proceeding.</li> |
| <li>The issue may require further study.</li> |
| </ul> |
| |
| <p>A <b>Proposed Resolution</b> for an open issue is still not be |
| construed as the view of LWG. Comments on the current state of |
| discussions are often given at the end of open issues in an italic |
| font. Such comments are for information only and should not be given |
| undue importance.</p> |
| |
| <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that |
| the issue is a duplicate of another issue, and will not be further |
| dealt with. A <b>Rationale</b> identifies the duplicated issue's |
| issue number. </p> |
| |
| <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that |
| the issue is not a defect in the Standard.</p> |
| |
| <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that |
| the issue can either be handled editorially, or is handled by a paper (usually |
| linked to in the rationale).</p> |
| |
| <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular |
| status, the LWG believes that this issue should be revisited at the |
| next revision of the standard.</p> |
| |
| <p><b><a name="Review">Review</a></b> - Exact wording of a |
| <b>Proposed Resolution</b> is now available for review on an issue |
| for which the LWG previously reached informal consensus.</p> |
| |
| <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has |
| been reviewed online, but not in a meeting, and some support has been formed |
| for the proposed resolution. Tentatively Ready issues may be moved to Ready |
| and forwarded to full committee within the same meeting. Unlike Ready issues |
| they will be reviewed in subcommittee prior to forwarding to full committee.</p> |
| |
| <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus |
| that the issue is a defect in the Standard, the <b>Proposed |
| Resolution</b> is correct, and the issue is ready to forward to the |
| full committee for further action as a Defect Report (DR).</p> |
| |
| <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16 |
| committee has voted to forward the issue to the Project Editor to be |
| processed as a Potential Defect Report. The Project Editor reviews |
| the issue, and then forwards it to the WG21 Convenor, who returns it |
| to the full committee for final disposition. This issues list |
| accords the status of DR to all these Defect Reports regardless of |
| where they are in that process.</p> |
| |
| <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full |
| WG21 committee has voted to accept the Defect Report's Proposed |
| Resolution as a Technical Corrigenda. Action on this issue is thus |
| complete and no further action is possible under ISO rules.</p> |
| |
| <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The |
| LWG has voted to accept the Defect Report's Proposed |
| Resolution into the Decimal TR. Action on this issue is thus |
| complete and no further action is expected.</p> |
| |
| <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed |
| resolution has not been accepted as a Technical Corrigendum, but |
| the full WG21 committee has voted to apply the Defect Report's Proposed |
| Resolution to the working paper.</p> |
| |
| <p><b>Pending</b> - This is a <i>status qualifier</i>. When prepended to |
| a status this indicates the issue has been |
| processed by the committee, and a decision has been made to move the issue to |
| the associated unqualified status. However for logistical reasons the indicated |
| outcome of the issue has not yet appeared in the latest working paper. |
| |
| </p><p>Issues are always given the status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> when |
| they first appear on the issues list. They may progress to |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> while the LWG |
| is actively working on them. When the LWG has reached consensus on |
| the disposition of an issue, the status will then change to |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>, or |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> as appropriate. Once the full J16 committee votes to |
| forward Ready issues to the Project Editor, they are given the |
| status of Defect Report ( <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>). These in turn may |
| become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>), |
| or are closed without action other than a Record of Response |
| (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a> ). The intent of this LWG process is that |
| only issues which are truly defects in the Standard move to the |
| formal ISO DR status. |
| </p> |
| |
| |
| <h2>Active Issues</h2> |
| <hr> |
| <h3><a name="23"></a>23. Num_get overflow result</h3> |
| <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> |
| <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>The current description of numeric input does not account for the |
| possibility of overflow. This is an implicit result of changing the |
| description to rely on the definition of scanf() (which fails to |
| report overflow), and conflicts with the documented behavior of |
| traditional and current implementations. </p> |
| |
| <p>Users expect, when reading a character sequence that results in a |
| value unrepresentable in the specified type, to have an error |
| reported. The standard as written does not permit this. </p> |
| |
| <p><b>Further comments from Dietmar:</b></p> |
| |
| <p> |
| I don't feel comfortable with the proposed resolution to issue 23: It |
| kind of simplifies the issue to much. Here is what is going on: |
| </p> |
| |
| <p> |
| Currently, the behavior of numeric overflow is rather counter intuitive |
| and hard to trace, so I will describe it briefly: |
| </p> |
| |
| <ul> |
| <li> |
| According to 22.2.2.1.2 [facet.num.get.virtuals] |
| paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would |
| return an input error; otherwise a value is converted to the rules |
| of <tt>scanf</tt>. |
| </li> |
| <li> |
| <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>. |
| </li> |
| <li> |
| <tt>fscanf()</tt> returns an input failure if during conversion no |
| character matching the conversion specification could be extracted |
| before reaching EOF. This is the only reason for <tt>fscanf()</tt> |
| to fail due to an input error and clearly does not apply to the case |
| of overflow. |
| </li> |
| <li> |
| Thus, the conversion is performed according to the rules of |
| <tt>fscanf()</tt> which basically says that <tt>strtod</tt>, |
| <tt>strtol()</tt>, etc. are to be used for the conversion. |
| </li> |
| <li> |
| The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as |
| many matching characters as there are and on overflow continue to |
| consume matching characters but also return a value identical to |
| the maximum (or minimum for signed types if there was a leading minus) |
| value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>. |
| </li> |
| <li> |
| Thus, according to the current wording in the standard, overflows |
| can be detected! All what is to be done is to check <tt>errno</tt> |
| after reading an element and, of course, clearing <tt>errno</tt> |
| before trying a conversion. With the current wording, it can be |
| detected whether the overflow was due to a positive or negative |
| number for signed types. |
| </li> |
| </ul> |
| |
| <p><b>Further discussion from Redmond:</b></p> |
| |
| <p>The basic problem is that we've defined our behavior, |
| including our error-reporting behavior, in terms of C90. However, |
| C90's method of reporting overflow in scanf is not technically an |
| "input error". The <tt>strto_*</tt> functions are more precise.</p> |
| |
| <p>There was general consensus that <tt>failbit</tt> should be set |
| upon overflow. We considered three options based on this:</p> |
| <ol> |
| <li>Set failbit upon conversion error (including overflow), and |
| don't store any value.</li> |
| <li>Set failbit upon conversion error, and also set <tt>errno</tt> to |
| indicated the precise nature of the error.</li> |
| <li>Set failbit upon conversion error. If the error was due to |
| overflow, store +-numeric_limits<T>::max() as an |
| overflow indication.</li> |
| </ol> |
| |
| <p>Straw poll: (1) 5; (2) 0; (3) 8.</p> |
| |
| |
| <p>Discussed at Lillehammer. General outline of what we want the |
| solution to look like: we want to say that overflow is an error, and |
| provide a way to distinguish overflow from other kinds of errors. |
| Choose candidate field the same way scanf does, but don't describe |
| the rest of the process in terms of format. If a finite input field |
| is too large (positive or negative) to be represented as a finite |
| value, then set failbit and assign the nearest representable value. |
| Bill will provide wording.</p> |
| |
| <p> |
| Discussed at Toronto: |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a> |
| is in alignment with the direction we wanted to go with in Lillehammer. Bill |
| to work on. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3: |
| </p> |
| |
| <blockquote> |
| <p> |
| <b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del> |
| <ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is |
| converted to a numeric value by the rules of one of the functions declared |
| in the header <tt><cstdlib></tt>:</ins> |
| </p> |
| <ul> |
| <li> |
| <del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is |
| converted (according to the rules of <tt>scanf</tt>) to a value of the |
| type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is |
| stored in <i>err</i>.</del> |
| <ins>For a signed integer value, the function <tt>strtoll</tt>.</ins> |
| </li> |
| <li> |
| <del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused |
| <tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is |
| assigned to <i>err</i>.</del> |
| <ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins> |
| </li> |
| <li> |
| <ins>For a floating-point value, the function <tt>strtold</tt>.</ins> |
| </li> |
| </ul> |
| <p> |
| <ins>The numeric value to be stored can be one of:</ins> |
| </p> |
| <ul> |
| <li><ins>zero, if the conversion function fails to convert the entire field. |
| <tt>ios_base::failbit</tt> is assigned to err.</ins></li> |
| <li><ins>the most positive representable value, if the field represents a value |
| too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned |
| to <i>err</i>.</ins></li> |
| <li><ins>the most negative representable value (zero for unsigned integer), if |
| the field represents a value too large negative to be represented in <i>val</i>. |
| <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li> |
| <li><ins>the converted value, otherwise.</ins></li> |
| </ul> |
| |
| <p><ins> |
| The resultant numeric value is stored in <i>val</i>. |
| </ins></p> |
| </blockquote> |
| |
| <p> |
| Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7: |
| </p> |
| |
| <blockquote> |
| <pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base& <i>str</i>, |
| ios_base::iostate& <i>err</i>, bool& <i>val</i>) const; |
| </pre> |
| <blockquote> |
| <p> |
| -6- <i>Effects:</i> If |
| <tt>(<i>str</i>.flags()&ios_base::boolalpha)==0</tt> then input |
| proceeds as it would for a <tt>long</tt> except that if a value is being |
| stored into <i>val</i>, the value is determined according to the |
| following: If the value to be stored is 0 then <tt>false</tt> is stored. |
| If the value is 1 then <tt>true</tt> is stored. Otherwise |
| <del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is |
| stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins> |
| </p> |
| <p> |
| -7- Otherwise target sequences are determined "as if" by calling the |
| members <tt>falsename()</tt> and <tt>truename()</tt> of the facet |
| obtained by <tt>use_facet<numpunct<charT> |
| >(<i>str</i>.getloc())</tt>. Successive characters in the range |
| <tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched |
| against corresponding positions in the target sequences only as |
| necessary to identify a unique match. The input iterator <i>in</i> is |
| compared to <i>end</i> only when necessary to obtain a character. If <del>and |
| only if</del> a target sequence is uniquely matched, <i>val</i> is set to the |
| corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt> |
| is assigned to <i>err</i>.</ins> |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="96"></a>96. Vector<bool> is not a container</h3> |
| <p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p><tt>vector<bool></tt> is not a container as its reference and |
| pointer types are not references and pointers. </p> |
| |
| <p>Also it forces everyone to have a space optimization instead of a |
| speed one.</p> |
| |
| <p><b>See also:</b> 99-0008 == N1185 Vector<bool> is |
| Nonconforming, Forces Optimization Choice.</p> |
| |
| <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p> |
| |
| |
| <p><i>[In Dublin many present felt that failure to meet Container |
| requirements was a defect. There was disagreement as to whether |
| or not the optimization requirements constituted a defect.]</i></p> |
| |
| |
| <p><i>[The LWG looked at the following resolutions in some detail: |
| <br> |
| * Not A Defect.<br> |
| * Add a note explaining that vector<bool> does not meet |
| Container requirements.<br> |
| * Remove vector<bool>.<br> |
| * Add a new category of container requirements which |
| vector<bool> would meet.<br> |
| * Rename vector<bool>.<br> |
| <br> |
| No alternative had strong, wide-spread, support and every alternative |
| had at least one "over my dead body" response.<br> |
| <br> |
| There was also mention of a transition scheme something like (1) add |
| vector_bool and deprecate vector<bool> in the next standard. (2) |
| Remove vector<bool> in the following standard.]</i></p> |
| |
| |
| <p><i>[Modifying container requirements to permit returning proxies |
| (thus allowing container requirements conforming vector<bool>) |
| was also discussed.]</i></p> |
| |
| |
| <p><i>[It was also noted that there is a partial but ugly workaround in |
| that vector<bool> may be further specialized with a customer |
| allocator.]</i></p> |
| |
| |
| <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211, |
| vector<bool>: More Problems, Better Solutions. Much discussion |
| of a two step approach: a) deprecate, b) provide replacement under a |
| new name. LWG straw vote on that: 1-favor, 11-could live with, 2-over |
| my dead body. This resolution was mentioned in the LWG report to the |
| full committee, where several additional committee members indicated |
| over-my-dead-body positions.]</i></p> |
| |
| |
| <p>Discussed at Lillehammer. General agreement that we should |
| deprecate vector<bool> and introduce this functionality under |
| a different name, e.g. bit_vector. This might make it possible to |
| remove the vector<bool> specialization in the standard that comes |
| after C++0x. There was also a suggestion that |
| in C++0x we could additional say that it's implementation defined |
| whether vector<bool> refers to the specialization or to the |
| primary template, but there wasn't general agreement that this was a |
| good idea.</p> |
| |
| <p>We need a paper for the new bit_vector class.</p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| We now have: |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a> |
| and |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>. |
| </p> |
| |
| <p><i>[ |
| Batavia: The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration |
| from <tt>vector<bool></tt>. Although some of the funcitonality from |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a> |
| could well be used in such a template. The concern is easing the API migration for those |
| users who want to continue using a bit-packed container. Alan and Beman to work. |
| ]</i></p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string buffers</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>The following question came from Thorsten Herlemann:</p> |
| |
| <blockquote> |
| <p>You can set a mode when constructing or opening a file-stream or |
| filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get |
| that mode later on, e.g. in my own operator << or operator |
| >> or when I want to check whether a file-stream or |
| file-buffer object passed as parameter is opened for input or output |
| or binary? Is there no possibility? Is this a design-error in the |
| standard C++ library? </p> |
| </blockquote> |
| |
| <p>It is indeed impossible to find out what a stream's or stream |
| buffer's open mode is, and without that knowledge you don't know |
| how certain operations behave. Just think of the append mode. </p> |
| |
| <p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the |
| current open mode setting. </p> |
| |
| <p><i>[ |
| post Bellevue: Alisdair requested to re-Open. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p>For stream buffers, add a function to the base class as a non-virtual function |
| qualified as const to 27.5.2 [streambuf]:</p> |
| |
| <p> <tt>openmode mode() const</tt>;</p> |
| |
| <p><b> Returns</b> the current open mode.</p> |
| |
| <p>With streams, I'm not sure what to suggest. In principle, the mode |
| could already be returned by <tt>ios_base</tt>, but the mode is only |
| initialized for file and string stream objects, unless I'm overlooking |
| anything. For this reason it should be added to the most derived |
| stream classes. Alternatively, it could be added to <tt>basic_ios</tt> |
| and would be default initialized in <tt>basic_ios<>::init()</tt>.</p> |
| |
| |
| <p><b>Rationale:</b></p> |
| <p>This might be an interesting extension for some future, but it is |
| not a defect in the current standard. The Proposed Resolution is |
| retained for future reference.</p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3> |
| <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#Ready">Ready</a> |
| <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>It is the constness of the container which should control whether |
| it can be modified through a member function such as erase(), not the |
| constness of the iterators. The iterators only serve to give |
| positioning information.</p> |
| |
| <p>Here's a simple and typical example problem which is currently very |
| difficult or impossible to solve without the change proposed |
| below.</p> |
| |
| <p>Wrap a standard container C in a class W which allows clients to |
| find and read (but not modify) a subrange of (C.begin(), C.end()]. The |
| only modification clients are allowed to make to elements in this |
| subrange is to erase them from C through the use of a member function |
| of W.</p> |
| |
| <p><i>[ |
| post Bellevue, Alisdair adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| This issue was implemented by |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a> |
| for everything but <tt>basic_string</tt>. |
| </p> |
| |
| <p> |
| Note that the specific example in this issue (<tt>basic_string</tt>) is the one place |
| we forgot to amend in |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>, |
| so we might open this issue for that |
| single container? |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| This was a fix that was intended for all standard library containers, |
| and has been done for other containers, but string was missed. |
| </p> |
| <p> |
| The wording updated. |
| </p> |
| <p> |
| We did not make the change in <tt>replace</tt>, because this change would affect |
| the implementation because the string may be written into. This is an |
| issue that should be taken up by concepts. |
| </p> |
| <p> |
| We note that the supplied wording addresses the initializer list provided in |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Update the following signature in the <tt>basic_string</tt> class template definition in |
| 21.3 [basic.string], p5: |
| </p> |
| <blockquote><pre>namespace std { |
| template<class charT, class traits = char_traits<charT>, |
| class Allocator = allocator<charT> > |
| class basic_string { |
| |
| ... |
| |
| iterator insert(<ins>const_</ins>iterator p, charT c); |
| void insert(<ins>const_</ins>iterator p, size_type n, charT c); |
| template<class InputIterator> |
| void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last); |
| void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list<charT>); |
| |
| ... |
| |
| iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position); |
| iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last); |
| |
| ... |
| |
| }; |
| } |
| </pre></blockquote> |
| |
| <p> |
| Update the following signatures in 21.3.6.4 [string::insert]: |
| </p> |
| |
| <blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c); |
| void insert(<ins>const_</ins>iterator p, size_type n, charT c); |
| template<class InputIterator> |
| void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last); |
| void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list<charT>); |
| </pre></blockquote> |
| |
| <p> |
| Update the following signatures in 21.3.6.5 [string::erase]: |
| </p> |
| |
| <blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position); |
| iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last); |
| </pre></blockquote> |
| |
| |
| |
| <p><b>Rationale:</b></p> |
| <p>The issue was discussed at length. It was generally agreed that 1) |
| There is no major technical argument against the change (although |
| there is a minor argument that some obscure programs may break), and |
| 2) Such a change would not break const correctness. The concerns about |
| making the change were 1) it is user detectable (although only in |
| boundary cases), 2) it changes a large number of signatures, and 3) it |
| seems more of a design issue that an out-and-out defect.</p> |
| |
| <p>The LWG believes that this issue should be considered as part of a |
| general review of const issues for the next revision of the |
| standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>Both std::min and std::max are defined as template functions. This |
| is very different than the definition of std::plus (and similar |
| structs) which are defined as function objects which inherit |
| std::binary_function.<br> |
| <br> |
| This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require |
| a function object that inherits std::binary_function.</p> |
| |
| <p><i>[ |
| post Bellevue: Alisdair requested to re-Open. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Rationale:</b></p> |
| <p>Although perhaps an unfortunate design decision, the omission is not a defect |
| in the current standard. A future standard may wish to consider additional |
| function objects.</p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="255"></a>255. Why do <tt>basic_streambuf<>::pbump()</tt> and <tt>gbump()</tt> take an int?</h3> |
| <p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-12</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The basic_streambuf members gbump() and pbump() are specified to take an |
| int argument. This requirement prevents the functions from effectively |
| manipulating buffers larger than std::numeric_limits<int>::max() |
| characters. It also makes the common use case for these functions |
| somewhat difficult as many compilers will issue a warning when an |
| argument of type larger than int (such as ptrdiff_t on LLP64 |
| architectures) is passed to either of the function. Since it's often the |
| result of the subtraction of two pointers that is passed to the |
| functions, a cast is necessary to silence such warnings. Finally, the |
| usage of a native type in the functions signatures is inconsistent with |
| other member functions (such as sgetn() and sputn()) that manipulate the |
| underlying character buffer. Those functions take a streamsize argument. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change the signatures of these functions in the synopsis of template |
| class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4 |
| and 27.5.2.3.2, p4) to take a streamsize argument. |
| </p> |
| |
| <p> |
| Although this change has the potential of changing the ABI of the |
| library, the change will affect only platforms where int is different |
| than the definition of streamsize. However, since both functions are |
| typically inline (they are on all known implementations), even on such |
| platforms the change will not affect any user code unless it explicitly |
| relies on the existing type of the functions (e.g., by taking their |
| address). Such a possibility is IMO quite remote. |
| </p> |
| |
| <p> |
| Alternate Suggestion from Howard Hinnant, c++std-lib-7780: |
| </p> |
| |
| <p> |
| This is something of a nit, but I'm wondering if streamoff wouldn't be a |
| better choice than streamsize. The argument to pbump and gbump MUST be |
| signed. But the standard has this to say about streamsize |
| (27.4.1/2/Footnote): |
| </p> |
| |
| <blockquote><p> |
| [Footnote: streamsize is used in most places where ISO C would use |
| size_t. Most of the uses of streamsize could use size_t, except for |
| the strstreambuf constructors, which require negative values. It |
| should probably be the signed type corresponding to size_t (which is |
| what Posix.2 calls ssize_t). --- end footnote] |
| </p></blockquote> |
| |
| <p> |
| This seems a little weak for the argument to pbump and gbump. Should we |
| ever really get rid of strstream, this footnote might go with it, along |
| with the reason to make streamsize signed. |
| </p> |
| |
| |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes this change is too big for now. We may wish to |
| reconsider this for a future revision of the standard. One |
| possibility is overloading pbump, rather than changing the |
| signature.</p> |
| <p><i>[ |
| [2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)] |
| ]</i></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="290"></a>290. Requirements to for_each and its function object</h3> |
| <p><b>Section:</b> 25.1.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-03</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>The specification of the for_each algorithm does not have a |
| "Requires" section, which means that there are no |
| restrictions imposed on the function object whatsoever. In essence it |
| means that I can provide any function object with arbitrary side |
| effects and I can still expect a predictable result. In particular I |
| can expect that the function object is applied exactly last - first |
| times, which is promised in the "Complexity" section. |
| </p> |
| |
| <p>I don't see how any implementation can give such a guarantee |
| without imposing requirements on the function object. |
| </p> |
| |
| <p>Just as an example: consider a function object that removes |
| elements from the input sequence. In that case, what does the |
| complexity guarantee (applies f exactly last - first times) mean? |
| </p> |
| |
| <p>One can argue that this is obviously a nonsensical application and |
| a theoretical case, which unfortunately it isn't. I have seen |
| programmers shooting themselves in the foot this way, and they did not |
| understand that there are restrictions even if the description of the |
| algorithm does not say so. |
| </p> |
| <p><i>[Lillehammer: This is more general than for_each. We don't want |
| the function object in transform invalidiating iterators |
| either. There should be a note somewhere in clause 17 (17, not 25) |
| saying that user code operating on a range may not invalidate |
| iterators unless otherwise specified. Bill will provide wording.]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3> |
| <p><b>Section:</b> 24.1.4 [bidirectional.iterators], 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> John Potter <b>Date:</b> 2001-01-22</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In section 24.1.4 [bidirectional.iterators], |
| Table 75 gives the return type of *r-- as convertible to T. This is |
| not consistent with Table 74 which gives the return type of *r++ as |
| T&. *r++ = t is valid while *r-- = t is invalid. |
| </p> |
| |
| <p> |
| In section 24.1.5 [random.access.iterators], |
| Table 76 gives the return type of a[n] as convertible to T. This is |
| not consistent with the semantics of *(a + n) which returns T& by |
| Table 74. *(a + n) = t is valid while a[n] = t is invalid. |
| </p> |
| |
| <p> |
| Discussion from the Copenhagen meeting: the first part is |
| uncontroversial. The second part, operator[] for Random Access |
| Iterators, requires more thought. There are reasonable arguments on |
| both sides. Return by value from operator[] enables some potentially |
| useful iterators, e.g. a random access "iota iterator" (a.k.a |
| "counting iterator" or "int iterator"). There isn't any obvious way |
| to do this with return-by-reference, since the reference would be to a |
| temporary. On the other hand, <tt>reverse_iterator</tt> takes an |
| arbitrary Random Access Iterator as template argument, and its |
| operator[] returns by reference. If we decided that the return type |
| in Table 76 was correct, we would have to change |
| <tt>reverse_iterator</tt>. This change would probably affect user |
| code. |
| </p> |
| |
| <p> |
| History: the contradiction between <tt>reverse_iterator</tt> and the |
| Random Access Iterator requirements has been present from an early |
| stage. In both the STL proposal adopted by the committee |
| (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by |
| Stepanov and Lee), the Random Access Iterator requirements say that |
| operator[]'s return value is "convertible to T". In N0527 |
| reverse_iterator's operator[] returns by value, but in HPL-95-11 |
| (R.1), and in the STL implementation that HP released to the public, |
| reverse_iterator's operator[] returns by reference. In 1995, the |
| standard was amended to reflect the contents of HPL-95-11 (R.1). The |
| original intent for operator[] is unclear. |
| </p> |
| |
| <p> |
| In the long term it may be desirable to add more fine-grained |
| iterator requirements, so that access method and traversal strategy |
| can be decoupled. (See "Improved Iterator Categories and |
| Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions |
| about issue 299 should keep this possibility in mind. |
| </p> |
| |
| <p>Further discussion: I propose a compromise between John Potter's |
| resolution, which requires <tt>T&</tt> as the return type of |
| <tt>a[n]</tt>, and the current wording, which requires convertible to |
| <tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt> |
| for the return type of the expression <tt>a[n]</tt>, but to also add |
| <tt>a[n] = t</tt> as a valid expression. This compromise "saves" the |
| common case uses of random access iterators, while at the same time |
| allowing iterators such as counting iterator and caching file |
| iterators to remain random access iterators (iterators where the |
| lifetime of the object returned by <tt>operator*()</tt> is tied to the |
| lifetime of the iterator). |
| </p> |
| |
| <p> |
| Note that the compromise resolution necessitates a change to |
| <tt>reverse_iterator</tt>. It would need to use a proxy to support |
| <tt>a[n] = t</tt>. |
| </p> |
| |
| <p> |
| Note also there is one kind of mutable random access iterator that |
| will no longer meet the new requirements. Currently, iterators that |
| return an r-value from <tt>operator[]</tt> meet the requirements for a |
| mutable random access iterartor, even though the expression <tt>a[n] = |
| t</tt> will only modify a temporary that goes away. With this proposed |
| resolution, <tt>a[n] = t</tt> will be required to have the same |
| operational semantics as <tt>*(a + n) = t</tt>. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| In section 24.1.4 [lib.bidirectdional.iterators], change the return |
| type in table 75 from "convertible to <tt>T</tt>" to |
| <tt>T&</tt>. |
| </p> |
| |
| <p> |
| In section 24.1.5 [lib.random.access.iterators], change the |
| operational semantics for <tt>a[n]</tt> to " the r-value of |
| <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a + |
| n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt> |
| with a return type of convertible to <tt>T</tt> and operational semantics of |
| <tt>*(a + n) = t</tt>. |
| </p> |
| |
| <p><i>[Lillehammer: Real problem, but should be addressed as part of |
| iterator redesign]</i></p> |
| |
| |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="309"></a>309. Does sentry catch exceptions?</h3> |
| <p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-19</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The descriptions of the constructors of basic_istream<>::sentry |
| (27.6.1.1.3 [istream::sentry]) and basic_ostream<>::sentry |
| (27.6.2.4 [ostream::sentry]) do not explain what the functions do in |
| case an exception is thrown while they execute. Some current |
| implementations allow all exceptions to propagate, others catch them |
| and set ios_base::badbit instead, still others catch some but let |
| others propagate. |
| </p> |
| |
| <p> |
| The text also mentions that the functions may call setstate(failbit) |
| (without actually saying on what object, but presumably the stream |
| argument is meant). That may have been fine for |
| basic_istream<>::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since |
| the function performs an input operation which may fail. However, |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.6.1.1.3 [istream::sentry], p2 to |
| clarify that the function should actually call setstate(failbit | |
| eofbit), so the sentence in p3 is redundant or even somewhat |
| contradictory. |
| </p> |
| |
| <p> |
| The same sentence that appears in 27.6.2.4 [ostream::sentry], p3 |
| doesn't seem to be very meaningful for basic_istream<>::sentry |
| which performs no input. It is actually rather misleading since it |
| would appear to guide library implementers to calling |
| setstate(failbit) when os.tie()->flush(), the only called function, |
| throws an exception (typically, it's badbit that's set in response to |
| such an event). |
| </p> |
| |
| <p><b>Additional comments from Martin, who isn't comfortable with the |
| current proposed resolution</b> (see c++std-lib-11530)</p> |
| |
| <p> |
| The istream::sentry ctor says nothing about how the function |
| deals with exemptions (27.6.1.1.2, p1 says that the class is |
| responsible for doing "exception safe"(*) prefix and suffix |
| operations but it doesn't explain what level of exception |
| safety the class promises to provide). The mockup example |
| of a "typical implementation of the sentry ctor" given in |
| 27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show |
| exception handling, either. Since the ctor is not classified |
| as a formatted or unformatted input function, the text in |
| 27.6.1.1, p1 through p4 does not apply. All this would seem |
| to suggest that the sentry ctor should not catch or in any |
| way handle exceptions thrown from any functions it may call. |
| Thus, the typical implementation of an istream extractor may |
| look something like [1]. |
| </p> |
| |
| <p> |
| The problem with [1] is that while it correctly sets ios::badbit |
| if an exception is thrown from one of the functions called from |
| the sentry ctor, if the sentry ctor reaches EOF while extracting |
| whitespace from a stream that has eofbit or failbit set in |
| exceptions(), it will cause an ios::failure to be thrown, which |
| will in turn cause the extractor to set ios::badbit. |
| </p> |
| |
| <p> |
| The only straightforward way to prevent this behavior is to |
| move the definition of the sentry object in the extractor |
| above the try block (as suggested by the example in 22.2.8, |
| p9 and also indirectly supported by 27.6.1.3, p1). See [2]. |
| But such an implementation will allow exceptions thrown from |
| functions called from the ctor to freely propagate to the |
| caller regardless of the setting of ios::badbit in the stream |
| object's exceptions(). |
| </p> |
| |
| <p> |
| So since neither [1] nor [2] behaves as expected, the only |
| possible solution is to have the sentry ctor catch exceptions |
| thrown from called functions, set badbit, and propagate those |
| exceptions if badbit is also set in exceptions(). (Another |
| solution exists that deals with both kinds of sentries, but |
| the code is non-obvious and cumbersome -- see [3].) |
| </p> |
| |
| <p> |
| Please note that, as the issue points out, current libraries |
| do not behave consistently, suggesting that implementors are |
| not quite clear on the exception handling in istream::sentry, |
| despite the fact that some LWG members might feel otherwise. |
| (As documented by the parenthetical comment here: |
| http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309) |
| </p> |
| |
| <p> |
| Also please note that those LWG members who in Copenhagen |
| felt that "a sentry's constructor should not catch exceptions, |
| because sentries should only be used within (un)formatted input |
| functions and that exception handling is the responsibility of |
| those functions, not of the sentries," as noted here |
| http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309 |
| would in effect be either arguing for the behavior described |
| in [1] or for extractors implemented along the lines of [3]. |
| </p> |
| |
| <p> |
| The original proposed resolution (Revision 25 of the issues |
| list) clarifies the role of the sentry ctor WRT exception |
| handling by making it clear that extractors (both library |
| or user-defined) should be implemented along the lines of |
| [2] (as opposed to [1]) and that no exception thrown from |
| the callees should propagate out of either function unless |
| badbit is also set in exceptions(). |
| </p> |
| |
| |
| <p>[1] Extractor that catches exceptions thrown from sentry:</p> |
| |
| <blockquote> |
| <pre>struct S { long i; }; |
| |
| istream& operator>> (istream &strm, S &s) |
| { |
| ios::iostate err = ios::goodbit; |
| try { |
| const istream::sentry guard (strm, false); |
| if (guard) { |
| use_facet<num_get<char> >(strm.getloc ()) |
| .get (istreambuf_iterator<char>(strm), |
| istreambuf_iterator<char>(), |
| strm, err, s.i); |
| } |
| } |
| catch (...) { |
| bool rethrow; |
| try { |
| strm.setstate (ios::badbit); |
| rethrow = false; |
| } |
| catch (...) { |
| rethrow = true; |
| } |
| if (rethrow) |
| throw; |
| } |
| if (err) |
| strm.setstate (err); |
| return strm; |
| } |
| </pre> |
| </blockquote> |
| |
| <p>[2] Extractor that propagates exceptions thrown from sentry:</p> |
| |
| <blockquote> |
| <pre>istream& operator>> (istream &strm, S &s) |
| { |
| istream::sentry guard (strm, false); |
| if (guard) { |
| ios::iostate err = ios::goodbit; |
| try { |
| use_facet<num_get<char> >(strm.getloc ()) |
| .get (istreambuf_iterator<char>(strm), |
| istreambuf_iterator<char>(), |
| strm, err, s.i); |
| } |
| catch (...) { |
| bool rethrow; |
| try { |
| strm.setstate (ios::badbit); |
| rethrow = false; |
| } |
| catch (...) { |
| rethrow = true; |
| } |
| if (rethrow) |
| throw; |
| } |
| if (err) |
| strm.setstate (err); |
| } |
| return strm; |
| } |
| </pre> |
| </blockquote> |
| |
| <p> |
| [3] Extractor that catches exceptions thrown from sentry |
| but doesn't set badbit if the exception was thrown as a |
| result of a call to strm.clear(). |
| </p> |
| |
| <blockquote> |
| <pre>istream& operator>> (istream &strm, S &s) |
| { |
| const ios::iostate state = strm.rdstate (); |
| const ios::iostate except = strm.exceptions (); |
| ios::iostate err = std::ios::goodbit; |
| bool thrown = true; |
| try { |
| const istream::sentry guard (strm, false); |
| thrown = false; |
| if (guard) { |
| use_facet<num_get<char> >(strm.getloc ()) |
| .get (istreambuf_iterator<char>(strm), |
| istreambuf_iterator<char>(), |
| strm, err, s.i); |
| } |
| } |
| catch (...) { |
| if (thrown && state & except) |
| throw; |
| try { |
| strm.setstate (ios::badbit); |
| thrown = false; |
| } |
| catch (...) { |
| thrown = true; |
| } |
| if (thrown) |
| throw; |
| } |
| if (err) |
| strm.setstate (err); |
| |
| return strm; |
| } |
| </pre> |
| </blockquote> |
| |
| <p> |
| [Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage. |
| </p> |
| |
| <p> |
| [Pre-Portland] A relevant newsgroup post: |
| </p> |
| |
| <p> |
| The current proposed resolution of issue #309 |
| (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is |
| unacceptable. I write commerical software and coding around this |
| makes my code ugly, non-intuitive, and requires comments referring |
| people to this very issue. Following is the full explanation of my |
| experience. |
| </p> |
| <p> |
| In the course of writing software for commercial use, I constructed |
| std::ifstream's based on user-supplied pathnames on typical POSIX |
| systems. |
| </p> |
| <p> |
| It was expected that some files that opened successfully might not read |
| successfully -- such as a pathname which actually refered to a |
| directory. Intuitively, I expected the streambuffer underflow() code |
| to throw an exception in this situation, and recent implementations of |
| libstdc++'s basic_filebuf do just that (as well as many of my own |
| custom streambufs). |
| </p> |
| <p> |
| I also intuitively expected that the istream code would convert these |
| exceptions to the "badbit' set on the stream object, because I had not |
| requested exceptions. I refer to 27.6.1.1. P4. |
| </p> |
| <p> |
| However, this was not the case on at least two implementations -- if |
| the first thing I did with an istream was call operator>>( T& ) for T |
| among the basic arithmetic types and std::string. Looking further I |
| found that the sentry's constructor was invoking the exception when it |
| pre-scanned for whitespace, and the extractor function (operator>>()) |
| was not catching exceptions in this situation. |
| </p> |
| <p> |
| So, I was in a situation where setting 'noskipws' would change the |
| istream's behavior even though no characters (whitespace or not) could |
| ever be successfully read. |
| </p> |
| <p> |
| Also, calling .peek() on the istream before calling the extractor() |
| changed the behavior (.peek() had the effect of setting the badbit |
| ahead of time). |
| </p> |
| <p> |
| I found this all to be so inconsistent and inconvenient for me and my |
| code design, that I filed a bugzilla entry for libstdc++. I was then |
| told that the bug cannot be fixed until issue #309 is resolved by the |
| committee. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| <p><b>Rationale:</b></p> |
| <p>The LWG agrees there is minor variation between implementations, |
| but believes that it doesn't matter. This is a rarely used corner |
| case. There is no evidence that this has any commercial importance |
| or that it causes actual portability problems for customers trying |
| to write code that runs on multiple implementations.</p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="342"></a>342. seek and eofbit</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-09</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>I think we have a defect.</p> |
| |
| <p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the |
| description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks |
| like:</p> |
| |
| <blockquote><p> |
| Behaves as an unformatted input function (as described in 27.6.1.3, |
| paragraph 1), except that it does not count the number of characters |
| extracted and does not affect the value returned by subsequent calls to |
| gcount(). After constructing a sentry object, if fail() != true, |
| executes rdbuf()->pubseekpos( pos). |
| </p></blockquote> |
| |
| <p>And according to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> which is also now a dr, |
| 27.6.1.3, paragraph 1 looks like:</p> |
| |
| <blockquote><p> |
| Each unformatted input function begins execution by constructing an |
| object of class sentry with the default argument noskipws (second) |
| argument true. If the sentry object returns true, when converted to a |
| value of type bool, the function endeavors to obtain the requested |
| input. Otherwise, if the sentry constructor exits by throwing an |
| exception or if the sentry object returns false, when converted to a |
| value of type bool, the function returns without attempting to obtain |
| any input. In either case the number of extracted characters is set to |
| 0; unformatted input functions taking a character array of non-zero |
| size as an argument shall also store a null character (using charT()) |
| in the first location of the array. If an exception is thrown during |
| input then ios::badbit is turned on in *this'ss error state. If |
| (exception()&badbit)!= 0 then the exception is rethrown. It also counts |
| the number of characters extracted. If no exception has been thrown it |
| ends by storing the count in a member object and returning the value |
| specified. In any event the sentry object is destroyed before leaving |
| the unformatted input function. |
| </p></blockquote> |
| |
| <p>And finally 27.6.1.1.2/5 says this about sentry:</p> |
| |
| <blockquote><p> |
| If, after any preparation is completed, is.good() is true, ok_ != false |
| otherwise, ok_ == false. |
| </p></blockquote> |
| |
| <p> |
| So although the seekg paragraph says that the operation proceeds if |
| !fail(), the behavior of unformatted functions says the operation |
| proceeds only if good(). The two statements are contradictory when only |
| eofbit is set. I don't think the current text is clear which condition |
| should be respected. |
| </p> |
| |
| <p><b>Further discussion from Redmond:</b></p> |
| |
| <p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is |
| "unformatted". That makes specific claims about sentry that |
| aren't quite appropriate for seeking, which has less fragile failure |
| modes than actual input. If we do really mean that it's unformatted |
| input, it should behave the same way as other unformatted input. On |
| the other hand, "principle of least surprise" is that seeking from EOF |
| ought to be OK.</p> |
| |
| <p> |
| Pre-Berlin: Paolo points out several problems with the proposed resolution in |
| Ready state: |
| </p> |
| |
| <ul> |
| <li>It should apply to both overloads of seekg.</li> |
| <li>tellg has similar issues, except that it should not call clear().</li> |
| <li>The point about clear() seems to apply to seekp().</li> |
| <li>Depending on the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#419">419</a> |
| if the sentry |
| sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then |
| you can never seek away from the end of stream.</li> |
| </ul> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p>Change 27.6.1.3 [istream.unformatted] to:</p> |
| <blockquote><p> |
| Behaves as an unformatted input function (as described in 27.6.1.3, |
| paragraph 1), except that it does not count the number of characters |
| extracted, does not affect the value returned by subsequent calls to |
| gcount(), and does not examine the value returned by the sentry |
| object. After constructing a sentry object, if <tt>fail() != |
| true</tt>, executes <tt>rdbuf()->pubseekpos(pos)</tt>. In |
| case of success, the function calls clear(). |
| In case of failure, the function calls <tt>setstate(failbit)</tt> |
| (which may throw <tt>ios_base::failure</tt>). |
| </p></blockquote> |
| |
| <p><i>[Lillehammer: Matt provided wording.]</i></p> |
| |
| |
| |
| |
| <p><b>Rationale:</b></p> |
| <p>In C, fseek does clear EOF. This is probably what most users would |
| expect. We agree that having eofbit set should not deter a seek, |
| and that a successful seek should clear eofbit. Note |
| that <tt>fail()</tt> is true only if <tt>failbit</tt> |
| or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather |
| than <tt>good()</tt>, satisfies this goal.</p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="343"></a>343. Unspecified library header dependencies</h3> |
| <p><b>Section:</b> 21 [strings], 23 [containers], 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-10-09</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The synopses of the C++ library headers clearly show which names are |
| required to be defined in each header. Since in order to implement the |
| classes and templates defined in these headers declarations of other |
| templates (but not necessarily their definitions) are typically |
| necessary the standard in 17.4.4, p1 permits library implementers to |
| include any headers needed to implement the definitions in each header. |
| </p> |
| |
| <p> |
| For instance, although it is not explicitly specified in the synopsis of |
| <string>, at the point of definition of the std::basic_string template |
| the declaration of the std::allocator template must be in scope. All |
| current implementations simply include <memory> from within <string>, |
| either directly or indirectly, to bring the declaration of |
| std::allocator into scope. |
| </p> |
| |
| <p> |
| Additionally, however, some implementation also include <istream> and |
| <ostream> at the top of <string> to bring the declarations of |
| std::basic_istream and std::basic_ostream into scope (which are needed |
| in order to implement the string inserter and extractor operators |
| (21.3.7.9 [lib.string.io])). Other implementations only include |
| <iosfwd>, since strictly speaking, only the declarations and not the |
| full definitions are necessary. |
| </p> |
| |
| <p> |
| Obviously, it is possible to implement <string> without actually |
| providing the full definitions of all the templates std::basic_string |
| uses (std::allocator, std::basic_istream, and std::basic_ostream). |
| Furthermore, not only is it possible, doing so is likely to have a |
| positive effect on compile-time efficiency. |
| </p> |
| |
| <p> |
| But while it may seem perfectly reasonable to expect a program that uses |
| the std::basic_string insertion and extraction operators to also |
| explicitly include <istream> or <ostream>, respectively, it doesn't seem |
| reasonable to also expect it to explicitly include <memory>. Since |
| what's reasonable and what isn't is highly subjective one would expect |
| the standard to specify what can and what cannot be assumed. |
| Unfortunately, that isn't the case. |
| </p> |
| |
| <p>The examples below demonstrate the issue.</p> |
| |
| <p>Example 1:</p> |
| |
| <p>It is not clear whether the following program is complete:</p> |
| |
| <pre>#include <string> |
| |
| extern std::basic_ostream<char> &strm; |
| |
| int main () { |
| strm << std::string ("Hello, World!\n"); |
| } |
| </pre> |
| |
| <p>or whether one must explicitly include <memory> or |
| <ostream> (or both) in addition to <string> in order for |
| the program to compile.</p> |
| |
| |
| <p>Example 2:</p> |
| |
| <p>Similarly, it is unclear whether the following program is complete:</p> |
| |
| <pre>#include <istream> |
| |
| extern std::basic_iostream<char> &strm; |
| |
| int main () { |
| strm << "Hello, World!\n"; |
| } |
| </pre> |
| |
| <p> |
| or whether one needs to explicitly include <ostream>, and |
| perhaps even other headers containing the definitions of other |
| required templates:</p> |
| |
| <pre>#include <ios> |
| #include <istream> |
| #include <ostream> |
| #include <streambuf> |
| |
| extern std::basic_iostream<char> &strm; |
| |
| int main () { |
| strm << "Hello, World!\n"; |
| } |
| </pre> |
| |
| <p>Example 3:</p> |
| |
| <p>Likewise, it seems unclear whether the program below is complete:</p> |
| <pre>#include <iterator> |
| |
| bool foo (std::istream_iterator<int> a, std::istream_iterator<int> b) |
| { |
| return a == b; |
| } |
| |
| int main () { } |
| </pre> |
| |
| <p>or whether one should be required to include <istream>.</p> |
| |
| <p>There are many more examples that demonstrate this lack of a |
| requirement. I believe that in a good number of cases it would be |
| unreasonable to require that a program explicitly include all the |
| headers necessary for a particular template to be specialized, but I |
| think that there are cases such as some of those above where it would |
| be desirable to allow implementations to include only as much as |
| necessary and not more.</p> |
| |
| <p><i>[ |
| post Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Position taken in prior reviews is that the idea of a table of header |
| dependencies is a good one. Our view is that a full paper is needed to |
| do justice to this, and we've made that recommendation to the issue |
| author. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| For every C++ library header, supply a minimum set of other C++ library |
| headers that are required to be included by that header. The proposed |
| list is below (C++ headers for C Library Facilities, table 12 in |
| 17.4.1.2, p3, are omitted): |
| </p> |
| |
| <pre>+------------+--------------------+ |
| | C++ header |required to include | |
| +============+====================+ |
| |<algorithm> | | |
| +------------+--------------------+ |
| |<bitset> | | |
| +------------+--------------------+ |
| |<complex> | | |
| +------------+--------------------+ |
| |<deque> |<memory> | |
| +------------+--------------------+ |
| |<exception> | | |
| +------------+--------------------+ |
| |<fstream> |<ios> | |
| +------------+--------------------+ |
| |<functional>| | |
| +------------+--------------------+ |
| |<iomanip> |<ios> | |
| +------------+--------------------+ |
| |<ios> |<streambuf> | |
| +------------+--------------------+ |
| |<iosfwd> | | |
| +------------+--------------------+ |
| |<iostream> |<istream>, <ostream>| |
| +------------+--------------------+ |
| |<istream> |<ios> | |
| +------------+--------------------+ |
| |<iterator> | | |
| +------------+--------------------+ |
| |<limits> | | |
| +------------+--------------------+ |
| |<list> |<memory> | |
| +------------+--------------------+ |
| |<locale> | | |
| +------------+--------------------+ |
| |<map> |<memory> | |
| +------------+--------------------+ |
| |<memory> | | |
| +------------+--------------------+ |
| |<new> |<exception> | |
| +------------+--------------------+ |
| |<numeric> | | |
| +------------+--------------------+ |
| |<ostream> |<ios> | |
| +------------+--------------------+ |
| |<queue> |<deque> | |
| +------------+--------------------+ |
| |<set> |<memory> | |
| +------------+--------------------+ |
| |<sstream> |<ios>, <string> | |
| +------------+--------------------+ |
| |<stack> |<deque> | |
| +------------+--------------------+ |
| |<stdexcept> | | |
| +------------+--------------------+ |
| |<streambuf> |<ios> | |
| +------------+--------------------+ |
| |<string> |<memory> | |
| +------------+--------------------+ |
| |<strstream> | | |
| +------------+--------------------+ |
| |<typeinfo> |<exception> | |
| +------------+--------------------+ |
| |<utility> | | |
| +------------+--------------------+ |
| |<valarray> | | |
| +------------+--------------------+ |
| |<vector> |<memory> | |
| +------------+--------------------+ |
| </pre> |
| |
| |
| <p><b>Rationale:</b></p> |
| <p>The portability problem is real. A program that works correctly on |
| one implementation might fail on another, because of different header |
| dependencies. This problem was understood before the standard was |
| completed, and it was a conscious design choice.</p> |
| <p>One possible way to deal with this, as a library extension, would |
| be an <all> header.</p> |
| |
| <p> |
| Hinnant: It's time we dealt with this issue for C++0X. Reopened. |
| </p> |
| |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="382"></a>382. codecvt do_in/out result</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-08-30</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| It seems that the descriptions of codecvt do_in() and do_out() leave |
| sufficient room for interpretation so that two implementations of |
| codecvt may not work correctly with the same filebuf. Specifically, |
| the following seems less than adequately specified: |
| </p> |
| |
| <ol> |
| <li> |
| the conditions under which the functions terminate |
| </li> |
| <li> |
| precisely when the functions return ok |
| </li> |
| <li> |
| precisely when the functions return partial |
| </li> |
| <li> |
| the full set of conditions when the functions return error |
| </li> |
| </ol> |
| |
| <ol> |
| <li> |
| 22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the |
| function: ...Stops if it encounters a character it cannot |
| convert... This assumes that there *is* a character to |
| convert. What happens when there is a sequence that doesn't form a |
| valid source character, such as an unassigned or invalid UNICODE |
| character, or a sequence that cannot possibly form a character |
| (e.g., the sequence "\xc0\xff" in UTF-8)? |
| </li> |
| <li> |
| Table 53 says that the function returns codecvt_base::ok |
| to indicate that the function(s) "completed the conversion." |
| Suppose that the source sequence is "\xc0\x80" in UTF-8, |
| with from pointing to '\xc0' and (from_end==from + 1). |
| It is not clear whether the return value should be ok |
| or partial (see below). |
| </li> |
| <li> |
| Table 53 says that the function returns codecvt_base::partial |
| if "not all source characters converted." With the from pointers |
| set up the same way as above, it is not clear whether the return |
| value should be partial or ok (see above). |
| </li> |
| <li> |
| Table 53, in the row describing the meaning of error mistakenly |
| refers to a "from_type" character, without the symbol from_type |
| having been defined. Most likely, the word "source" character |
| is intended, although that is not sufficient. The functions |
| may also fail when they encounter an invalid source sequence |
| that cannot possibly form a valid source character (e.g., as |
| explained in bullet 1 above). |
| </li> |
| </ol> |
| <p> |
| Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible: |
| </p> |
| <blockquote><p> |
| "A return value of partial, if (from_next == from_end), |
| indicates that either the destination sequence has not |
| absorbed all the available destination elements, or that |
| additional source elements are needed before another |
| destination element can be produced." |
| </p></blockquote> |
| <p> |
| If the value is partial, it's not clear to me that (from_next |
| ==from_end) could ever hold if there isn't enough room |
| in the destination buffer. In order for (from_next==from_end) to |
| hold, all characters in that range must have been successfully |
| converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no |
| further source characters to convert, no more room in the |
| destination buffer can be needed. |
| </p> |
| <p> |
| It's also not clear to me that (from_next==from_end) could ever |
| hold if additional source elements are needed to produce another |
| destination character (not element as incorrectly stated in the |
| text). partial is returned if "not all source characters have |
| been converted" according to Table 53, which also implies that |
| (from_next==from) does NOT hold. |
| </p> |
| <p> |
| Could it be that the intended qualifying condition was actually |
| (from_next != from_end), i.e., that the sentence was supposed |
| to read |
| </p> |
| <blockquote><p> |
| "A return value of partial, if (from_next != from_end),..." |
| </p></blockquote> |
| <p> |
| which would make perfect sense, since, as far as I understand it, |
| partial can only occur if (from_next != from_end)? |
| </p> |
| <p><i>[Lillehammer: Defer for the moment, but this really needs to be |
| fixed. Right now, the description of codecvt is too vague for it to |
| be a useful contract between providers and clients of codecvt |
| facets. (Note that both vendors and users can be both providers and |
| clients of codecvt facets.) The major philosophical issue is whether |
| the standard should only describe mappings that take a single wide |
| character to multiple narrow characters (and vice versa), or whether |
| it should describe fully general N-to-M conversions. When the |
| original standard was written only the former was contemplated, but |
| today, in light of the popularity of utf8 and utf16, that doesn't |
| seem sufficient for C++0x. Bill supports general N-to-M conversions; |
| we need to make sure Martin and Howard agree.]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="387"></a>387. std::complex over-encapsulated</h3> |
| <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#Ready">Ready</a> |
| <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The absence of explicit description of std::complex<T> layout |
| makes it imposible to reuse existing software developed in traditional |
| languages like Fortran or C with unambigous and commonly accepted |
| layout assumptions. There ought to be a way for practitioners to |
| predict with confidence the layout of std::complex<T> whenever T |
| is a numerical datatype. The absence of ways to access individual |
| parts of a std::complex<T> object as lvalues unduly promotes |
| severe pessimizations. For example, the only way to change, |
| independently, the real and imaginary parts is to write something like |
| </p> |
| |
| <pre>complex<T> z; |
| // ... |
| // set the real part to r |
| z = complex<T>(r, z.imag()); |
| // ... |
| // set the imaginary part to i |
| z = complex<T>(z.real(), i); |
| </pre> |
| |
| <p> |
| At this point, it seems appropriate to recall that a complex number |
| is, in effect, just a pair of numbers with no particular invariant to |
| maintain. Existing practice in numerical computations has it that a |
| complex number datatype is usually represented by Cartesian |
| coordinates. Therefore the over-encapsulation put in the specification |
| of std::complex<> is not justified. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p>Add the following requirements to 26.3 [complex.numbers] as 26.3/4:</p> |
| <blockquote> |
| <p>If z is an lvalue expression of type cv std::complex<T> then</p> |
| |
| <ul> |
| <li>the expression reinterpret_cast<cv T(&)[2]>(z) |
| is well-formed; and</li> |
| <li>reinterpret_cast<cv T(&)[2]>(z)[0]designates the |
| real part of z; and</li> |
| <li>reinterpret_cast<cv T(&)[2]>(z)[1]designates the |
| imaginary part of z.</li> |
| </ul> |
| |
| <p> |
| Moreover, if a is an expression of pointer type cv complex<T>* |
| and the expression a[i] is well-defined for an integer expression |
| i then: |
| </p> |
| |
| <ul> |
| <li>reinterpret_cast<cv T*>(a)[2*i] designates the real |
| part of a[i]; and</li> |
| <li>reinterpret_cast<cv T*>(a)[2*i+1] designates the |
| imaginary part of a[i].</li> |
| </ul> |
| </blockquote> |
| |
| <p> |
| In 26.3.2 [complex] and 26.3.3 [complex.special] add the following member functions |
| (changing <tt>T</tt> to concrete types as appropriate for the specializations). |
| </p> |
| |
| <blockquote><pre>void real(T); |
| void imag(T); |
| </pre></blockquote> |
| |
| <p> |
| Add to 26.3.4 [complex.members] |
| </p> |
| |
| <blockquote> |
| <pre>T real() const; |
| </pre> |
| <blockquote> |
| <i>Returns:</i> the value of the real component |
| </blockquote> |
| <pre>void real(T val); |
| </pre> |
| <blockquote> |
| Assigns val to the real component. |
| </blockquote> |
| <pre>T imag() const; |
| </pre> |
| <blockquote> |
| <i>Returns:</i> the value of the imaginary component |
| </blockquote> |
| <pre>void imag(T val); |
| </pre> |
| <blockquote> |
| Assigns val to the imaginary component. |
| </blockquote> |
| </blockquote> |
| |
| <p><i>[Kona: The layout guarantee is absolutely necessary for C |
| compatibility. However, there was disagreement about the other part |
| of this proposal: retrieving elements of the complex number as |
| lvalues. An alternative: continue to have real() and imag() return |
| rvalues, but add set_real() and set_imag(). Straw poll: return |
| lvalues - 2, add setter functions - 5. Related issue: do we want |
| reinterpret_cast as the interface for converting a complex to an |
| array of two reals, or do we want to provide a more explicit way of |
| doing it? Howard will try to resolve this issue for the next |
| meeting.]</i></p> |
| |
| |
| <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p> |
| |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Second half of proposed wording replaced and moved to Ready. |
| </blockquote> |
| |
| <p><i>[ |
| Pre-Sophia Antipolis, Howard adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Added the members to 26.3.3 [complex.special] and changed from Ready to Review. |
| </blockquote> |
| |
| <p><i>[ |
| Post-Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Moved from WP back to Ready so that the "and 26.3.3 [complex.special]" in the proposed |
| resolution can be officially applied. |
| </blockquote> |
| |
| |
| |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes that C99 compatibility would be enough |
| justification for this change even without other considerations. All |
| existing implementations already have the layout proposed here.</p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="394"></a>394. behavior of formatted output on failure</h3> |
| <p><b>Section:</b> 27.6.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-12-27</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| There is a contradiction in Formatted output about what bit is |
| supposed to be set if the formatting fails. On sentence says it's |
| badbit and another that it's failbit. |
| </p> |
| <p> |
| 27.6.2.5.1, p1 says in the Common Requirements on Formatted output |
| functions: |
| </p> |
| <pre> ... If the generation fails, then the formatted output function |
| does setstate(ios::failbit), which might throw an exception. |
| </pre> |
| <p> |
| 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters: |
| </p> |
| <p> |
| ... The formatting conversion occurs as if it performed the |
| following code fragment: |
| </p> |
| <pre> bool failed = |
| use_facet<num_put<charT,ostreambuf_iterator<charT,traits> |
| > > |
| (getloc()).put(*this, *this, fill(), val). failed(); |
| |
| ... If failed is true then does setstate(badbit) ... |
| </pre> |
| <p> |
| The original intent of the text, according to Jerry Schwarz (see |
| c++std-lib-10500), is captured in the following paragraph: |
| </p> |
| <p> |
| In general "badbit" should mean that the stream is unusable because |
| of some underlying failure, such as disk full or socket closure; |
| "failbit" should mean that the requested formatting wasn't possible |
| because of some inconsistency such as negative widths. So typically |
| if you clear badbit and try to output something else you'll fail |
| again, but if you clear failbit and try to output something else |
| you'll succeed. |
| </p> |
| <p> |
| In the case of the arithmetic inserters, since num_put cannot |
| report failure by any means other than exceptions (in response |
| to which the stream must set badbit, which prevents the kind of |
| recoverable error reporting mentioned above), the only other |
| detectable failure is if the iterator returned from num_put |
| returns true from failed(). |
| </p> |
| <p> |
| Since that can only happen (at least with the required iostream |
| specializations) under such conditions as the underlying failure |
| referred to above (e.g., disk full), setting badbit would seem |
| to be the appropriate response (indeed, it is required in |
| 27.6.2.5.2, p1). It follows that failbit can never be directly |
| set by the arithmetic (it can only be set by the sentry object |
| under some unspecified conditions). |
| </p> |
| <p> |
| The situation is different for other formatted output functions |
| which can fail as a result of the streambuf functions failing |
| (they may do so by means other than exceptions), and which are |
| then required to set failbit. |
| </p> |
| <p> |
| The contradiction, then, is that ostream::operator<<(int) will |
| set badbit if the disk is full, while operator<<(ostream&, |
| char) will set failbit under the same conditions. To make the behavior |
| consistent, the Common requirements sections for the Formatted output |
| functions should be changed as proposed below. |
| </p> |
| <p><i>[Kona: There's agreement that this is a real issue. What we |
| decided at Kona: 1. An error from the buffer (which can be detected |
| either directly from streambuf's member functions or by examining a |
| streambuf_iterator) should always result in badbit getting set. |
| 2. There should never be a circumstance where failbit gets set. |
| That represents a formatting error, and there are no circumstances |
| under which the output facets are specified as signaling a |
| formatting error. (Even more so for string output that for numeric |
| because there's nothing to format.) If we ever decide to make it |
| possible for formatting errors to exist then the facets can signal |
| the error directly, and that should go in clause 22, not clause 27. |
| 3. The phrase "if generation fails" is unclear and should be |
| eliminated. It's not clear whether it's intended to mean a buffer |
| error (e.g. a full disk), a formatting error, or something else. |
| Most people thought it was supposed to refer to buffer errors; if |
| so, we should say so. Martin will provide wording.]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| <p><b>Rationale:</b></p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="396"></a>396. what are characters zero and one</h3> |
| <p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character |
| having the value of 0 or 1 but there is no definition of what |
| that means for charT other than char and wchar_t. And even for |
| those two types, the values 0 and 1 are not actually what is |
| intended -- the values '0' and '1' are. This, along with the |
| converse problem in the description of to_string() in 23.3.5.2, |
| p33, looks like a defect remotely related to DR 303. |
| </p> |
| <p> |
| http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303 |
| </p> |
| <pre>23.3.5.1: |
| -6- An element of the constructed string has value zero if the |
| corresponding character in str, beginning at position pos, |
| is 0. Otherwise, the element has the value one. |
| </pre> |
| <pre>23.3.5.2: |
| -33- Effects: Constructs a string object of the appropriate |
| type and initializes it to a string of length N characters. |
| Each character is determined by the value of its |
| corresponding bit position in *this. Character position N |
| ?- 1 corresponds to bit position zero. Subsequent decreasing |
| character positions correspond to increasing bit positions. |
| Bit value zero becomes the character 0, bit value one becomes |
| the character 1. |
| </pre> |
| <p> |
| Also note the typo in 23.3.5.1, p6: the object under construction |
| is a bitset, not a string. |
| </p> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| We note that <tt>bitset</tt> has been moved from section 23 to section 20, by |
| another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>) previously resolved at this meeting. |
| </p> |
| <p> |
| Disposition: move to ready. |
| </p> |
| <p> |
| We request that Howard submit a separate issue regarding the three to_string overloads. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p>Change the constructor's function declaration immediately before |
| 23.3.5.1 [bitset.cons] p3 to:</p> |
| <pre> template <class charT, class traits, class Allocator> |
| explicit |
| bitset(const basic_string<charT, traits, Allocator>& str, |
| typename basic_string<charT, traits, Allocator>::size_type pos = 0, |
| typename basic_string<charT, traits, Allocator>::size_type n = |
| basic_string<charT, traits, Allocator>::npos, |
| charT zero = charT('0'), charT one = charT('1')) |
| </pre> |
| <p>Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An |
| element of the constructed string has value 0 if the corresponding |
| character in <i>str</i>, beginning at position <i>pos</i>, |
| is <i>zero</i>. Otherwise, the element has the value 1.</p> |
| |
| <p>Change the text of the second sentence in 23.3.5.1, p5 to read: |
| "The function then throws invalid_argument if any of the rlen |
| characters in str beginning at position pos is other than <i>zero</i> |
| or <i>one</i>. The function uses traits::eq() to compare the character |
| values." |
| </p> |
| |
| <p>Change the declaration of the <tt>to_string</tt> member function |
| immediately before 23.3.5.2 [bitset.members] p33 to:</p> |
| <pre> template <class charT, class traits, class Allocator> |
| basic_string<charT, traits, Allocator> |
| to_string(charT zero = charT('0'), charT one = charT('1')) const; |
| </pre> |
| <p>Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit |
| value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the |
| character <tt><i>one</i></tt>.</p> |
| <p>Change 23.3.5.3 [bitset.operators] p8 to:</p> |
| <p><b>Returns</b>:</p> |
| <pre> os << x.template to_string<charT,traits,allocator<charT> >( |
| use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('0'), |
| use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('1')); |
| </pre> |
| |
| |
| <p><b>Rationale:</b></p> |
| <p>There is a real problem here: we need the character values of '0' |
| and '1', and we have no way to get them since strings don't have |
| imbued locales. In principle the "right" solution would be to |
| provide an extra object, either a ctype facet or a full locale, |
| which would be used to widen '0' and '1'. However, there was some |
| discomfort about using such a heavyweight mechanism. The proposed |
| resolution allows those users who care about this issue to get it |
| right.</p> |
| <p>We fix the inserter to use the new arguments. Note that we already |
| fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p> |
| |
| |
| |
| <p><i>[ |
| post Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| We are happy with the resolution as proposed, and we move this to Ready. |
| </blockquote> |
| |
| <p><i>[ |
| Howard adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| The proposed wording neglects the 3 newer to_string overloads. |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3> |
| <p><b>Section:</b> 27.6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| 17.4.4.8, p3 prohibits library dtors from throwing exceptions. |
| </p> |
| <p> |
| 27.6.2.3, p4 says this about the ostream::sentry dtor: |
| </p> |
| <pre> -4- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception()) |
| is true, calls os.flush(). |
| </pre> |
| <p> |
| 27.6.2.6, p7 that describes ostream::flush() says: |
| </p> |
| <pre> -7- If rdbuf() is not a null pointer, calls rdbuf()->pubsync(). |
| If that function returns ?-1 calls setstate(badbit) (which |
| may throw ios_base::failure (27.4.4.3)). |
| </pre> |
| <p> |
| That seems like a defect, since both pubsync() and setstate() can |
| throw an exception. |
| </p> |
| <p><i>[ |
| The contradiction is real. Clause 17 says destructors may never |
| throw exceptions, and clause 27 specifies a destructor that does |
| throw. In principle we might change either one. We're leaning |
| toward changing clause 17: putting in an "unless otherwise specified" |
| clause, and then putting in a footnote saying the sentry destructor |
| is the only one that can throw. PJP suggests specifying that |
| sentry::~sentry() should internally catch any exceptions it might cause. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3> |
| <p><b>Section:</b> 27.6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| While reviewing unformatted input member functions of istream |
| for their behavior when they encounter end-of-file during input |
| I found that the requirements vary, sometimes unexpectedly, and |
| in more than one case even contradict established practice (GNU |
| libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC |
| 5.38, Rogue Wave libstd 3.1, and Classic Iostreams). |
| </p> |
| <p> |
| The following unformatted input member functions set eofbit if they |
| encounter an end-of-file (this is the expected behavior, and also |
| the behavior of all major implementations): |
| </p> |
| <pre> basic_istream<charT, traits>& |
| get (char_type*, streamsize, char_type); |
| </pre> |
| <p> |
| Also sets failbit if it fails to extract any characters. |
| </p> |
| <pre> basic_istream<charT, traits>& |
| get (char_type*, streamsize); |
| </pre> |
| <p> |
| Also sets failbit if it fails to extract any characters. |
| </p> |
| <pre> basic_istream<charT, traits>& |
| getline (char_type*, streamsize, char_type); |
| </pre> |
| <p> |
| Also sets failbit if it fails to extract any characters. |
| </p> |
| <pre> basic_istream<charT, traits>& |
| getline (char_type*, streamsize); |
| </pre> |
| <p> |
| Also sets failbit if it fails to extract any characters. |
| </p> |
| <pre> basic_istream<charT, traits>& |
| ignore (int, int_type); |
| </pre> |
| <pre> basic_istream<charT, traits>& |
| read (char_type*, streamsize); |
| </pre> |
| <p> |
| Also sets failbit if it encounters end-of-file. |
| </p> |
| <pre> streamsize readsome (char_type*, streamsize); |
| </pre> |
| |
| <p> |
| The following unformated input member functions set failbit but |
| not eofbit if they encounter an end-of-file (I find this odd |
| since the functions make it impossible to distinguish a general |
| failure from a failure due to end-of-file; the requirement is |
| also in conflict with all major implementation which set both |
| eofbit and failbit): |
| </p> |
| <pre> int_type get(); |
| </pre> |
| <pre> basic_istream<charT, traits>& |
| get (char_type&); |
| </pre> |
| <p> |
| These functions only set failbit of they extract no characters, |
| otherwise they don't set any bits, even on failure (I find this |
| inconsistency quite unexpected; the requirement is also in |
| conflict with all major implementations which set eofbit |
| whenever they encounter end-of-file): |
| </p> |
| <pre> basic_istream<charT, traits>& |
| get (basic_streambuf<charT, traits>&, char_type); |
| </pre> |
| <pre> basic_istream<charT, traits>& |
| get (basic_streambuf<charT, traits>&); |
| </pre> |
| <p> |
| This function sets no bits (all implementations except for |
| STLport and Classic Iostreams set eofbit when they encounter |
| end-of-file): |
| </p> |
| <pre> int_type peek (); |
| </pre> |
| <p>Informally, what we want is a global statement of intent saying |
| that eofbit gets set if we trip across EOF, and then we can take |
| away the specific wording for individual functions. A full review |
| is necessary. The wording currently in the standard is a mishmash, |
| and changing it on an individual basis wouldn't make things better. |
| Dietmar will do this work.</p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="408"></a>408. Is vector<reverse_iterator<char*> > forbidden?</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| I've been discussing iterator semantics with Dave Abrahams, and a |
| surprise has popped up. I don't think this has been discussed before. |
| </p> |
| |
| <p> |
| 24.1 [iterator.requirements] says that the only operation that can be performed on "singular" |
| iterator values is to assign a non-singular value to them. (It |
| doesn't say they can be destroyed, and that's probably a defect.) |
| Some implementations have taken this to imply that there is no need |
| to initialize the data member of a reverse_iterator<> in the default |
| constructor. As a result, code like |
| </p> |
| <blockquote><pre> std::vector<std::reverse_iterator<char*> > v(7); |
| v.reserve(1000); |
| </pre></blockquote> |
| <p> |
| invokes undefined behavior, because it must default-initialize the |
| vector elements, and then copy them to other storage. Of course many |
| other vector operations on these adapters are also left undefined, |
| and which those are is not reliably deducible from the standard. |
| </p> |
| |
| <p> |
| I don't think that 24.1 was meant to make standard-library iterator |
| types unsafe. Rather, it was meant to restrict what operations may |
| be performed by functions which take general user- and standard |
| iterators as arguments, so that raw pointers would qualify as |
| iterators. However, this is not clear in the text, others have come |
| to the opposite conclusion. |
| </p> |
| |
| <p> |
| One question is whether the standard iterator adaptors have defined |
| copy semantics. Another is whether they have defined destructor |
| semantics: is |
| </p> |
| <blockquote><pre> { std::vector<std::reverse_iterator<char*> > v(7); } |
| </pre></blockquote> |
| <p> |
| undefined too? |
| </p> |
| |
| <p> |
| Note this is not a question of whether algorithms are allowed to |
| rely on copy semantics for arbitrary iterators, just whether the |
| types we actually supply support those operations. I believe the |
| resolution must be expressed in terms of the semantics of the |
| adapter's argument type. It should make clear that, e.g., the |
| reverse_iterator<T> constructor is actually required to execute |
| T(), and so copying is defined if the result of T() is copyable. |
| </p> |
| |
| <p> |
| Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default |
| constructor more precisely, has some relevance to this issue. |
| However, it is not the whole story. |
| </p> |
| |
| <p> |
| The issue was whether |
| </p> |
| <blockquote><pre> reverse_iterator() { } |
| </pre></blockquote> |
| <p> |
| is allowed, vs. |
| </p> |
| <blockquote><pre> reverse_iterator() : current() { } |
| </pre></blockquote> |
| |
| <p> |
| The difference is when T is char*, where the first leaves the member |
| uninitialized, and possibly equal to an existing pointer value, or |
| (on some targets) may result in a hardware trap when copied. |
| </p> |
| |
| <p> |
| 8.5 paragraph 5 seems to make clear that the second is required to |
| satisfy DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, at least for non-class Iterator argument |
| types. |
| </p> |
| |
| <p> |
| But that only takes care of reverse_iterator, and doesn't establish |
| a policy for all iterators. (The reverse iterator adapter was just |
| an example.) In particular, does my function |
| </p> |
| <blockquote><pre> template <typename Iterator> |
| void f() { std::vector<Iterator> v(7); } |
| </pre></blockquote> |
| <p> |
| evoke undefined behavior for some conforming iterator definitions? |
| I think it does, now, because vector<> will destroy those singular |
| iterator values, and that's explicitly disallowed. |
| </p> |
| |
| <p> |
| 24.1 shouldn't give blanket permission to copy all singular iterators, |
| because then pointers wouldn't qualify as iterators. However, it |
| should allow copying of that subset of singular iterator values that |
| are default-initialized, and it should explicitly allow destroying any |
| iterator value, singular or not, default-initialized or not. |
| </p> |
| |
| <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p> |
| <p><i>[ |
| We don't want to require all singular iterators to be copyable, |
| because that is not the case for pointers. However, default |
| construction may be a special case. Issue: is it really default |
| construction we want to talk about, or is it something like value |
| initialization? We need to check with core to see whether default |
| constructed pointers are required to be copyable; if not, it would be |
| wrong to impose so strict a requirement for iterators. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3> |
| <p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The Effects and Returns clauses of the do_widen() member function of |
| the ctype facet fail to specify the behavior of the function on failure. |
| That the function may not be able to simply cast the narrow character |
| argument to the type of the result since doing so may yield the wrong value |
| for some wchar_t encodings. Popular implementations of ctype<wchar_t> that |
| use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail |
| when the argument's MSB is set. There is no way for the the rest of locale |
| and iostream to reliably detect this failure. |
| </p> |
| <p><i>[Kona: This is a real problem. Widening can fail. It's unclear |
| what the solution should be. Returning WEOF works for the wchar_t |
| specialization, but not in general. One option might be to add a |
| default, like <i>narrow</i>. But that's an incompatible change. |
| Using <i>traits::eof</i> might seem like a good idea, but facets |
| don't have access to traits (a recurring problem). We could |
| have <i>widen</i> throw an exception, but that's a scary option; |
| existing library components aren't written with the assumption |
| that <i>widen</i> can throw.]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3> |
| <p><b>Section:</b> 27.4.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The dtor of the ios_base::Init object is supposed to call flush() on the |
| 6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog. |
| This call may cause an exception to be thrown. |
| </p> |
| |
| <p> |
| 17.4.4.8, p3 prohibits all library destructors from throwing exceptions. |
| </p> |
| |
| <p> |
| The question is: What should this dtor do if one or more of these calls |
| to flush() ends up throwing an exception? This can happen quite easily |
| if one of the facets installed in the locale imbued in the iostream |
| object throws. |
| </p> |
| <p><i>[Kona: We probably can't do much better than what we've got, so |
| the LWG is leaning toward NAD. At the point where the standard |
| stream objects are being cleaned up, the usual error reporting |
| mechanism are all unavailable. And exception from flush at this |
| point will definitely cause problems. A quality implementation |
| might reasonably swallow the exception, or call abort, or do |
| something even more drastic.]</i></p> |
| |
| |
| <p><i>[ |
| See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| 27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good() |
| is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to |
| true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then |
| says that a formatted input function endeavors to obtain the requested input |
| if the sentry's operator bool() returns true. |
| |
| Given these requirements, no formatted extractor should ever set failbit if |
| the initial stream rdstate() == eofbit. That is contrary to the behavior of |
| all implementations I tested. The program below prints out |
| |
| eof = 1, fail = 0 |
| eof = 1, fail = 1 |
| |
| on all of them. |
| </p> |
| <pre> |
| #include <sstream> |
| #include <cstdio> |
| |
| int main() |
| { |
| std::istringstream strm ("1"); |
| |
| int i = 0; |
| |
| strm >> i; |
| |
| std::printf ("eof = %d, fail = %d\n", |
| !!strm.eof (), !!strm.fail ()); |
| |
| strm >> i; |
| |
| std::printf ("eof = %d, fail = %d\n", |
| !!strm.eof (), !!strm.fail ()); |
| } |
| |
| </pre> |
| <p> |
| <br> |
| |
| Comments from Jerry Schwarz (c++std-lib-11373): |
| <br> |
| |
| Jerry Schwarz wrote: |
| <br> |
| |
| I don't know where (if anywhere) it says it in the standard, but the |
| formatted extractors are supposed to set failbit if they don't extract |
| any characters. If they didn't then simple loops like |
| <br> |
| |
| while (cin >> x); |
| <br> |
| |
| would loop forever. |
| <br> |
| |
| Further comments from Martin Sebor: |
| <br> |
| |
| The question is which part of the extraction should prevent this from happening |
| by setting failbit when eofbit is already set. It could either be the sentry |
| object or the extractor. It seems that most implementations have chosen to |
| set failbit in the sentry [...] so that's the text that will need to be |
| corrected. |
| |
| </p> |
| <p> |
| Pre Berlin: This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>. If the sentry |
| sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then |
| you can never seek away from the end of stream. |
| </p> |
| <p>Kona: Possibly NAD. If eofbit is set then good() will return false. We |
| then set <i>ok</i> to false. We believe that the sentry's |
| constructor should always set failbit when <i>ok</i> is false, and |
| we also think the standard already says that. Possibly it could be |
| clearer.</p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 27.6.1.1.3 [istream::sentry], p2 to: |
| </p> |
| |
| <blockquote> |
| <pre>explicit sentry(basic_istream<charT,traits>& <i>is</i> , bool <i>noskipws</i> = false);</pre> |
| <p> |
| -2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del> |
| <ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>. |
| Otherwise</ins> prepares for formatted or unformatted input. ... |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3> |
| <p><b>Section:</b> 27.5.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The reflector thread starting with c++std-lib-11346 notes that the class |
| template basic_streambuf, along with basic_stringbuf and basic_filebuf, |
| is copy-constructible but that the semantics of the copy constructors |
| are not defined anywhere. Further, different implementations behave |
| differently in this respect: some prevent copy construction of objects |
| of these types by declaring their copy ctors and assignment operators |
| private, others exhibit undefined behavior, while others still give |
| these operations well-defined semantics. |
| </p> |
| |
| <p> |
| Note that this problem doesn't seem to be isolated to just the three |
| types mentioned above. A number of other types in the library section |
| of the standard provide a compiler-generated copy ctor and assignment |
| operator yet fail to specify their semantics. It's believed that the |
| only types for which this is actually a problem (i.e. types where the |
| compiler-generated default may be inappropriate and may not have been |
| intended) are locale facets. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| 27.5.2 [lib.streambuf]: Add into the synopsis, public section, just above the destructor declaration: |
| </p> |
| |
| <blockquote> |
| <pre>basic_streambuf(const basic_streambuf& sb); |
| basic_streambuf& operator=(const basic_streambuf& sb); |
| </pre> |
| </blockquote> |
| |
| <p>Insert after 27.5.2.1, paragraph 2:</p> |
| <blockquote> |
| <pre>basic_streambuf(const basic_streambuf& sb); |
| </pre> |
| |
| <p>Constructs a copy of sb.</p> |
| <p>Postcondtions:</p> |
| <pre> eback() == sb.eback() |
| gptr() == sb.gptr() |
| egptr() == sb.egptr() |
| pbase() == sb.pbase() |
| pptr() == sb.pptr() |
| epptr() == sb.epptr() |
| getloc() == sb.getloc() |
| </pre> |
| |
| <pre>basic_streambuf& operator=(const basic_streambuf& sb); |
| </pre> |
| |
| <p>Assigns the data members of sb to this.</p> |
| |
| <p>Postcondtions:</p> |
| <pre> eback() == sb.eback() |
| gptr() == sb.gptr() |
| egptr() == sb.egptr() |
| pbase() == sb.pbase() |
| pptr() == sb.pptr() |
| epptr() == sb.epptr() |
| getloc() == sb.getloc() |
| </pre> |
| |
| <p>Returns: *this.</p> |
| </blockquote> |
| |
| <p>27.7.1 [lib.stringbuf]:</p> |
| |
| <p><b>Option A:</b></p> |
| |
| <blockquote> |
| <p>Insert into the basic_stringbuf synopsis in the private section:</p> |
| |
| <pre>basic_stringbuf(const basic_stringbuf&); // not defined |
| basic_stringbuf& operator=(const basic_stringbuf&); // not defined |
| </pre> |
| </blockquote> |
| |
| <p><b>Option B:</b></p> |
| |
| <blockquote> |
| <p>Insert into the basic_stringbuf synopsis in the public section:</p> |
| |
| <pre>basic_stringbuf(const basic_stringbuf& sb); |
| basic_stringbuf& operator=(const basic_stringbuf& sb); |
| </pre> |
| |
| <p>27.7.1.1, insert after paragraph 4:</p> |
| |
| <pre>basic_stringbuf(const basic_stringbuf& sb);</pre> |
| |
| <p> |
| Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with. |
| </p> |
| |
| <p>Postcondtions: </p> |
| <pre> str() == sb.str() |
| gptr() - eback() == sb.gptr() - sb.eback() |
| egptr() - eback() == sb.egptr() - sb.eback() |
| pptr() - pbase() == sb.pptr() - sb.pbase() |
| getloc() == sb.getloc() |
| </pre> |
| |
| <p> |
| Note: The only requirement on epptr() is that it point beyond the |
| initialized range if an output sequence exists. There is no requirement |
| that epptr() - pbase() == sb.epptr() - sb.pbase(). |
| </p> |
| |
| <pre>basic_stringbuf& operator=(const basic_stringbuf& sb);</pre> |
| <p>After assignment the basic_stringbuf has the same state as if it |
| were initially copy constructed from sb, except that the |
| basic_stringbuf is allowed to retain any excess capacity it might have, |
| which may in turn effect the value of epptr(). |
| </p> |
| </blockquote> |
| |
| <p>27.8.1.1 [lib.filebuf]</p> |
| |
| <p>Insert at the bottom of the basic_filebuf synopsis:</p> |
| |
| <blockquote> |
| <pre>private: |
| basic_filebuf(const basic_filebuf&); // not defined |
| basic_filebuf& operator=(const basic_filebuf&); // not defined |
| </pre> |
| </blockquote> |
| <p><i>[Kona: this is an issue for basic_streambuf itself and for its |
| derived classes. We are leaning toward allowing basic_streambuf to |
| be copyable, and specifying its precise semantics. (Probably the |
| obvious: copying the buffer pointers.) We are less sure whether |
| the streambuf derived classes should be copyable. Howard will |
| write up a proposal.]</i></p> |
| |
| |
| <p><i>[Sydney: Dietmar presented a new argument against basic_streambuf |
| being copyable: it can lead to an encapsulation violation. Filebuf |
| inherits from streambuf. Now suppose you inhert a my_hijacking_buf |
| from streambuf. You can copy the streambuf portion of a filebuf to a |
| my_hijacking_buf, giving you access to the pointers into the |
| filebuf's internal buffer. Perhaps not a very strong argument, but |
| it was strong enough to make people nervous. There was weak |
| preference for having streambuf not be copyable. There was weak |
| preference for having stringbuf not be copyable even if streambuf |
| is. Move this issue to open for now. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| 2007-01-12, Howard: |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1862.html#27.5.2%20-%20Class%20template%20basic_streambuf%3CcharT,traits%3E">Rvalue Reference Recommendations for Chapter 27</a> |
| recommends protected copy constructor and assignment for <tt>basic_streambuf</tt> with the same semantics |
| as would be generated by the compiler. These members aid in derived classes implementing move semantics. |
| A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is |
| today as each data member of a <tt>basic_streambuf</tt> is already both readable and writable by derived |
| classes via various get/set protected member functions (<tt>eback()</tt>, <tt>setp()</tt>, etc.). Rather |
| a protected copy constructor and copy assignment operator simply make the job of derived classes implementing |
| move semantics less tedious and error prone. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Rationale:</b></p> |
| <p> |
| 27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor |
| and assignment operator are the same as currently implied by the lack |
| of declarations: public and simply copies the data members. This |
| resolution is not a change but a clarification of the current |
| standard. |
| </p> |
| |
| <p> |
| 27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make |
| basic_stringbuf not copyable. This is likely the status-quo of |
| current implementations. B) Reasonable copy semantics of |
| basic_stringbuf can be defined and implemented. A copyable |
| basic_streambuf is arguably more useful than a non-copyable one. This |
| should be considered as new functionality and not the fixing of a |
| defect. If option B is chosen, ramifications from issue 432 are taken |
| into account. |
| </p> |
| |
| <p> |
| 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for |
| basic_filebuf. |
| </p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3> |
| <p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| |
| <p> |
| A third party test suite tries to exercise istream::ignore(N) with |
| a negative value of N and expects that the implementation will treat |
| N as if it were 0. Our implementation asserts that (N >= 0) holds and |
| aborts the test. |
| </p> |
| |
| <p> |
| I can't find anything in section 27 that prohibits such values but I don't |
| see what the effects of such calls should be, either (this applies to |
| a number of unformatted input functions as well as some member functions |
| of the basic_streambuf template). |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| I propose that we add to each function in clause 27 that takes an argument, |
| say N, of type streamsize a Requires clause saying that "N >= 0." The intent |
| is to allow negative streamsize values in calls to precision() and width() |
| but disallow it in calls to streambuf::sgetn(), istream::ignore(), or |
| ostream::write(). |
| </p> |
| |
| <p><i>[Kona: The LWG agreed that this is probably what we want. However, we |
| need a review to find all places where functions in clause 27 take |
| arguments of type streamsize that shouldn't be allowed to go |
| negative. Martin will do that review.]</i></p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3> |
| <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The requirements specified in Stage 2 and reiterated in the rationale |
| of DR 221 (and echoed again in DR 303) specify that num_get<charT>:: |
| do_get() compares characters on the stream against the widened elements |
| of "012...abc...ABCX+-" |
| </p> |
| |
| <p> |
| An implementation is required to allow programs to instantiate the num_get |
| template on any charT that satisfies the requirements on a user-defined |
| character type. These requirements do not include the ability of the |
| character type to be equality comparable (the char_traits template must |
| be used to perform tests for equality). Hence, the num_get template cannot |
| be implemented to support any arbitrary character type. The num_get template |
| must either make the assumption that the character type is equality-comparable |
| (as some popular implementations do), or it may use char_traits<charT> to do |
| the comparisons (some other popular implementations do that). This diversity |
| of approaches makes it difficult to write portable programs that attempt to |
| instantiate the num_get template on user-defined types. |
| </p> |
| |
| <p><i>[Kona: the heart of the problem is that we're theoretically |
| supposed to use traits classes for all fundamental character |
| operations like assignment and comparison, but facets don't have |
| traits parameters. This is a fundamental design flaw and it |
| appears all over the place, not just in this one place. It's not |
| clear what the correct solution is, but a thorough review of facets |
| and traits is in order. The LWG considered and rejected the |
| possibility of changing numeric facets to use narrowing instead of |
| widening. This may be a good idea for other reasons (see issue |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#459">459</a>), but it doesn't solve the problem raised by this |
| issue. Whether we use widen or narrow the <tt>num_get</tt> facet |
| still has no idea which traits class the user wants to use for |
| the comparison, because only streams, not facets, are passed traits |
| classes. The standard does not require that two different |
| traits classes with the same <tt>char_type</tt> must necessarily |
| have the same behavior.]</i></p> |
| |
| |
| <p>Informally, one possibility: require that some of the basic |
| character operations, such as <tt>eq</tt>, <tt>lt</tt>, |
| and <tt>assign</tt>, must behave the same way for all traits classes |
| with the same <tt>char_type</tt>. If we accept that limitation on |
| traits classes, then the facet could reasonably be required to |
| use <tt>char_traits<charT></tt>.</p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="430"></a>430. valarray subset operations</h3> |
| <p><b>Section:</b> 26.5.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The standard fails to specify the behavior of valarray::operator[](slice) |
| and other valarray subset operations when they are passed an "invalid" |
| slice object, i.e., either a slice that doesn't make sense at all (e.g., |
| slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray |
| object (e.g., slice (2, 1, 1) for a valarray of size 1). |
| </p> |
| <p><i>[Kona: the LWG believes that invalid slices should invoke |
| undefined behavior. Valarrays are supposed to be designed for high |
| performance, so we don't want to require specific checking. We |
| need wording to express this decision.]</i></p> |
| |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Please note that the standard also fails to specify the behavior of |
| slice_array and gslice_array in the valid case. Bill Plauger will |
| endeavor to provide revised wording for slice_array and gslice_array. |
| </blockquote> |
| |
| <p><i>[ |
| post-Bellevue: Bill provided wording. |
| ]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Insert after 26.5.2.4 [valarray.sub], paragraph 1: |
| </p> |
| |
| <blockquote> |
| <p> |
| The member operator is overloaded to provide several ways to select |
| sequences |
| of elements from among those controlled by <tt>*this</tt>. The first group of five |
| member operators work in conjunction with various overloads of <tt>operator=</tt> |
| (and other assigning operators) to allow selective replacement (slicing) of |
| the controlled sequence. The selected elements must exist. |
| </p> |
| <p> |
| The first member operator selects element off. For example: |
| </p> |
| |
| <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); |
| v0[3] = 'A'; |
| // v0 == valarray<char>("abcAefghijklmnop", 16) |
| </pre></blockquote> |
| |
| <p> |
| The second member operator selects those elements of the controlled sequence |
| designated by <tt>slicearr</tt>. For example: |
| </p> |
| |
| <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); |
| valarray<char> v1("ABCDE", 5); |
| v0[slice(2, 5, 3)] = v1; |
| // v0 == valarray<char>("abAdeBghCjkDmnEp", 16) |
| </pre></blockquote> |
| |
| <p> |
| The third member operator selects those elements of the controlled sequence |
| designated by <tt>gslicearr</tt>. For example: |
| </p> |
| |
| <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); |
| valarray<char> v1("ABCDEF", 6); |
| const size_t lv[] = {2, 3}; |
| const size_t dv[] = {7, 2}; |
| const valarray<size_t> len(lv, 2), str(dv, 2); |
| v0[gslice(3, len, str)] = v1; |
| // v0 == valarray<char>("abcAeBgCijDlEnFp", 16) |
| </pre></blockquote> |
| |
| <p> |
| The fourth member operator selects those elements of the controlled sequence |
| designated by <tt>boolarr</tt>. For example: |
| </p> |
| |
| <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); |
| valarray<char> v1("ABC", 3); |
| const bool vb[] = {false, false, true, true, false, true}; |
| v0[valarray<bool>(vb, 6)] = v1; |
| // v0 == valarray<char>("abABeCghijklmnop", 16) |
| </pre></blockquote> |
| |
| <p> |
| The fifth member operator selects those elements of the controlled sequence |
| designated by indarr. For example: |
| </p> |
| |
| <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); |
| valarray<char> v1("ABCDE", 5); |
| const size_t vi[] = {7, 5, 2, 3, 8}; |
| v0[valarray<size_t>(vi, 5)] = v1; |
| // v0 == valarray<char>("abCDeBgAEjklmnop", 16) |
| </pre></blockquote> |
| |
| <p> |
| The second group of five member operators each construct an object that |
| represents the value(s) selected. The selected elements must exist. |
| </p> |
| |
| <p> |
| The sixth member operator returns the value of element off. For example: |
| </p> |
| |
| <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); |
| // v0[3] returns 'd' |
| </pre></blockquote> |
| |
| <p> |
| The seventh member operator returns an object of class <tt>valarray<Ty></tt> |
| containing those elements of the controlled sequence designated by <tt>slicearr</tt>. |
| For example: |
| </p> |
| |
| <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); |
| // v0[slice(2, 5, 3)] returns valarray<char>("cfilo", 5) |
| </pre></blockquote> |
| |
| <p> |
| The eighth member operator selects those elements of the controlled sequence |
| designated by <tt>gslicearr</tt>. For example: |
| </p> |
| |
| <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); |
| const size_t lv[] = {2, 3}; |
| const size_t dv[] = {7, 2}; |
| const valarray<size_t> len(lv, 2), str(dv, 2); |
| // v0[gslice(3, len, str)] returns |
| // valarray<char>("dfhkmo", 6) |
| </pre></blockquote> |
| |
| <p> |
| The ninth member operator selects those elements of the controlled sequence |
| designated by <tt>boolarr</tt>. For example: |
| </p> |
| |
| <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); |
| const bool vb[] = {false, false, true, true, false, true}; |
| // v0[valarray<bool>(vb, 6)] returns |
| // valarray<char>("cdf", 3) |
| </pre></blockquote> |
| |
| <p> |
| The last member operator selects those elements of the controlled sequence |
| designated by <tt>indarr</tt>. For example: |
| </p> |
| |
| <blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); |
| const size_t vi[] = {7, 5, 2, 3, 8}; |
| // v0[valarray<size_t>(vi, 5)] returns |
| // valarray<char>("hfcdi", 5) |
| </pre></blockquote> |
| |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="431"></a>431. Swapping containers with unequal allocators</h3> |
| <p><b>Section:</b> 20.1.2 [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-09-20</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations |
| are permitted to supply containers that are unable to cope with |
| allocator instances and that container implementations may assume |
| that all instances of an allocator type compare equal. We gave |
| implementers this latitude as a temporary hack, and eventually we |
| want to get rid of it. What happens when we're dealing with |
| allocators that <i>don't</i> compare equal? |
| </p> |
| |
| <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both |
| objects of type <tt>vector<int, my_alloc></tt> and that |
| <tt>v1.get_allocator() != v2.get_allocator()</tt>. What happens if |
| we write <tt>v1.swap(v2)</tt>? Informally, three possibilities:</p> |
| |
| <p>1. This operation is illegal. Perhaps we could say that an |
| implementation is required to check and to throw an exception, or |
| perhaps we could say it's undefined behavior.</p> |
| <p>2. The operation performs a slow swap (i.e. using three |
| invocations of <tt>operator=</tt>, leaving each allocator with its |
| original container. This would be an O(N) operation.</p> |
| <p>3. The operation swaps both the vectors' contents and their |
| allocators. This would be an O(1) operation. That is:</p> |
| <blockquote> |
| <pre> my_alloc a1(...); |
| my_alloc a2(...); |
| assert(a1 != a2); |
| |
| vector<int, my_alloc> v1(a1); |
| vector<int, my_alloc> v2(a2); |
| assert(a1 == v1.get_allocator()); |
| assert(a2 == v2.get_allocator()); |
| |
| v1.swap(v2); |
| assert(a1 == v2.get_allocator()); |
| assert(a2 == v1.get_allocator()); |
| </pre> |
| </blockquote> |
| |
| <p><i>[Kona: This is part of a general problem. We need a paper |
| saying how to deal with unequal allocators in general.]</i></p> |
| |
| |
| <p><i>[pre-Sydney: Howard argues for option 3 in |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| 2007-01-12, Howard: This issue will now tend to come up more often with move constructors |
| and move assignment operators. For containers, these members transfer resources (i.e. |
| the allocated memory) just like swap. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Batavia: There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable |
| requirement using concepts. If the allocator supports Swappable, then container's swap will |
| swap allocators, else it will perform a "slow swap" using copy construction and copy assignment. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="446"></a>446. Iterator equality between different containers</h3> |
| <p><b>Section:</b> 24.1 [iterator.requirements], 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Andy Koenig <b>Date:</b> 2003-12-16</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| What requirements does the standard place on equality comparisons between |
| iterators that refer to elements of different containers. For example, if |
| v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true? |
| Is it allowed to throw an exception? |
| </p> |
| |
| <p> |
| The standard appears to be silent on both questions. |
| </p> |
| <p><i>[Sydney: The intention is that comparing two iterators from |
| different containers is undefined, but it's not clear if we say that, |
| or even whether it's something we should be saying in clause 23 or in |
| clause 24. Intuitively we might want to say that equality is defined |
| only if one iterator is reachable from another, but figuring out how |
| to say it in any sensible way is a bit tricky: reachability is defined |
| in terms of equality, so we can't also define equality in terms of |
| reachability. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3> |
| <p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p> |
| <p><b>Discussion:</b></p> |
| <pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode); |
| </pre> |
| |
| <p>should be supplemented with the overload:</p> |
| |
| <pre> basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode); |
| </pre> |
| |
| <p> |
| Depending on the operating system, one of these forms is fundamental and |
| the other requires an implementation-defined mapping to determine the |
| actual filename. |
| </p> |
| |
| <p><i>[Sydney: Yes, we want to allow wchar_t filenames. Bill will |
| provide wording.]</i></p> |
| |
| |
| <p><i>[ |
| In Toronto we noted that this is issue 5 from |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>. |
| ]</i></p> |
| |
| <p> |
| How does this interact with the newly-defined character types, and how |
| do we avoid interface explosion considering <tt>std::string</tt> overloads that |
| were added? Propose another solution that is different than the |
| suggestion proposed by PJP. |
| </p> |
| <p> |
| Suggestion is to make a member template function for <tt>basic_string</tt> (for |
| <tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a |
| <tt>const char*</tt> member. |
| </p> |
| <p> |
| Goal is to do implicit conversion between character string literals to |
| appropriate <tt>basic_string</tt> type. Not quite sure if this is possible. |
| </p> |
| <p> |
| Implementors are free to add specific overloads for non-char character |
| types. |
| </p> |
| |
| <p><i>[ |
| Martin adds pre-Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>. |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not |
| usefully changed unless <tt>fstream</tt> is also changed; this also only handles |
| <tt>wchar_t</tt> and not other character types. |
| </p> |
| <p> |
| The TR2 filesystem library is a more complete solution, but is not available soon. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| Martin adds: please reference |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for |
| problems and solutions. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p>Change from:</p> |
| <blockquote> |
| <pre>basic_filebuf<charT,traits>* open( |
| const char* s, |
| ios_base::openmode mode ); |
| </pre> |
| |
| <p> |
| Effects: If is_open() != false, returns a null pointer. |
| Otherwise, initializes the filebuf as required. It then |
| opens a file, if possible, whose name is the NTBS s ("as if" |
| by calling std::fopen(s,modstr)).</p> |
| </blockquote> |
| |
| <p>to:</p> |
| |
| <blockquote> |
| <pre>basic_filebuf<charT,traits>* open( |
| const char* s, |
| ios_base::openmode mode ); |
| |
| basic_filebuf<charT,traits>* open( |
| const wchar_t* ws, |
| ios_base::openmode mode ); |
| </pre> |
| |
| <p> |
| Effects: If is_open() != false, returns a null pointer. |
| Otherwise, initializes the filebuf as required. It then |
| opens a file, if possible, whose name is the NTBS s ("as if" |
| by calling std::fopen(s,modstr)). |
| For the second signature, the NTBS s is determined from the |
| WCBS ws in an implementation-defined manner. |
| </p> |
| |
| <p> |
| (NOTE: For a system that "naturally" represents a filename |
| as a WCBS, the NTBS s in the first signature may instead |
| be mapped to a WCBS; if so, it follows the same mapping |
| rules as the first argument to open.) |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Rationale:</b></p> |
| <p> |
| Slightly controversial, but by a 7-1 straw poll the LWG agreed to move |
| this to Ready. The controversy was because the mapping between wide |
| names and files in a filesystem is implementation defined. The |
| counterargument, which most but not all LWG members accepted, is that |
| the mapping between narrow files names and files is also |
| implemenation defined.</p> |
| |
| <p><i>[Lillehammer: Moved back to "open" status, at Beman's urging. |
| (1) Why just basic_filebuf, instead of also basic_fstream (and |
| possibly other things too). (2) Why not also constructors that take |
| std::basic_string? (3) We might want to wait until we see Beman's |
| filesystem library; we might decide that it obviates this.]</i></p> |
| |
| |
| <p><i>[ |
| post Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Move again to Ready. |
| </p> |
| <p> |
| There is a timing issue here. Since the filesystem library will not be |
| in C++0x, this should be brought forward. This solution would remain |
| valid in the context of the proposed filesystem. |
| </p> |
| <p> |
| This issue has been kicking around for a while, and the wchar_t addition |
| alone would help many users. Thus, we suggest putting this on the |
| reflector list with an invitation for someone to produce proposed |
| wording that covers basic_fstream. In the meantime, we suggest that the |
| proposed wording be adopted as-is. |
| </p> |
| <p> |
| If more of the Lillehammer questions come back, they should be |
| introduced as separate issues. |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3> |
| <p><b>Section:</b> 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-02-27</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In 24.1.5 [lib.random.access.iterators], table 76 the operational |
| semantics for the expression "r -= n" are defined as "return r += -n". |
| This means, that the expression -n must be valid, which is not the case |
| for unsigned types. |
| </p> |
| |
| <p><i>[ |
| Sydney: Possibly not a real problem, since difference type is required |
| to be a signed integer type. However, the wording in the standard may |
| be less clear than we would like. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| To remove this limitation, I suggest to change the |
| operational semantics for this column to: |
| </p> |
| <blockquote><pre> { Distance m = n; |
| if (m >= 0) |
| while (m--) --r; |
| else |
| while (m++) ++r; |
| return r; } |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</h3> |
| <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-03-16</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>When parsing strings of wide-character digits, the standard |
| requires the library to widen narrow-character "atoms" and compare |
| the widened atoms against the characters that are being parsed. |
| Simply narrowing the wide characters would be far simpler, and |
| probably more efficient. The two choices are equivalent except in |
| convoluted test cases, and many implementations already ignore the |
| standard and use narrow instead of widen.</p> |
| |
| <p> |
| First, I disagree that using narrow() instead of widen() would |
| necessarily have unfortunate performance implications. A possible |
| implementation of narrow() that allows num_get to be implemented |
| in a much simpler and arguably comparably efficient way as calling |
| widen() allows, i.e. without making a virtual call to do_narrow every |
| time, is as follows: |
| </p> |
| |
| <pre> inline char ctype<wchar_t>::narrow (wchar_t wc, char dflt) const |
| { |
| const unsigned wi = unsigned (wc); |
| |
| if (wi > UCHAR_MAX) |
| return typeid (*this) == typeid (ctype<wchar_t>) ? |
| dflt : do_narrow (wc, dflt); |
| |
| if (narrow_ [wi] < 0) { |
| const char nc = do_narrow (wc, dflt); |
| if (nc == dflt) |
| return dflt; |
| narrow_ [wi] = nc; |
| } |
| |
| return char (narrow_ [wi]); |
| } |
| </pre> |
| |
| <p> |
| Second, I don't think the change proposed in the issue (i.e., to use |
| narrow() instead of widen() during Stage 2) would be at all |
| drastic. Existing implementations with the exception of libstdc++ |
| currently already use narrow() so the impact of the change on programs |
| would presumably be isolated to just a single implementation. Further, |
| since narrow() is not required to translate alternate wide digit |
| representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> |
| to |
| their narrow equivalents (i.e., the portable source characters '0' |
| through '9'), the change does not necessarily imply that these |
| alternate digits would be treated as ordinary digits and accepted as |
| part of numbers during parsing. In fact, the requirement in 22.2.1.1.2 |
| [locale.ctype.virtuals], p13 forbids narrow() to translate an alternate |
| digit character, wc, to an ordinary digit in the basic source |
| character set unless the expression |
| (ctype<charT>::is(ctype_base::digit, wc) == true) holds. This in |
| turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and |
| 5.2.1, respectively) for charT of either char or wchar_t. |
| </p> |
| |
| <p><i>[Sydney: To a large extent this is a nonproblem. As long as |
| you're only trafficking in char and wchar_t we're only dealing with a |
| stable character set, so you don't really need either 'widen' or |
| 'narrow': can just use literals. Finally, it's not even clear whether |
| widen-vs-narrow is the right question; arguably we should be using |
| codecvt instead.]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p>Change stage 2 so that implementations are permitted to use either |
| technique to perform the comparison:</p> |
| <ol> |
| <li> call widen on the atoms and compare (either by using |
| operator== or char_traits<charT>::eq) the input with |
| the widened atoms, or</li> |
| <li> call narrow on the input and compare the narrow input |
| with the atoms</li> |
| <li> do (1) or (2) only if charT is not char or wchar_t, |
| respectively; i.e., avoid calling widen or narrow |
| if it the source and destination types are the same</li> |
| </ol> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="463"></a>463. auto_ptr usability issues</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| |
| <p> |
| TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>() |
| member of auto_ptr (20.4.5.3/4) obsolete. |
| </p> |
| |
| <p> |
| The sole purpose of this obsolete conversion member is to enable copy |
| initialization base from r-value derived (or any convertible types like |
| cv-types) case: |
| </p> |
| <pre>#include <memory> |
| using std::auto_ptr; |
| |
| struct B {}; |
| struct D : B {}; |
| |
| auto_ptr<D> source(); |
| int sink(auto_ptr<B>); |
| int x1 = sink( source() ); // #1 EDG - no suitable copy constructor |
| </pre> |
| |
| <p> |
| The excellent analysis of conversion operations that was given in the final |
| auto_ptr proposal |
| (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf) |
| explicitly specifies this case analysis (case 4). DR #84 makes the analysis |
| wrong and actually comes to forbid the loophole that was exploited by the |
| auto_ptr designers. |
| </p> |
| |
| <p> |
| I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that |
| ever allowed this case. This is probably because it requires 3 user defined |
| conversions and in fact current compilers conform to DR #84. |
| </p> |
| |
| <p> |
| I was surprised to discover that the obsolete conversion member actually has |
| negative impact of the copy initialization base from l-value derived |
| case:</p> |
| <pre>auto_ptr<D> dp; |
| int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies |
| </pre> |
| |
| <p> |
| I'm sure that the original intention was allowing this initialization using |
| the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but |
| since in this copy initialization it's merely user defined conversion (UDC) |
| and the obsolete conversion member is UDC with the same rank (for the early |
| overloading stage) there is an ambiguity between them. |
| </p> |
| |
| <p> |
| Removing the obsolete member will have impact on code that explicitly |
| invokes it: |
| </p> |
| <pre>int y = sink(source().operator auto_ptr<B>()); |
| </pre> |
| |
| <p> |
| IMHO no one ever wrote such awkward code and the reasonable workaround for |
| #1 is: |
| </p> |
| <pre>int y = sink( auto_ptr<B>(source()) ); |
| </pre> |
| |
| <p> |
| I was even more surprised to find out that after removing the obsolete |
| conversion member the initialization was still ill-formed: |
| int x3 = sink(dp); // #3 EDG - no suitable copy constructor |
| </p> |
| |
| <p> |
| This copy initialization semantically requires copy constructor which means |
| that both template conversion constructor and the auto_ptr_ref conversion |
| member (20.4.5.3/3) are required which is what was explicitly forbidden in |
| DR #84. This is a bit amusing case in which removing ambiguity results with |
| no candidates. |
| </p> |
| |
| <p> |
| I also found exception safety issue with auto_ptr related to auto_ptr_ref: |
| </p> |
| <pre>int f(auto_ptr<B>, std::string); |
| auto_ptr<B> source2(); |
| |
| // string constructor throws while auto_ptr_ref |
| // "holds" the pointer |
| int x4 = f(source2(), "xyz"); // #4 |
| </pre> |
| |
| <p> |
| The theoretic execution sequence that will cause a leak: |
| </p> |
| <ol> |
| <li>call auto_ptr<B>::operator auto_ptr_ref<B>()</li> |
| <li>call string::string(char const*) and throw</li> |
| </ol> |
| |
| <p> |
| According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member |
| returns auto_ptr_ref<Y> that holds *this and this is another defect since |
| the type of *this is auto_ptr<X> where X might be different from Y. Several |
| library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which |
| is much more reasonable. Other vendor implemented auto_ptr_ref as |
| defectively required and it results with awkward and catastrophic code: |
| int oops = sink(auto_ptr<B>(source())); // warning recursive on all control |
| paths |
| </p> |
| |
| <p> |
| Dave Abrahams noticed that there is no specification saying that |
| auto_ptr_ref copy constructor can't throw. |
| </p> |
| |
| <p> |
| My proposal comes to solve all the above issues and significantly simplify |
| auto_ptr implementation. One of the fundamental requirements from auto_ptr |
| is that it can be constructed in an intuitive manner (i.e. like ordinary |
| pointers) but with strict ownership semantics which yield that source |
| auto_ptr in initialization must be non-const. My idea is to add additional |
| constructor template with sole propose to generate ill-formed, diagnostic |
| required, instance for const auto_ptr arguments during instantiation of |
| declaration. This special constructor will not be instantiated for other |
| types which is achievable using 14.8.2/2 (SFINAE). Having this constructor |
| in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&) |
| legitimate since the actual argument can't be const yet non const r-value |
| are acceptable. |
| </p> |
| |
| <p> |
| This implementation technique makes the "private auxiliary class" |
| auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG, |
| GCC and VC) consume the new implementation as expected and allow all |
| intuitive initialization and assignment cases while rejecting illegal cases |
| that involve const auto_ptr arguments. |
| </p> |
| |
| <p>The proposed auto_ptr interface:</p> |
| |
| <pre>namespace std { |
| template<class X> class auto_ptr { |
| public: |
| typedef X element_type; |
| |
| // 20.4.5.1 construct/copy/destroy: |
| explicit auto_ptr(X* p=0) throw(); |
| auto_ptr(auto_ptr&) throw(); |
| template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); |
| auto_ptr& operator=(auto_ptr&) throw(); |
| template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw(); |
| ~auto_ptr() throw(); |
| |
| // 20.4.5.2 members: |
| X& operator*() const throw(); |
| X* operator->() const throw(); |
| X* get() const throw(); |
| X* release() throw(); |
| void reset(X* p=0) throw(); |
| |
| private: |
| template<class U> |
| auto_ptr(U& rhs, typename |
| unspecified_error_on_const_auto_ptr<U>::type = 0); |
| }; |
| } |
| </pre> |
| |
| <p> |
| One compliant technique to implement the unspecified_error_on_const_auto_ptr |
| helper class is using additional private auto_ptr member class template like |
| the following: |
| </p> |
| <pre>template<typename T> struct unspecified_error_on_const_auto_ptr; |
| |
| template<typename T> |
| struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const> |
| { typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; }; |
| </pre> |
| |
| <p> |
| There are other techniques to implement this helper class that might work |
| better for different compliers (i.e. better diagnostics) and therefore I |
| suggest defining its semantic behavior without mandating any specific |
| implementation. IMO, and I didn't found any compiler that thinks otherwise, |
| 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest |
| verifying this with core language experts. |
| </p> |
| |
| <p><b>Further changes in standard text:</b></p> |
| <p>Remove section 20.4.5.3</p> |
| |
| <p>Change 20.4.5/2 to read something like: |
| Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified |
| ill-formed declaration that will require unspecified diagnostic.</p> |
| |
| <p>Change 20.4.5.1/4,5,6 to read:</p> |
| |
| <pre>template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();</pre> |
| <p> 4 Requires: Y* can be implicitly converted to X*.</p> |
| <p> 5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().</p> |
| <p> 6 Postconditions: *this holds the pointer returned from a.release().</p> |
| |
| <p>Change 20.4.5.1/10</p> |
| <pre>template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw(); |
| </pre> |
| <p> |
| 10 Requires: Y* can be implicitly converted to X*. The expression delete |
| get() is well formed. |
| </p> |
| |
| <p>LWG TC DR #127 is obsolete.</p> |
| |
| <p> |
| Notice that the copy constructor and copy assignment operator should remain |
| as before and accept non-const auto_ptr& since they have effect on the form |
| of the implicitly declared copy constructor and copy assignment operator of |
| class that contains auto_ptr as member per 12.8/5,10: |
| </p> |
| <pre>struct X { |
| // implicit X(X&) |
| // implicit X& operator=(X&) |
| auto_ptr<D> aptr_; |
| }; |
| </pre> |
| |
| <p> |
| In most cases this indicates about sloppy programming but preserves the |
| current auto_ptr behavior. |
| </p> |
| |
| <p> |
| Dave Abrahams encouraged me to suggest fallback implementation in case that |
| my suggestion that involves removing of auto_ptr_ref will not be accepted. |
| In this case removing the obsolete conversion member to auto_ptr<Y> and |
| 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal |
| cases. The two constructors that I suggested will co exist with the current |
| members but will make auto_ptr_ref obsolete in initialization contexts. |
| auto_ptr_ref will be effective in assignment contexts as suggested in DR |
| #127 and I can't see any serious exception safety issues in those cases |
| (although it's possible to synthesize such). auto_ptr_ref<X> semantics will |
| have to be revised to say that it strictly holds pointer of type X and not |
| reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is |
| constructed from auto_ptr<X> in which X is different from Y (i.e. assignment |
| from r-value derived to base). |
| </p> |
| |
| <p><i>[Redmond: punt for the moment. We haven't decided yet whether we |
| want to fix auto_ptr for C++-0x, or remove it and replace it with |
| move_ptr and unique_ptr.]</i></p> |
| |
| |
| <p><i>[ |
| Oxford 2007: Recommend NAD. We're just going to deprecate it. It still works for simple use cases |
| and people know how to deal with it. Going forward <tt>unique_ptr</tt> is the recommended |
| tool. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| 2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change the synopsis in D.9.1 [auto.ptr]: |
| </p> |
| |
| <blockquote><pre>namespace std { |
| <del>template <class Y> struct auto_ptr_ref {};</del> |
| |
| <ins>// exposition only</ins> |
| <ins>template <class T> struct constant_object;</ins> |
| |
| <ins>// exposition only</ins> |
| <ins>template <class T></ins> |
| <ins>struct cannot_transfer_ownership_from</ins> |
| <ins>: constant_object<T> {};</ins> |
| |
| template <class X> class auto_ptr { |
| public: |
| typedef X element_type; |
| |
| // D.9.1.1 construct/copy/destroy: |
| explicit auto_ptr(X* p =0) throw(); |
| auto_ptr(auto_ptr&) throw(); |
| template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>&) throw(); |
| auto_ptr& operator=(auto_ptr&) throw(); |
| template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del>) throw(); |
| <del>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</del> |
| ~auto_ptr() throw(); |
| |
| // D.9.1.2 members: |
| X& operator*() const throw(); |
| X* operator->() const throw(); |
| X* get() const throw(); |
| X* release() throw(); |
| void reset(X* p =0) throw(); |
| |
| <del>// D.9.1.3 conversions:</del> |
| <del>auto_ptr(auto_ptr_ref<X>) throw();</del> |
| <del>template<class Y> operator auto_ptr_ref<Y>() throw();</del> |
| <del>template<class Y> operator auto_ptr<Y>() throw();</del> |
| |
| <ins>// exposition only</ins> |
| <ins>template<class U></ins> |
| <ins>auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0);</ins> |
| }; |
| |
| template <> class auto_ptr<void> |
| { |
| public: |
| typedef void element_type; |
| }; |
| |
| } |
| </pre></blockquote> |
| |
| <p> |
| Remove D.9.1.3 [auto.ptr.conv]. |
| </p> |
| |
| <p> |
| Change D.9.1 [auto.ptr], p3: |
| </p> |
| |
| <blockquote> |
| The <tt>auto_ptr</tt> provides a semantics of strict ownership. An |
| <tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an |
| <tt>auto_ptr</tt> copies the pointer and transfers ownership to the |
| destination. If more than one <tt>auto_ptr</tt> owns the same object at |
| the same time the behavior of the program is undefined. <ins>Templates |
| <tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>, |
| and the final constructor of <tt>auto_ptr</tt> are for exposition only. |
| For any types <tt>X</tt> and <tt>Y</tt>, initializing |
| <tt>auto_ptr<X></tt> from <tt>const auto_ptr<Y></tt> is |
| ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of |
| <tt>auto_ptr</tt> include providing temporary exception-safety for |
| dynamically allocated memory, passing ownership of dynamically allocated |
| memory to a function, and returning dynamically allocated memory from a |
| function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt> |
| and <tt>Assignable</tt> requirements for Standard Library container |
| elements and thus instantiating a Standard Library container with an |
| <tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>] |
| </blockquote> |
| |
| <p> |
| Change D.9.1.1 [auto.ptr.cons], p5: |
| </p> |
| |
| <blockquote> |
| <pre>template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>& a) throw(); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>. |
| </p> |
| <p> |
| <i>Effects:</i> Calls <ins><tt>const_cast<auto_ptr<Y>&>(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Change D.9.1.1 [auto.ptr.cons], p10: |
| </p> |
| |
| <blockquote> |
| <pre>template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del> a) throw(); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>. |
| The expression <tt>delete get()</tt> is well formed. |
| </p> |
| <p> |
| <i>Effects:</i> Calls <tt>reset(a.release())</tt>. |
| </p> |
| <p> |
| <i>Returns:</i> <tt>*this</tt>. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="471"></a>471. result of what() implementation-defined</h3> |
| <p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#type.info">issues</a> in [type.info].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| |
| <p>[lib.exception] specifies the following:</p> |
| <pre> exception (const exception&) throw(); |
| exception& operator= (const exception&) throw(); |
| |
| -4- Effects: Copies an exception object. |
| -5- Notes: The effects of calling what() after assignment |
| are implementation-defined. |
| </pre> |
| |
| <p> |
| First, does the Note only apply to the assignment operator? If so, |
| what are the effects of calling what() on a copy of an object? Is |
| the returned pointer supposed to point to an identical copy of |
| the NTBS returned by what() called on the original object or not? |
| </p> |
| |
| <p> |
| Second, is this Note intended to extend to all the derived classes |
| in section 19? I.e., does the standard provide any guarantee for |
| the effects of what() called on a copy of any of the derived class |
| described in section 19? |
| </p> |
| |
| <p> |
| Finally, if the answer to the first question is no, I believe it |
| constitutes a defect since throwing an exception object typically |
| implies invoking the copy ctor on the object. If the answer is yes, |
| then I believe the standard ought to be clarified to spell out |
| exactly what the effects are on the copy (i.e., after the copy |
| ctor was called). |
| </p> |
| |
| <p><i>[Redmond: Yes, this is fuzzy. The issue of derived classes is |
| fuzzy too.]</i></p> |
| |
| |
| <p><i>[ |
| Batavia: Howard provided wording. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Eric concerned this is unimplementable, due to nothrow guarantees. |
| Suggested implementation would involve reference counting. |
| </p> |
| <p> |
| Is the implied reference counting subtle enough to call out a note on |
| implementation? Probably not. |
| </p> |
| <p> |
| If reference counting required, could we tighten specification further |
| to require same pointer value? Probably an overspecification, especially |
| if exception classes defer evalutation of final string to calls to |
| what(). |
| </p> |
| <p> |
| Remember issue moved open and not resolved at Batavia, but cannot |
| remember who objected to canvas a disenting opinion - please speak up if |
| you disagree while reading these minutes! |
| </p> |
| <p> |
| Move to Ready as we are accepting words unmodified. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| The issue was pulled from Ready. It needs to make clear that only homogenous copying |
| is intended to be supported. Not coping from a dervied to a base. |
| </blockquote> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| Change 18.7.1 [exception] to: |
| </p> |
| |
| <blockquote> |
| <pre>exception(const exception& <ins><i>e</i></ins>) throw(); |
| exception& operator=(const exception& <ins><i>e</i></ins>) throw();</pre> |
| <blockquote> |
| <p> |
| -4- <i>Effects:</i> Copies an exception object. |
| </p> |
| <p> |
| <del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del> |
| </p> |
| <p> |
| <ins>-5- <i>Throws:</i> Nothing. This also applies |
| to all standard library-defined classes that derive from <tt>exception</tt>.</ins> |
| </p> |
| <p> |
| <ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>. This also applies |
| to all standard library-defined classes that derive from <tt>exception</tt>.</ins> |
| </p> |
| |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="473"></a>473. underspecified ctype calls</h3> |
| <p><b>Section:</b> 22.2.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Most ctype member functions come in two forms: one that operates |
| on a single character at a time and another form that operates |
| on a range of characters. Both forms are typically described by |
| a single Effects and/or Returns clause. |
| </p> |
| <p> |
| The Returns clause of each of the single-character non-virtual forms |
| suggests that the function calls the corresponding single character |
| virtual function, and that the array form calls the corresponding |
| virtual array form. Neither of the two forms of each virtual member |
| function is required to be implemented in terms of the other. |
| </p> |
| <p> |
| There are three problems: |
| </p> |
| <p> |
| 1. One is that while the standard does suggest that each non-virtual |
| member function calls the corresponding form of the virtual function, |
| it doesn't actually explicitly require it. |
| </p> |
| <p> |
| Implementations that cache results from some of the virtual member |
| functions for some or all values of their arguments might want to |
| call the array form from the non-array form the first time to fill |
| the cache and avoid any or most subsequent virtual calls. Programs |
| that rely on each form of the virtual function being called from |
| the corresponding non-virtual function will see unexpected behavior |
| when using such implementations. |
| </p> |
| <p> |
| 2. The second problem is that either form of each of the virtual |
| functions can be overridden by a user-defined function in a derived |
| class to return a value that is different from the one produced by |
| the virtual function of the alternate form that has not been |
| overriden. |
| </p> |
| <p> |
| Thus, it might be possible for, say, ctype::widen(c) to return one |
| value, while for ctype::widen(&c, &c + 1, &wc) to set |
| wc to another value. This is almost certainly not intended. Both |
| forms of every function should be required to return the same result |
| for the same character, otherwise the same program using an |
| implementation that calls one form of the functions will behave |
| differently than when using another implementation that calls the |
| other form of the function "under the hood." |
| </p> |
| <p> |
| 3. The last problem is that the standard text fails to specify whether |
| one form of any of the virtual functions is permitted to be implemented |
| in terms of the other form or not, and if so, whether it is required |
| or permitted to call the overridden virtual function or not. |
| </p> |
| <p> |
| Thus, a program that overrides one of the virtual functions so that |
| it calls the other form which then calls the base member might end |
| up in an infinite loop if the called form of the base implementation |
| of the function in turn calls the other form. |
| </p> |
| <p> |
| Lillehammer: Part of this isn't a real problem. We already talk about |
| caching. 22.1.1/6 But part is a real problem. ctype virtuals may call |
| each other, so users don't know which ones to override to avoid avoid |
| infinite loops.</p> |
| |
| <p>This is a problem for all facet virtuals, not just ctype virtuals, |
| so we probably want a blanket statement in clause 22 for all |
| facets. The LWG is leaning toward a blanket prohibition, that a |
| facet's virtuals may never call each other. We might want to do that |
| in clause 27 too, for that matter. A review is necessary. Bill will |
| provide wording.</p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="484"></a>484. Convertible to T</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-09-16</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>From comp.std.c++:</p> |
| |
| <p> |
| I note that given an input iterator a for type T, |
| then *a only has to be "convertable to T", not actually of type T. |
| </p> |
| |
| <p>Firstly, I can't seem to find an exact definition of "convertable to T". |
| While I assume it is the obvious definition (an implicit conversion), I |
| can't find an exact definition. Is there one?</p> |
| |
| <p>Slightly more worryingly, there doesn't seem to be any restriction on |
| the this type, other than it is "convertable to T". Consider two input |
| iterators a and b. I would personally assume that most people would |
| expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that |
| the standard requires that, and that whatever type *a is (call it U) |
| could have == defined on it with totally different symantics and still |
| be a valid inputer iterator.</p> |
| |
| <p>Is this a correct reading? When using input iterators should I write |
| T(*a) all over the place to be sure that the object i'm using is the |
| class I expect?</p> |
| |
| <p>This is especially a nuisance for operations that are defined to be |
| "convertible to bool". (This is probably allowed so that |
| implementations could return say an int and avoid an unnessary |
| conversion. However all implementations I have seen simply return a |
| bool anyway. Typical implemtations of STL algorithms just write |
| things like <tt>while(a!=b && *a!=0)</tt>. But strictly |
| speaking, there are lots of types that are convertible to T but |
| that also overload the appropriate operators so this doesn't behave |
| as expected.</p> |
| |
| <p>If we want to make code like this legal (which most people seem to |
| expect), then we'll need to tighten up what we mean by "convertible |
| to T".</p> |
| |
| <p><i>[Lillehammer: The first part is NAD, since "convertible" is |
| well-defined in core. The second part is basically about pathological |
| overloads. It's a minor problem but a real one. So leave open for |
| now, hope we solve it as part of iterator redesign.]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="485"></a>485. output iterator insufficently constrained</h3> |
| <p><b>Section:</b> 24.1.2 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-10-13</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The note on 24.1.2 Output iterators insufficently limits what can be |
| performed on output iterators. While it requires that each iterator is |
| progressed through only once and that each iterator is written to only |
| once, it does not require the following things:</p> |
| |
| <p>Note: Here it is assumed that x is an output iterator of type X which |
| has not yet been assigned to.</p> |
| |
| <p>a) That each value of the output iterator is written to: |
| The standard allows: |
| ++x; ++x; ++x; |
| </p> |
| |
| <p> |
| b) That assignments to the output iterator are made in order |
| X a(x); ++a; *a=1; *x=2; is allowed |
| </p> |
| |
| <p> |
| c) Chains of output iterators cannot be constructed: |
| X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current |
| wording (I believe) x,a,b,c could be written to in any order. |
| </p> |
| |
| <p>I do not believe this was the intension of the standard?</p> |
| <p><i>[Lillehammer: Real issue. There are lots of constraints we |
| intended but didn't specify. Should be solved as part of iterator |
| redesign.]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3> |
| <p><b>Section:</b> 23 [containers], 24 [iterators], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>Various clauses other than clause 25 make use of iterator arithmetic not |
| supported by the iterator category in question. |
| Algorithms in clause 25 are exceptional because of 25 [lib.algorithms], |
| paragraph 9, but this paragraph does not provide semantics to the |
| expression "iterator - n", where n denotes a value of a distance type |
| between iterators.</p> |
| |
| <p>1) Examples of current wording:</p> |
| |
| <p>Current wording outside clause 25:</p> |
| |
| <p> |
| 23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)", |
| "(last - first)" |
| 23.3.1.1 [lib.map.cons], paragraph 4: "last - first" |
| 23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first" |
| 23.3.3.1 [lib.set.cons], paragraph 4: "last - first" |
| 23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first" |
| 24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)" |
| </p> |
| |
| <p> |
| [Important note: The list is not complete, just an illustration. The |
| same issue might well apply to other paragraphs not listed here.]</p> |
| |
| <p>None of these expressions is valid for the corresponding iterator |
| category.</p> |
| |
| <p>Current wording in clause 25:</p> |
| |
| <p> |
| 25.1.1 [lib.alg.foreach], paragraph 1: "last - 1" |
| 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 - |
| (last2-first2))" |
| 25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)" |
| 25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)" |
| </p> |
| |
| <p> |
| However, current wording of 25 [lib.algorithms], paragraph 9 covers |
| neither of these four cases:</p> |
| |
| <p>Current wording of 25 [lib.algorithms], paragraph 9:</p> |
| |
| <p> |
| "In the description of the algorithms operator + and - are used for some |
| of the iterator categories for which they do not have to be defined. In |
| these cases the semantics of a+n is the same as that of</p> |
| <pre>{X tmp = a; |
| advance(tmp, n); |
| return tmp; |
| } |
| </pre> |
| <p>and that of b-a is the same as of return distance(a, b)"</p> |
| |
| <p> |
| This paragrpah does not take the expression "iterator - n" into account, |
| where n denotes a value of a distance type between two iterators [Note: |
| According to current wording, the expression "iterator - n" would be |
| resolved as equivalent to "return distance(n, iterator)"]. Even if the |
| expression "iterator - n" were to be reinterpreted as equivalent to |
| "iterator + -n" [Note: This would imply that "a" and "b" were |
| interpreted implicitly as values of iterator types, and "n" as value of |
| a distance type], then 24.3.4/2 interfers because it says: "Requires: n |
| may be negative only for random access and bidirectional iterators.", |
| and none of the paragraphs quoted above requires the iterators on which |
| the algorithms operate to be of random access or bidirectional category. |
| </p> |
| |
| <p>2) Description of intended behavior:</p> |
| |
| <p> |
| For the rest of this Defect Report, it is assumed that the expression |
| "iterator1 + n" and "iterator1 - iterator2" has the semantics as |
| described in current 25 [lib.algorithms], paragraph 9, but applying to |
| all clauses. The expression "iterator1 - n" is equivalent to an |
| result-iterator for which the expression "result-iterator + n" yields an |
| iterator denoting the same position as iterator1 does. The terms |
| "iterator1", "iterator2" and "result-iterator" shall denote the value of |
| an iterator type, and the term "n" shall denote a value of a distance |
| type between two iterators.</p> |
| |
| <p> |
| All implementations known to the author of this Defect Report comply |
| with these assumptions. |
| No impact on current code is expected.</p> |
| |
| <p>3) Proposed fixes:</p> |
| |
| |
| <p>Change 25 [lib.algorithms], paragraph 9 to:</p> |
| |
| <p> |
| "In the description of the algorithms operator + and - are used for some |
| of the iterator categories for which they do not have to be defined. In |
| this paragraph, a and b denote values of an iterator type, and n denotes |
| a value of a distance type between two iterators. In these cases the |
| semantics of a+n is the same as that of</p> |
| <pre>{X tmp = a; |
| advance(tmp, n); |
| return tmp; |
| } |
| </pre> |
| <p>,the semantics of a-n denotes the value of an iterator i for which the |
| following condition holds: |
| advance(i, n) == a, |
| and that of b-a is the same as of |
| return distance(a, b)". |
| </p> |
| |
| <p>Comments to the new wording:</p> |
| |
| <p> |
| a) The wording " In this paragraph, a and b denote values of an iterator |
| type, and n denotes a value of a distance type between two iterators." |
| was added so the expressions "b-a" and "a-n" are distinguished regarding |
| the types of the values on which they operate. |
| b) The wording ",the semantics of a-n denotes the value of an iterator i |
| for which the following condition holds: advance(i, n) == a" was added |
| to cover the expression 'iterator - n'. The wording "advance(i, n) == a" |
| was used to avoid a dependency on the semantics of a+n, as the wording |
| "i + n == a" would have implied. However, such a dependency might well |
| be deserved. |
| c) DR 225 is not considered in the new wording. |
| </p> |
| |
| <p> |
| Proposed fixes regarding invalid iterator arithmetic expressions outside |
| clause 25:</p> |
| |
| <p> |
| Either |
| a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above) |
| before any current invalid iterator arithmetic expression. In that case, |
| the first sentence of 25 [lib.algorithms], paragraph 9, need also to be |
| modified and could read: "For the rest of this International Standard, |
| ...." / "In the description of the following clauses including this |
| ...." / "In the description of the text below ..." etc. - anyways |
| substituting the wording "algorithms", which is a straight reference to |
| clause 25. |
| In that case, 25 [lib.algorithms] paragraph 9 will certainly become |
| obsolete. |
| Alternatively, |
| b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms], |
| paragraph 9, to the beginning of each clause containing invalid iterator |
| arithmetic expressions. |
| Alternatively, |
| c) Fix each paragraph (both current wording and possible resolutions of |
| DRs) containing invalid iterator arithmetic expressions separately. |
| </p> |
| |
| <p>5) References to other DRs:</p> |
| |
| <p> |
| See DR 225. |
| See DR 237. The resolution could then also read "Linear in last - |
| first". |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Keep open and ask Bill to provide wording. |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement |
| about this in 25/11. But (a) it should be in 17, not 25; and (b) it's |
| not quite broad enough, because there are some arithmetic expressions |
| it doesn't cover. Bill will provide wording.]</i></p> |
| |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3> |
| <p><b>Section:</b> 25.2.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 2005-05-04</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Problem: |
| The iterator requirements for partition() and stable_partition() [25.2.12] |
| are listed as BidirectionalIterator, however, there are efficient algorithms |
| for these functions that only require ForwardIterator that have been known |
| since before the standard existed. The SGI implementation includes these (see |
| <a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a> |
| and |
| <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>). |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 25.2.12 from </p> |
| <blockquote><pre>template<class BidirectionalIterator, class Predicate> |
| BidirectionalIterator partition(BidirectionalIterato r first, |
| BidirectionalIterator last, |
| Predicate pred); |
| </pre></blockquote> |
| <p>to </p> |
| <blockquote><pre>template<class ForwardIterator, class Predicate> |
| ForwardIterator partition(ForwardIterator first, |
| ForwardIterator last, |
| Predicate pred); |
| </pre></blockquote> |
| <p>Change the complexity from </p> |
| |
| <blockquote><p> |
| At most (last - first)/2 swaps are done. Exactly (last - first) |
| applications of the predicate are done. |
| </p></blockquote> |
| |
| <p>to </p> |
| |
| <blockquote><p> |
| If ForwardIterator is a bidirectional_iterator, at most (last - first)/2 |
| swaps are done; otherwise at most (last - first) swaps are done. Exactly |
| (last - first) applications of the predicate are done. |
| </p></blockquote> |
| |
| |
| |
| <p><b>Rationale:</b></p> |
| <p> |
| Partition is a "foundation" algorithm useful in many contexts (like sorting |
| as just one example) - my motivation for extending it to include forward |
| iterators is slist - without this extension you can't partition an slist |
| (without writing your own partition). Holes like this in the standard |
| library weaken the argument for generic programming (ideally I'd be able |
| to provide a library that would refine std::partition() to other concepts |
| without fear of conflicting with other libraries doing the same - but |
| that is a digression). I consider the fact that partition isn't defined |
| to work for ForwardIterator a minor embarrassment. |
| </p> |
| |
| <p><i>[Mont Tremblant: Moved to Open, request motivation and use cases |
| by next meeting. Sean provided further rationale by post-meeting |
| mailing.]</i></p> |
| |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 2005-06-07</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Motivation: |
| </p> |
| |
| <p> |
| This requirement seems obvious to me, it is the essence of code modularity. |
| I have complained to Mr. Plauger that the Dinkumware library does not |
| observe this principle but he objected that this behaviour is not covered in |
| the standard. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Append the following point to 22.1.1.1.1: |
| </p> |
| |
| <p> |
| 6. The implementation of a facet of Table 52 parametrized with an |
| InputIterator/OutputIterator should use that iterator only as character |
| source/sink respectively. |
| For a *_get facet, it means that the value received depends only on the |
| sequence of input characters and not on how they are accessed. |
| For a *_put facet, it means that the sequence of characters output depends |
| only on the value to be formatted and not of how the characters are stored. |
| </p> |
| |
| <p><i>[ |
| Berlin: Moved to Open, Need to clean up this area to make it clear |
| locales don't have to contain open ended sets of facets. Jack, Howard, |
| Bill. |
| ]</i></p> |
| |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="503"></a>503. more on locales</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2005-06-20</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table |
| 51" to refer to the facet *objects* associated with a locale. And we |
| almost certainly mean just those associated with the default or "C" |
| locale. Otherwise, you can't switch to a locale that enforces a different |
| mapping between narrow and wide characters, or that defines additional |
| uppercase characters. |
| </p> |
| |
| <p> |
| b) 22.2.1.5 para. 3 (codecvt) has the same issues. |
| </p> |
| |
| <p> |
| c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of |
| a homing sequence for the basic character set, which might very well need |
| one. |
| </p> |
| |
| <p> |
| d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping |
| between wide and narrow characters be taken as one-for-one. |
| </p> |
| |
| <p> |
| e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as |
| I can tell. The muddle is, as before, calling Table 51 a list of |
| instantiations. But the constraint it applies seems to me to cover |
| *all* defined uses of num_get/put, so why bother to say so? |
| </p> |
| |
| <p> |
| f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations |
| return '.' or L'.'.) Presumably this means "as appropriate for the |
| character type. But given the vague definition of "required" earlier, |
| this overrules *any* change of decimal point for non "C" locales. |
| Surely we don't want to do that. |
| </p> |
| |
| <p> |
| g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations |
| return ',' or L','.) As above, this probably means "as appropriate for the |
| character type. But this overrules the "C" locale, which requires *no* |
| character ('\0') for the thousands separator. Even if we agree that we |
| don't mean to block changes in decimal point or thousands separator, |
| we should also eliminate this clear incompatibility with C. |
| </p> |
| |
| <p> |
| h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations |
| return the empty string, indicating no grouping." Same considerations |
| as for do_decimal_point. |
| </p> |
| |
| <p> |
| i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table |
| 51". Same bad jargon. |
| </p> |
| |
| <p> |
| j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required |
| in Table 51". Same bad jargon. |
| </p> |
| |
| <p> |
| k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous |
| as num_get/put. |
| </p> |
| |
| <p> |
| l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous |
| as num_get/put. |
| </p> |
| |
| <p> |
| m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required |
| in Table 51 ... return an object of type pattern initialized to |
| {symbol, sign, none, value}." This once again *overrides* the "C" |
| locale, as well as any other locale." |
| </p> |
| |
| <p> |
| 3) We constrain the use_facet calls that can be made by num_get/put, |
| so why don't we do the same for money_get/put? Or for any of the |
| other facets, for that matter? |
| </p> |
| |
| <p> |
| 4) As an almost aside, we spell out when a facet needs to use the ctype |
| facet, but several also need to use a codecvt facet and we don't say so. |
| </p> |
| <p><i>[ |
| Berlin: Bill to provide wording. |
| ]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="522"></a>522. Tuple doesn't define swap</h3> |
| <p><b>Section:</b> 20.4 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Andy Koenig <b>Date:</b> 2005-07-03</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Tuple doesn't define swap(). It should. |
| </p> |
| <p><i>[ |
| Berlin: Doug to provide wording. |
| ]</i></p> |
| |
| <p><i>[ |
| Batavia: Howard to provide wording. |
| ]</i></p> |
| |
| <p><i>[ |
| Toronto: Howard to provide wording (really this time). |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Bellevue: Alisdair provided wording. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| Add these signatures to 20.4 [tuple] |
| </p> |
| |
| <blockquote><pre>template <class... Types> |
| void swap(tuple<Types...>& x, tuple<Types...>& y); |
| template <class... Types> |
| void swap(tuple<Types...>&& x, tuple<Types...>& y); |
| template <class... Types> |
| void swap(tuple<Types...>& x, tuple<Types...>&& y); |
| </pre></blockquote> |
| |
| <p> |
| Add this signature to 20.4.1 [tuple.tuple] |
| </p> |
| |
| <blockquote><pre>void swap(tuple&&); |
| </pre></blockquote> |
| |
| <p> |
| Add the following two sections to the end of the tuple clauses |
| </p> |
| |
| <blockquote> |
| <p> |
| 20.3.1.7 tuple swap [tuple.swap] |
| </p> |
| |
| <pre>void swap(tuple&& rhs); |
| </pre> |
| |
| <blockquote> |
| <p> |
| <i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>. |
| </p> |
| <p> |
| <i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element |
| in <tt>rhs</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an |
| exception. |
| </p> |
| </blockquote> |
| |
| <p> |
| 20.3.1.8 tuple specialized algorithms [tuple.special] |
| </p> |
| |
| <pre>template <class... Types> |
| void swap(tuple<Types...>& x, tuple<Types...>& y); |
| template <class... Types> |
| void swap(tuple<Types...>&& x, tuple<Types...>& y); |
| template <class... Types> |
| void swap(tuple<Types...>& x, tuple<Types...>&& y); |
| </pre> |
| |
| <blockquote> |
| <p> |
| <i>Effects:</i> x.swap(y) |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3> |
| <p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| A problem with TR1 regex is currently being discussed on the Boost |
| developers list. It involves the handling of case-insensitive matching |
| of character ranges such as [Z-a]. The proper behavior (according to the |
| ECMAScript standard) is unimplementable given the current specification |
| of the TR1 regex_traits<> class template. John Maddock, the author of |
| the TR1 regex proposal, agrees there is a problem. The full discussion |
| can be found at http://lists.boost.org/boost/2005/06/28850.php (first |
| message copied below). We don't have any recommendations as yet. |
| </p> |
| <p> |
| -- Begin original message -- |
| </p> |
| <p> |
| The situation of interest is described in the ECMAScript specification |
| (ECMA-262), section 15.10.2.15: |
| </p> |
| <p> |
| "Even if the pattern ignores case, the case of the two ends of a range |
| is significant in determining which characters belong to the range. |
| Thus, for example, the pattern /[E-F]/i matches only the letters E, F, |
| e, and f, while the pattern /[E-f]/i matches all upper and lower-case |
| ASCII letters as well as the symbols [, \, ], ^, _, and `." |
| </p> |
| <p> |
| A more interesting case is what should happen when doing a |
| case-insentitive match on a range such as [Z-a]. It should match z, Z, |
| a, A and the symbols [, \, ], ^, _, and `. This is not what happens with |
| Boost.Regex (it throws an exception from the regex constructor). |
| </p> |
| <p> |
| The tough pill to swallow is that, given the specification in TR1, I |
| don't think there is any effective way to handle this situation. |
| According to the spec, case-insensitivity is handled with |
| regex_traits<>::translate_nocase(CharT) -- two characters are equivalent |
| if they compare equal after both are sent through the translate_nocase |
| function. But I don't see any way of using this translation function to |
| make character ranges case-insensitive. Consider the difficulty of |
| detecting whether "z" is in the range [Z-a]. Applying the transformation |
| to "z" has no effect (it is essentially std::tolower). And we're not |
| allowed to apply the transformation to the ends of the range, because as |
| ECMA-262 says, "the case of the two ends of a range is significant." |
| </p> |
| <p> |
| So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix |
| is to redefine translate_nocase to return a string_type containing all |
| the characters that should compare equal to the specified character. But |
| this function is hard to implement for Unicode, and it doesn't play nice |
| with the existing ctype facet. What a mess! |
| </p> |
| <p> |
| -- End original message -- |
| </p> |
| |
| <p><i>[ |
| John Maddock adds: |
| ]</i></p> |
| |
| |
| <p> |
| One small correction, I have since found that ICU's regex package does |
| implement this correctly, using a similar mechanism to the current |
| TR1.Regex. |
| </p> |
| <p> |
| Given an expression [c1-c2] that is compiled as case insensitive it: |
| </p> |
| <p> |
| Enumerates every character in the range c1 to c2 and converts it to it's |
| case folded equivalent. That case folded character is then used a key to a |
| table of equivalence classes, and each member of the class is added to the |
| list of possible matches supported by the character-class. This second step |
| isn't possible with our current traits class design, but isn't necessary if |
| the input text is also converted to a case-folded equivalent on the fly. |
| </p> |
| <p> |
| ICU applies similar brute force mechanisms to character classes such as |
| [[:lower:]] and [[:word:]], however these are at least cached, so the impact |
| is less noticeable in this case. |
| </p> |
| <p> |
| Quick and dirty performance comparisons show that expressions such as |
| "[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times |
| slower than a "normal" expression). For an application that uses a lot of |
| regexes this could have a noticeable performance impact. ICU also has an |
| advantage in that it knows the range of valid characters codes: code points |
| outside that range are assumed not to require enumeration, as they can not |
| be part of any equivalence class. I presume that if we want the TR1.Regex |
| to work with arbitrarily large character sets enumeration really does become |
| impractical. |
| </p> |
| <p> |
| Finally note that Unicode has: |
| </p> |
| <p> |
| Three cases (upper, lower and title). |
| One to many, and many to one case transformations. |
| Character that have context sensitive case translations - for example an |
| uppercase sigma has two different lowercase forms - the form chosen depends |
| on context(is it end of a word or not), a caseless match for an upper case |
| sigma should match either of the lower case forms, which is why case folding |
| is often approximated by tolower(toupper(c)). |
| </p> |
| <p> |
| Probably we need some way to enumerate character equivalence classes, |
| including digraphs (either as a result or an input), and some way to tell |
| whether the next character pair is a valid digraph in the current locale. |
| </p> |
| <p> |
| Hoping this doesn't make this even more complex that it was already, |
| </p> |
| |
| <p><i>[ |
| Portland: Alisdair: Detect as invalid, throw an exception. |
| Pete: Possible general problem with case insensitive ranges. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3> |
| <p><b>Section:</b> 26.6.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 2006-02-06</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| There are some problems in the definition of partial_sum and |
| adjacent_difference in 26.4 [lib.numeric.ops] |
| </p> |
| |
| <p> |
| Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not |
| parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply |
| specifies the effects clause as; |
| </p> |
| |
| <blockquote><p> |
| Assigns to every element referred to by iterator <tt>i</tt> in the range |
| <tt>[result,result + (last - first))</tt> a value correspondingly equal to |
| </p> |
| <blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result ))) |
| </pre></blockquote> |
| </blockquote> |
| |
| <p> |
| And similarly for BinaryOperation. Using just this definition, it seems |
| logical to expect that: |
| </p> |
| |
| |
| <blockquote><pre>char i_array[4] = { 100, 100, 100, 100 }; |
| int o_array[4]; |
| |
| std::partial_sum(i_array, i_array+4, o_array); |
| </pre></blockquote> |
| |
| <p> |
| Is equivalent to |
| </p> |
| |
| <blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 }; |
| </pre></blockquote> |
| |
| <p> |
| i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>, |
| <tt>int</tt>. |
| </p> |
| |
| <p> |
| Yet all implementations I have tested produce 100, -56, 44, -112, |
| because they are using an accumulator of the <tt>InputIterator</tt>'s |
| <tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>. |
| </p> |
| |
| <p> |
| The issue becomes more noticeable when the result of the expression <tt>*i + |
| *(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the |
| <tt>value_type</tt>. In a contrived example: |
| </p> |
| |
| <blockquote><pre>enum not_int { x = 1, y = 2 }; |
| ... |
| not_int e_array[4] = { x, x, y, y }; |
| std::partial_sum(e_array, e_array+4, o_array); |
| </pre></blockquote> |
| |
| <p> |
| Is it the intent that the operations happen in the <tt>input type</tt>, or in |
| the <tt>result type</tt>? |
| </p> |
| |
| <p> |
| If the intent is that operations happen in the <tt>result type</tt>, something |
| like this should be added to the "Requires" clause of 26.4.3/4 |
| [lib.partial.sum]: |
| </p> |
| |
| <blockquote><p> |
| The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the |
| requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> |
| (23.1) types. |
| </p></blockquote> |
| |
| <p> |
| (As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2 |
| [lib.inner.product].) |
| </p> |
| |
| <p> |
| The "auto initializer" feature proposed in |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a> |
| is not required to |
| implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be |
| obtained by using the <tt>std::plus<></tt> function object. |
| </p> |
| |
| <p> |
| If the intent is that operations happen in the <tt>input type</tt>, then |
| something like this should be added instead; |
| </p> |
| |
| <blockquote><p> |
| The type of *first shall meet the requirements of |
| <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types. |
| The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be |
| convertible to this type. |
| </p></blockquote> |
| |
| <p> |
| The 'widening' behaviour can then be obtained by writing a custom proxy |
| iterator, which is somewhat involved. |
| </p> |
| |
| <p> |
| In both cases, the semantics should probably be clarified. |
| </p> |
| |
| <p> |
| 26.4.4 [lib.adjacent.difference] is similarly underspecified, although |
| all implementations seem to perform operations in the 'result' type: |
| </p> |
| |
| <blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 }; |
| int o_array[4]; |
| |
| std::adjacent_difference(i_array, i_array+4, o_array); |
| </pre></blockquote> |
| |
| <p> |
| o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255. |
| </p> |
| |
| <p> |
| In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the |
| <tt>value_type</tt>; it can be brought in line with the rest of 26.4 |
| [lib.numeric.ops] by adding the following to 26.4.4/2 |
| [lib.adjacent.difference]: |
| </p> |
| |
| <blockquote><p> |
| The type of <tt>*first</tt> shall meet the requirements of |
| <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types." |
| </p></blockquote> |
| <p><i>[ |
| Berlin: Giving output iterator's value_types very controversial. Suggestion of |
| adding signatures to allow user to specify "accumulator". |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| The intent of the algorithms is to perform their calculations using the type of the input iterator. |
| Proposed wording provided. |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| We did not agree that the proposed resolution was correct. For example, |
| when the arguments are types <tt>(float*, float*, double*)</tt>, the |
| highest-quality solution would use double as the type of the |
| accumulator. If the intent of the wording is to require that the type of |
| the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the wording |
| should specify it. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences: |
| </p> |
| |
| <blockquote> |
| The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>? |
| (20.1.3?) and <tt>Assignable</tt> (23.1?) types. The result of <tt>*i + *(i+1)</tt> or |
| <tt>binary_op(*i, *(i+1))</tt> shall be convertible to this type. |
| </blockquote> |
| |
| <p> |
| Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence: |
| </p> |
| |
| <blockquote> |
| The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>? |
| (20.1.3) and <tt>Assignable</tt> (23.1) types. |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3> |
| <p><b>Section:</b> TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99]. |
| The rest of the TR should use that type. I believe this affects two places. |
| First, the random number requirements, 5.1.1/10-11, lists all of the types with |
| which template parameters named IntType and UIntType may be instantiated. |
| _Longlong (or "long long", assuming it is added to C++0x) should be added to the |
| IntType list, and UIntType (again, or "unsigned long long") should be added to |
| the UIntType list. Second, 6.3.2 lists the types for which hash<> is |
| required to be instantiable. _Longlong and _Ulonglong should be added to that |
| list, so that people may use long long as a hash key. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-05</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In 25, p8 we allow BinaryPredicates to return a type that's convertible |
| to bool but need not actually be bool. That allows predicates to return |
| things like proxies and requires that implementations be careful about |
| what kinds of expressions they use the result of the predicate in (e.g., |
| the expression in if (!pred(a, b)) need not be well-formed since the |
| negation operator may be inaccessible or return a type that's not |
| convertible to bool). |
| </p> |
| <p> |
| Here's the text for reference: |
| </p> |
| <blockquote><p> |
| ...if an algorithm takes BinaryPredicate binary_pred as its argument |
| and first1 and first2 as its iterator arguments, it should work |
| correctly in the construct if (binary_pred(*first1, first2)){...}. |
| </p></blockquote> |
| |
| <p> |
| In 25.3, p2 we require that the Compare function object return true |
| of false, which would seem to preclude such proxies. The relevant text |
| is here: |
| </p> |
| <blockquote><p> |
| Compare is used as a function object which returns true if the first |
| argument is less than the second, and false otherwise... |
| </p></blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| I think we could fix this by rewording 25.3, p2 to read somthing like: |
| </p> |
| <blockquote><p> |
| -2- <tt>Compare</tt> is <del>used as a function object which returns |
| <tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The |
| return value of the function call operator applied to an object of type |
| <tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt> |
| if the first argument of the call</ins> is less than the second, and |
| <tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for |
| algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt> |
| will not apply any non-constant function through the dereferenced iterator. |
| </p></blockquote> |
| |
| |
| <p><i>[ |
| Portland: Jack to define "convertible to bool" such that short circuiting isn't |
| destroyed. |
| ]</i></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="564"></a>564. stringbuf seekpos underspecified</h3> |
| <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The effects of the <code>seekpos()</code> member function of |
| <code>basic_stringbuf</code> simply say that the function positions |
| the input and/or output sequences but fail to spell out exactly |
| how. This is in contrast to the detail in which <code>seekoff()</code> |
| is described. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| Change 27.7.1.3, p13 to read: |
| |
| </p> |
| <blockquote> |
| <p> |
| -13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg, |
| <i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences, |
| if possible, to correspond to the stream position stored in <tt><i>sp</i></tt> |
| (as described below).</del> |
| </p> |
| <ul> |
| <li><del>If <tt>(<i>which</i> & ios_base::in) != 0</tt>, positions the input sequence.</del></li> |
| <li><del>If <tt>(<i>which</i> & ios_base::out) != 0</tt>, positions the output sequence.</del></li> |
| <li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function |
| positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt> |
| has not been obtained by a previous successful call to one of the positioning |
| functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>) |
| the effect is undefined.</del></li> |
| </ul> |
| </blockquote> |
| |
| |
| <p><i>[ |
| Kona (2007): A <tt>pos_type</tt> is a position in a stream by |
| definition, so there is no ambiguity as to what it means. Proposed |
| Disposition: NAD |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Post-Kona Martin adds: |
| I'm afraid I disagree |
| with the Kona '07 rationale for marking it NAD. The only text |
| that describes precisely what it means to position the input |
| or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects |
| clause is inadequate in comparison and the proposed resolution |
| plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>. |
| ]</i></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="565"></a>565. xsputn inefficient</h3> |
| <p><b>Section:</b> 27.5.2.4.5 [streambuf.virt.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| <tt>streambuf::xsputn()</tt> is specified to have the effect of |
| "writing up to <tt>n</tt> characters to the output sequence as if by |
| repeated calls to <tt>sputc(c)</tt>." |
| |
| </p> |
| <p> |
| |
| Since <tt>sputc()</tt> is required to call <tt>overflow()</tt> when |
| <tt>(pptr() == epptr())</tt> is true, strictly speaking |
| <tt>xsputn()</tt> should do the same. However, doing so would be |
| suboptimal in some interesting cases, such as in unbuffered mode or |
| when the buffer is <tt>basic_stringbuf</tt>. |
| |
| </p> |
| <p> |
| |
| Assuming calling <tt>overflow()</tt> is not really intended to be |
| required and the wording is simply meant to describe the general |
| effect of appending to the end of the sequence it would be worthwhile |
| to mention in <tt>xsputn()</tt> that the function is not actually |
| required to cause a call to <tt>overflow()</tt>. |
| |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| Add the following sentence to the <tt>xsputn()</tt> Effects clause in |
| 27.5.2.4.5, p1 (N1804): |
| |
| </p> |
| <blockquote> |
| <p> |
| -1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output |
| sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters |
| written are obtained from successive elements of the array whose first element |
| is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt> |
| characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return |
| <tt>traits::eof()</tt>. <ins>It is uspecified whether the function calls |
| <tt>overflow()</tt> when <tt>(pptr() == epptr())</tt> becomes true or whether |
| it achieves the same effects by other means.</ins> |
| </p> |
| </blockquote> |
| <p> |
| |
| In addition, I suggest to add a footnote to this function with the |
| same text as Footnote 292 to make it extra clear that derived classes |
| are permitted to override <tt>xsputn()</tt> for efficiency. |
| |
| </p> |
| |
| |
| <p><i>[ |
| Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly |
| to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that |
| has always been the intention of the committee. We believe that the |
| proposed wording doesn't accomplish that. Proposed Disposition: Open |
| ]</i></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="568"></a>568. log2 overloads missing</h3> |
| <p><b>Section:</b> TR1 8.16.4 [tr.c99.cmath.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-03-07</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1. |
| </p> |
| |
| <p> |
| Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1. |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-12</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| There are two deficiencies related to file sizes: |
| </p> |
| <ol> |
| <li>It doesn't appear that the Standard Library is specified in |
| a way that handles modern file sizes, which are often too |
| large to be represented by an unsigned long.</li> |
| |
| <li>The std::fpos class does not currently have the ability to |
| set/get file positions.</li> |
| </ol> |
| <p> |
| The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by: |
| </p> |
| <ol type="A"> |
| <li>Defining fpos_t be long long, which is large enough to |
| represent any file position likely in the foreseeable future.</li> |
| |
| <li>Adding member functions to class fpos. For example, |
| <blockquote><pre>fpos_t seekpos() const; |
| </pre></blockquote> |
| </li> |
| </ol> |
| <p> |
| Because there are so many types relating to file positions and offsets (fpos_t, |
| fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and |
| perhaps more), it is difficult to know if the Dinkumware extensions are |
| sufficient. But they seem a useful starting place for discussions, and they do |
| represent existing practice. |
| </p> |
| |
| <p><i>[ |
| Kona (2007): We need a paper. It would be nice if someone proposed |
| clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently |
| these definitions are horrible. Proposed Disposition: Open |
| ]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="580"></a>580. unused allocator members</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| C++ Standard Library templates that take an allocator as an argument |
| are required to call the <code>allocate()</code> and |
| <code>deallocate()</code> members of the allocator object to obtain |
| storage. However, they do not appear to be required to call any other |
| allocator members such as <code>construct()</code>, |
| <code>destroy()</code>, <code>address()</code>, and |
| <code>max_size()</code>. This makes these allocator members less than |
| useful in portable programs. |
| |
| </p> |
| <p> |
| |
| It's unclear to me whether the absence of the requirement to use these |
| allocator members is an unintentional omission or a deliberate |
| choice. However, since the functions exist in the standard allocator |
| and since they are required to be provided by any user-defined |
| allocator I believe the standard ought to be clarified to explictly |
| specify whether programs should or should not be able to rely on |
| standard containers calling the functions. |
| |
| </p> |
| <p> |
| |
| I propose that all containers be required to make use of these |
| functions. |
| |
| </p> |
| <p><i>[ |
| Batavia: We support this resolution. Martin to provide wording. |
| ]</i></p> |
| |
| <p><i>[ |
| pre-Oxford: Martin provided wording. |
| ]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| Specifically, I propose to change 23.1 [container.requirements], |
| p9 as follows: |
| |
| </p> |
| <blockquote> |
| <p> |
| -9- Copy constructors for all container types defined in this clause |
| <ins>that are parametrized on <code>Allocator</code></ins> copy |
| <del>an</del><ins>the</ins> allocator argument from their respective |
| first parameters. |
| |
| All other constructors for these container types take a<del>n</del> |
| <ins>const</ins> <code>Allocator&</code> argument (20.1.6), an |
| allocator whose <code>value_type</code> is the same as the container's |
| <code>value_type</code>. |
| |
| A copy of this argument <del>is</del><ins>shall be</ins> used for any |
| memory allocation <ins> and deallocation</ins> performed<del>,</del> |
| by these constructors and by all member functions<del>,</del> during |
| the lifetime of each container object. <ins>Allocation shall be |
| performed "as if" by calling the <code>allocate()</code> member |
| function on a copy of the allocator object of the appropriate type |
| <sup>New Footnote)</sup>, and deallocation "as if" by calling |
| <code>deallocate()</code> on a copy of the same allocator object of |
| the corresponding type.</ins> |
| |
| <ins>A copy of this argument shall also be used to construct and |
| destroy objects whose lifetime is managed by the container, including |
| but not limited to those of the container's <code>value_type</code>, |
| and to obtain their address. All objects residing in storage |
| allocated by a container's allocator shall be constructed "as if" by |
| calling the <code>construct()</code> member function on a copy of the |
| allocator object of the appropriate type. The same objects shall be |
| destroyed "as if" by calling <code>destroy()</code> on a copy of the |
| same allocator object of the same type. The address of such objects |
| shall be obtained "as if" by calling the <code>address()</code> member |
| function on a copy of the allocator object of the appropriate |
| type.</ins> |
| |
| <ins>Finally, a copy of this argument shall be used by its container |
| object to determine the maximum number of objects of the container's |
| <code>value_type</code> the container may store at the same time. The |
| container member function <code>max_size()</code> obtains this number |
| from the value returned by a call to |
| <code>get_allocator().max_size()</code>.</ins> |
| |
| In all container types defined in this clause <ins>that are |
| parametrized on <code>Allocator</code></ins>, the member |
| <code>get_allocator()</code> returns a copy of the |
| <code>Allocator</code> object used to construct the |
| container.<sup>258)</sup> |
| </p> |
| <p> |
| New Footnote: This type may be different from <code>Allocator</code>: |
| it may be derived from <code>Allocator</code> via |
| <code>Allocator::rebind<U>::other</code> for the appropriate |
| type <code>U</code>. |
| </p> |
| </blockquote> |
| <p> |
| |
| The proposed wording seems cumbersome but I couldn't think of a better |
| way to describe the requirement that containers use their |
| <code>Allocator</code> to manage only objects (regardless of their |
| type) that persist over their lifetimes and not, for example, |
| temporaries created on the stack. That is, containers shouldn't be |
| required to call <code>Allocator::construct(Allocator::allocate(1), |
| elem)</code> just to construct a temporary copy of an element, or |
| <code>Allocator::destroy(Allocator::address(temp), 1)</code> to |
| destroy temporaries. |
| |
| </p> |
| |
| |
| <p><i>[ |
| Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| post Oxford: This would be rendered NAD Editorial by acceptance of |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>. |
| ]</i></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="582"></a>582. specialized algorithms and volatile storage</h3> |
| <p><b>Section:</b> 20.7.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| The specialized algorithms [lib.specialized.algorithms] are specified |
| as having the general effect of invoking the following expression: |
| |
| </p> |
| <pre> |
| new (static_cast<void*>(&*i)) |
| typename iterator_traits<ForwardIterator>::value_type (x) |
| |
| </pre> |
| <p> |
| |
| This expression is ill-formed when the type of the subexpression |
| <code>&*i</code> is some volatile-qualified <code>T</code>. |
| |
| </p> |
| |
| <p><i>[ |
| Batavia: Lack of support for proposed resolution but agree there is a |
| defect. Howard to look at wording. Concern that move semantics |
| properly expressed if iterator returns rvalue. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| In order to allow these algorithms to operate on volatile storage I |
| propose to change the expression so as to make it well-formed even for |
| pointers to volatile types. Specifically, I propose the following |
| changes to clauses 20 and 24. Change 20.6.4.1, p1 to read: |
| |
| </p> |
| <pre> |
| <i>Effects</i>: |
| |
| typedef typename iterator_traits<ForwardIterator>::pointer pointer; |
| typedef typename iterator_traits<ForwardIterator>::value_type value_type; |
| |
| for (; first != last; ++result, ++first) |
| new (static_cast<void*>(const_cast<pointer>(&*result)) |
| value_type (*first); |
| |
| </pre> |
| <p> |
| |
| change 20.6.4.2, p1 to read |
| |
| </p> |
| <pre> |
| <i>Effects</i>: |
| |
| typedef typename iterator_traits<ForwardIterator>::pointer pointer; |
| typedef typename iterator_traits<ForwardIterator>::value_type value_type; |
| |
| for (; first != last; ++result, ++first) |
| new (static_cast<void*>(const_cast<pointer>(&*first)) |
| value_type (*x); |
| |
| </pre> |
| <p> |
| |
| and change 20.6.4.3, p1 to read |
| |
| </p> |
| <pre> |
| <i>Effects</i>: |
| |
| typedef typename iterator_traits<ForwardIterator>::pointer pointer; |
| typedef typename iterator_traits<ForwardIterator>::value_type value_type; |
| |
| for (; n--; ++first) |
| new (static_cast<void*>(const_cast<pointer>(&*first)) |
| value_type (*x); |
| |
| </pre> |
| <p> |
| |
| In addition, since there is no partial specialization for |
| <code>iterator_traits<volatile T*></code> I propose to add one |
| to parallel such specialization for <const T*>. Specifically, I |
| propose to add the following text to the end of 24.3.1, p3: |
| |
| </p> |
| <p> |
| |
| and for pointers to volatile as |
| |
| </p> |
| <pre> |
| namespace std { |
| template<class T> struct iterator_traits<volatile T*> { |
| typedef ptrdiff_t difference_type; |
| typedef T value_type; |
| typedef volatile T* pointer; |
| typedef volatile T& reference; |
| typedef random_access_iterator_tag iterator_category; |
| }; |
| } |
| |
| </pre> |
| <p> |
| |
| Note that the change to <code>iterator_traits</code> isn't necessary |
| in order to implement the specialized algorithms in a way that allows |
| them to operate on volatile strorage. It is only necesassary in order |
| to specify their effects in terms of <code>iterator_traits</code> as |
| is done here. Implementations can (and some do) achieve the same |
| effect by means of function template overloading. |
| |
| </p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="585"></a>585. facet error reporting</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Date:</b> 2006-06-22</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| Section 22.2, paragraph 2 requires facet <code>get()</code> members |
| that take an <code>ios_base::iostate&</code> argument, |
| <code><i>err</i></code>, to ignore the (initial) value of the |
| argument, but to set it to <code>ios_base::failbit</code> in case of a |
| parse error. |
| |
| </p> |
| <p> |
| |
| We believe there are a few minor problems with this blanket |
| requirement in conjunction with the wording specific to each |
| <code>get()</code> member function. |
| |
| </p> |
| <p> |
| |
| First, besides <code>get()</code> there are other member functions |
| with a slightly different name (for example, |
| <code>get_date()</code>). It's not completely clear that the intent of |
| the paragraph is to include those as well, and at least one |
| implementation has interpreted the requirement literally. |
| |
| </p> |
| <p> |
| |
| Second, the requirement to "set the argument to |
| <code>ios_base::failbit</code> suggests that the functions are not |
| permitted to set it to any other value (such as |
| <code>ios_base::eofbit</code>, or even <code>ios_base::eofbit | |
| ios_base::failbit</code>). |
| |
| </p> |
| <p> |
| |
| However, 22.2.2.1.2, p5 (Stage 3 of <code>num_get</code> parsing) and |
| p6 (<code>bool</code> parsing) specifies that the <code>do_get</code> |
| functions perform <code><i>err</i> |= ios_base::eofbit</code>, which |
| contradicts the earlier requirement to ignore <i>err</i>'s initial |
| value. |
| |
| </p> |
| <p> |
| |
| 22.2.6.1.2, p1 (the Effects clause of the <code>money_get</code> |
| facet's <code>do_get</code> member functions) also specifies that |
| <code><i>err</i></code>'s initial value be used to compute the final |
| value by ORing it with either <code>ios_base::failbit</code> or |
| with<code>ios_base::eofbit | ios_base::failbit</code>. |
| |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| We believe the intent is for all facet member functions that take an |
| <code>ios_base::iostate&</code> argument to: |
| |
| </p> |
| <ul> |
| <li> |
| |
| ignore the initial value of the <code><i>err</i></code> argument, |
| |
| </li> |
| <li> |
| |
| reset <code><i>err</i></code> to <code>ios_base::goodbit</code> prior |
| to any further processing, |
| |
| </li> |
| <li> |
| |
| and set either <code>ios_base::eofbit</code>, or |
| <code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as |
| appropriate, in response to reaching the end-of-file or on parse |
| error, or both. |
| |
| </li> |
| </ul> |
| <p> |
| |
| To that effect we propose to change 22.2, p2 as follows: |
| |
| </p> |
| <p> |
| |
| The <i>put</i><del>()</del> members make no provision for error |
| reporting. (Any failures of the OutputIterator argument must be |
| extracted from the returned iterator.) <ins>Unless otherwise |
| specified, </ins>the <i>get</i><del>()</del> members <ins>that</ins> |
| take an <code>ios_base::iostate&</code> argument <del>whose value |
| they ignore, but set to ios_base::failbit in case of a parse |
| error.</del><ins>, <code><i>err</i></code>, start by evaluating |
| <code>err = ios_base::goodbit</code>, and may subsequently set |
| <i>err</i> to either <code>ios_base::eofbit</code>, or |
| <code>ios_base::failbit</code>, or <code>ios_base::eofbit | |
| ios_base::failbit</code> in response to reaching the end-of-file or in |
| case of a parse error, or both, respectively.</ins> |
| |
| </p> |
| |
| |
| <p><i>[ |
| Kona (2007): We need to change the proposed wording to clarify that the |
| phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc. |
| Proposed Disposition: Open |
| ]</i></p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3> |
| <p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2006-07-18</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The wording used for section 23.2.1 [lib.array] seems to be subtly |
| ambiguous about zero sized arrays (N==0). Specifically: |
| </p> |
| <p> |
| * "An instance of array<T, N> stores N elements of type T, so that |
| [...]" |
| </p> |
| <p> |
| Does this imply that a zero sized array object stores 0 elements, i.e. |
| that it cannot store any element of type T? The next point clarifies |
| the rationale behind this question, basically how to implement begin() |
| and end(): |
| </p> |
| <p> |
| * 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() == |
| end() == unique value." |
| </p> |
| <p> |
| What does "unique" mean in this context? Let's consider the following |
| possible implementations, all relying on a partial specialization: |
| </p> |
| <blockquote><pre>a) |
| template< typename T > |
| class array< T, 0 > { |
| |
| .... |
| |
| iterator begin() |
| { return iterator( reinterpret_cast< T * >( this ) ); } |
| .... |
| |
| }; |
| </pre></blockquote> |
| <p> |
| This has been used in boost, probably intending that the return value |
| had to be unique to the specific array object and that array couldn't |
| store any T. Note that, besides relying on a reinterpret_cast, has |
| (more than potential) alignment problems. |
| </p> |
| <blockquote><pre>b) |
| template< typename T > |
| class array< T, 0 > { |
| |
| T t; |
| |
| iterator begin() |
| { return iterator( &t ); } |
| .... |
| |
| }; |
| </pre></blockquote> |
| <p> |
| This provides a value which is unique to the object and to the type of |
| the array, but requires storing a T. Also, it would allow the user to |
| mistakenly provide an initializer list with one element. |
| </p> |
| <p> |
| A slight variant could be returning *the* null pointer of type T |
| </p> |
| <blockquote><pre> return static_cast<T*>(0); |
| </pre></blockquote> |
| <p> |
| In this case the value would be unique to the type array<T, 0> but not |
| to the objects (all objects of type array<T, 0> with the same value |
| for T would yield the same pointer value). |
| </p> |
| <p> |
| Furthermore this is inconsistent with what the standard requires from |
| allocation functions (see library issue 9). |
| </p> |
| <p> |
| c) same as above but with t being a static data member; again, the |
| value would be unique to the type, not to the object. |
| </p> |
| <p> |
| d) to avoid storing a T *directly* while disallowing the possibility |
| to use a one-element initializer list a non-aggregate nested class |
| could be defined |
| </p> |
| <blockquote><pre> struct holder { holder() {} T t; } h; |
| </pre></blockquote> |
| <p> |
| and then begin be defined as |
| </p> |
| <blockquote><pre> iterator begin() { return &h.t; } |
| </pre></blockquote> |
| <p> |
| But then, it's arguable whether the array stores a T or not. |
| Indirectly it does. |
| </p> |
| <p> |
| ----------------------------------------------------- |
| </p> |
| <p> |
| Now, on different issues: |
| </p> |
| <p> |
| * what's the effect of calling assign(T&) on a zero-sized array? There |
| seems to be only mention of front() and back(), in 23.2.1 [lib.array] |
| p4 (I would also suggest to move that bullet to section 23.2.1.5 |
| [lib.array.zero], for locality of reference) |
| </p> |
| <p> |
| * (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit |
| inconsistent with that of other sequences: that's not a problem in |
| itself, but compare it for instance with "A vector is a kind of |
| sequence that supports random access iterators"; though the intent is |
| obvious one might argue that the wording used for arrays doesn't tell |
| what an array is, and relies on the reader to infer that it is what |
| the <array> header defines. |
| </p> |
| <p> |
| * it would be desiderable to have a static const data member of type |
| std::size_t, with value N, for usage as integral constant expression |
| </p> |
| <p> |
| * section 23.1 [lib.container.requirements] seem not to consider |
| fixed-size containers at all, as it says: "[containers] control |
| allocation and deallocation of these objects [the contained objects] |
| through constructors, destructors, *insert and erase* operations" |
| </p> |
| <p> |
| * max_size() isn't specified: the result is obvious but, technically, |
| it relies on table 80: "size() of the largest possible container" |
| which, again, doesn't seem to consider fixed size containers |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| <p><i>[ |
| Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details |
| Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence |
| requirements? Alisdair will prepare a paper. Proposed Disposition: Open |
| ]</i></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3> |
| <p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In a private email, Daveed writes: |
| </p> |
| <blockquote> |
| <p> |
| I am not familiar with the C TR, but my guess is that the |
| class type approach still won't match a built-in type |
| approach because the notion of "promotion" cannot be |
| emulated by user-defined types. |
| </p> |
| <p> |
| Here is an example: |
| </p> |
| </blockquote> |
| <pre> |
| struct S { |
| S(_Decimal32 const&); // Converting constructor |
| }; |
| void f(S); |
| |
| void f(_Decimal64); |
| |
| void g(_Decimal32 d) { |
| f(d); |
| } |
| </pre> |
| |
| <blockquote> |
| <p> |
| If _Decimal32 is a built-in type, the call f(d) will likely |
| resolve to f(_Decimal64) because that requires only a |
| promotion, whereas f(S) requires a user-defined conversion. |
| </p> |
| <p> |
| If _Decimal32 is a class type, I think the call f(d) will be |
| ambiguous because both the conversion to _Decimal64 and the |
| conversion to S will be user-defined conversions with neither |
| better than the other. |
| </p> |
| </blockquote> |
| <p> |
| Robert comments: |
| </p> |
| <p> |
| In general, a library of arithmetic types cannot exactly emulate the |
| behavior of the intrinsic numeric types. There are several ways to tell |
| whether an implementation of the decimal types uses compiler |
| intrinisics or a library. For example: |
| </p> |
| <pre> _Decimal32 d1; |
| d1.operator+=(5); // If d1 is a builtin type, this won't compile. |
| </pre> |
| <p> |
| In preparing the decimal TR, we have three options: |
| </p> |
| <ol> |
| <li>require that the decimal types be class types</li> |
| <li>require that the decimal types be builtin types, like float and double</li> |
| <li>specify a library of class types, but allow enough implementor |
| latitude that a conforming implementation could instead provide builtin |
| types</li> |
| </ol> |
| <p> |
| We decided as a group to pursue option #3, but that approach implies |
| that implementations may not agree on the semantics of certain use |
| cases (first example, above), or on whether certain other cases are |
| well-formed (second example). Another potentially important problem is |
| that, under the present definition of POD, the decimal classes are not |
| POD types, but builtins will be. |
| </p> |
| <p>Note that neither example above implies any problems with respect to |
| C-to-C++ compatibility, since neither example can be expressed in C. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3> |
| <p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-15</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In c++std-lib-17205, Martin writes: |
| </p> |
| <blockquote><p>...was it a deliberate design choice to make narrowing |
| assignments ill-formed while permitting narrowing compound assignments? |
| For instance: |
| </p></blockquote> |
| <pre> decimal32 d32; |
| decimal64 d64; |
| |
| d32 = 64; // error |
| d32 += 64; // okay |
| </pre> |
| <p> |
| In c++std-lib-17229, Robert responds: |
| </p> |
| <blockquote><p>It is a vestige of an old idea that I forgot to remove |
| from the paper. Narrowing assignments should be permitted. The bug is |
| that the converting constructors that cause narrowing should not be |
| explicit. Thanks for pointing this out. |
| </p></blockquote> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| 1. In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions: |
| </p> |
| <pre> // <i>3.2.2.2 conversion from floating-point type:</i> |
| <del>explicit</del> decimal32(decimal64 <i>d64</i>); |
| <del>explicit</del> decimal32(decimal128 <i>d128</i>); |
| </pre> |
| <p> |
| 2. Do the same thing in "3.2.2.2. Conversion from floating-point type." |
| </p> |
| <p> |
| 3. In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion: |
| </p> |
| <pre> // <i>3.2.3.2 conversion from floating-point type:</i> |
| <del>explicit</del> decimal64(decimal128 <i>d128</i>); |
| </pre> |
| <p> |
| 4. Do the same thing in "3.2.3.2. Conversion from floating-point type." |
| </p> |
| |
| <p><i>[ |
| Redmond: We prefer explicit conversions for narrowing and implicit for widening. |
| ]</i></p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-05</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| This is based on N2134, where 21.3.1/2 states: |
| "... The Allocator object used shall be a copy of the Allocator object |
| passed to the basic_string object's constructor or, if the constructor does |
| not take an Allocator argument, a copy of a default-constructed Allocator |
| object." |
| </p> |
| <p> |
| Section 21.3.2/1 lists two constructors: |
| </p> |
| <blockquote><pre>basic_string(const basic_string<charT,traits,Allocator>& str ); |
| |
| basic_string(const basic_string<charT,traits,Allocator>& str , |
| size_type pos , size_type n = npos, |
| const Allocator& a = Allocator()); |
| </pre></blockquote> |
| <p> |
| and then says "In the first form, the Allocator value used is copied from |
| str.get_allocator().", which isn't an option according to 21.3.1. |
| </p> |
| <p><i>[ |
| Batavia: We need blanket statement to the effect of: |
| ]</i></p> |
| |
| |
| <ol> |
| <li>If an allocator is passed in, use it, or,</li> |
| <li>If a string is passed in, use its allocator.</li> |
| </ol> |
| <p><i>[ |
| Review constructors and functions that return a string; make sure we follow these |
| rules (substr, operator+, etc.). Howard to supply wording. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Bo adds: The new container constructor which takes only a <tt>size_type</tt> is not |
| consistent with 23.1 [container.requirements], p9 which says in part: |
| |
| <blockquote> |
| All other constructors for these container types take an |
| <tt>Allocator&</tt> argument (20.1.2), an allocator whose value type |
| is the same as the container's value type. A copy of this argument is |
| used for any memory allocation performed, by these constructors and by |
| all member functions, during the lifetime of each container object. |
| </blockquote> |
| ]</i></p> |
| |
| |
| <p><i>[ |
| post Bellevue: We re-confirm that the issue is real. Pablo will provide wording. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3> |
| <p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-30</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The <tt><array></tt> header is given under 23.2 [sequences]. |
| 23.2.1 [array]/paragraph 3 says: |
| </p> |
| <blockquote><p> |
| "Unless otherwise specified, all array operations are as described in |
| 23.1 [container.requirements]". |
| </p></blockquote> |
| <p> |
| However, array isn't mentioned at all in section 23.1 [container.requirements]. |
| In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear) |
| that std::array does not have in 23.2.1 [array]. |
| </p> |
| <p> |
| Also, Table 83 "Optional sequence operations" lists several operations that |
| std::array does have, but array isn't mentioned. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3> |
| <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#Ready">Ready</a> |
| <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| is there an issue opened for (0,3) as complex number with |
| the French local? With the English local, the above parses as an |
| imaginery complex number. With the French locale it parses as a |
| real complex number. |
| </p> |
| |
| <p> |
| Further notes/ideas from the lib-reflector, messages 17982-17984: |
| </p> |
| |
| <blockquote> |
| <p> |
| Add additional entries in num_punct to cover the complex separator (French would be ';'). |
| </p> |
| <p> |
| Insert a space before the comma, which should eliminate the ambiguity. |
| </p> |
| <p> |
| Solve the problem for ordered sequences in general, perhaps with a |
| dedicated facet. Then complex should use that solution. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| After much discussion, we agreed on the following: Add a footnote: |
| </p> |
| <p> |
| [In a locale in which comma is being used as a decimal point character, |
| inserting "showbase" into the output stream forces all outputs to show |
| an explicit decimal point character; then all inserted complex sequences |
| will extract unambiguously.] |
| </p> |
| <p> |
| And move this to READY status. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| Pre-Sophia Antipolis, Howard adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Changed "showbase" to "showpoint" and changed from Ready to Review. |
| </blockquote> |
| |
| <p><i>[ |
| Post-Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change. |
| In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready. We subsequently |
| voted the footnote into the WP with "showbase". |
| </p> |
| <p> |
| I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add a footnote to 26.3.6 [complex.ops] p16: |
| </p> |
| |
| <blockquote> |
| [In a locale in which comma is being used as a decimal point character, |
| inserting <tt>showpoint</tt> into the output stream forces all outputs to show |
| an explicit decimal point character; then all inserted complex sequences |
| will extract unambiguously.] |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="630"></a>630. arrays of valarray</h3> |
| <p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-28</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| Section 26.1 [numeric.requirements], p1 suggests that a |
| <code>valarray</code> specialization on a type <code>T</code> that |
| satisfies the requirements enumerated in the paragraph is itself a |
| valid type on which <code>valarray</code> may be instantiated |
| (Footnote 269 makes this clear). I.e., |
| <code>valarray<valarray<T> ></code> is valid as long as |
| <code>T</code> is valid. However, since implementations of |
| <code>valarray</code> are permitted to initialize storage allocated by |
| the class by invoking the default ctor of <code>T</code> followed by |
| the copy assignment operator, such implementations of |
| <code>valarray</code> wouldn't work with (perhaps user-defined) |
| specializations of <code>valarray</code> whose assignment operator had |
| undefined behavior when the size of its argument didn't match the size |
| of <code>*this</code>. By <i>"wouldn't work"</i> I mean that it would |
| be impossible to resize such an array of arrays by calling the |
| <code>resize()</code> member function on it if the function used the |
| copy assignment operator after constructing all elements using the |
| default ctor (e.g., by invoking <code>new value_type[N]</code>) to |
| obtain default-initialized storage) as it's permitted to do. |
| |
| </p> |
| <p> |
| |
| Stated more generally, the problem is that |
| <code>valarray<valarray<T> >::resize(size_t)</code> isn't |
| required or guaranteed to have well-defined semantics for every type |
| <code>T</code> that satisfies all requirements in |
| 26.1 [numeric.requirements]. |
| |
| </p> |
| <p> |
| |
| I believe this problem was introduced by the adoption of the |
| resolution outlined in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>, |
| <i>Assignment of valarrays</i>, from 1996. The copy assignment |
| operator of the original numerical array classes proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>, |
| as well as the one proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a> |
| (both from 1993), had well-defined semantics for arrays of unequal |
| size (the latter explicitly only when <code>*this</code> was empty; |
| assignment of non empty arrays of unequal size was a runtime error). |
| |
| </p> |
| <p> |
| |
| The justification for the change given in N0857 was the "loss of |
| performance [deemed] only significant for very simple operations on |
| small arrays or for architectures with very few registers." |
| |
| </p> |
| <p> |
| |
| Since tiny arrays on a limited subset of hardware architectures are |
| likely to be an exceedingly rare case (despite the continued |
| popularity of x86) I propose to revert the resolution and make the |
| behavior of all <code>valarray</code> assignment operators |
| well-defined even for non-conformal arrays (i.e., arrays of unequal |
| size). I have implemented this change and measured no significant |
| degradation in performance in the common case (non-empty arrays of |
| equal size). I have measured a 50% (and in some cases even greater) |
| speedup in the case of assignments to empty arrays versus calling |
| <code>resize()</code> first followed by an invocation of the copy |
| assignment operator. |
| |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| If no proposed wording by June meeting, this issue should be closed NAD. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| Change 26.5.2.2 [valarray.assign], p1 as follows: |
| |
| </p> |
| <blockquote> |
| <p> |
| <code> |
| |
| valarray<T>& operator=(const valarray<T>&<ins> x</ins>); |
| |
| </code> |
| </p> |
| <p> |
| |
| -1- Each element of the <code>*this</code> array is assigned the value |
| of the corresponding element of the argument array. <del>The |
| resulting behavior is undefined if </del><ins>When </ins>the length of |
| the argument array is not equal to the length of the *this |
| array<del>.</del><ins> resizes <code>*this</code> to make the two |
| arrays the same length, as if by calling |
| <code>resize(x.size())</code>, before performing the assignment.</ins> |
| |
| </p> |
| </blockquote> |
| <p> |
| |
| And add a new paragraph just below paragraph 1 with the following |
| text: |
| |
| </p> |
| <blockquote> |
| <p> |
| |
| <ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins> |
| |
| </p> |
| </blockquote> |
| <p> |
| |
| Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4: |
| |
| </p> |
| <blockquote> |
| <p> |
| |
| <ins>-?- When the length, <i><code>N</code></i> of the array referred |
| to by the argument is not equal to the length of <code>*this</code>, |
| the operator resizes <code>*this</code> to make the two arrays the |
| same length, as if by calling <code>resize(<i>N</i>)</code>, before |
| performing the assignment.</ins> |
| |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| pre-Sophia Antipolis, Martin adds the following compromise wording, but |
| prefers the original proposed resolution: |
| ]</i></p> |
| |
| |
| <p> |
| Change 26.5.2.2 [valarray.assign], p1 as follows: |
| </p> |
| |
| <blockquote> |
| <p> |
| -1- <i>Requires:</i> <tt>size() == 0 || size() == x.size()</tt>. |
| </p> |
| <p> |
| -2- <i>Effects:</i> If <tt>size() == 0</tt> calls <tt>x.resize(x.size())</tt> first. |
| Each element of the <tt>*this</tt> array is assigned the value of the |
| corresponding element of the argument array. |
| </p> |
| <p> |
| -3- <i>Postcondition:</i> <tt>size() == x.size()</tt>. |
| </p> |
| </blockquote> |
| |
| <p> |
| Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after |
| p4: |
| </p> |
| |
| <blockquote> |
| <p> |
| -?- When <tt>size() == 0</tt> and the length, <tt>N</tt> of the array referred to by |
| the argument is not equal to the length of <tt>*this</tt>, the operator |
| resizes <tt>*this</tt> to make the two arrays the same length, as if by |
| calling <tt>resize(N)</tt>, before performing the assignment. Otherwise, |
| when <tt>size() > 0</tt> and <tt>size() != N</tt>, the behavior is undefined. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><i>[ |
| Kona (2007): Gaby to propose wording for an alternative resolution in |
| which you can assign to a <tt>valarray</tt> of size 0, but not to any other |
| <tt>valarray</tt> whose size is unequal to the right hand side of the assignment. |
| ]</i></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3> |
| <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> James Kanze <b>Date:</b> 2007-01-31</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for |
| some functions. In particular, it says that: |
| </p> |
| |
| <blockquote><p> |
| [...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> |
| as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its |
| iterator arguments, it should work correctly in the construct <tt>if |
| (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>. |
| <tt>BinaryPredicate</tt> always takes the first iterator type as its |
| first argument, that is, in those cases when <tt>T <i>value</i></tt> is |
| part of the signature, it should work correctly in the context of <tt>if |
| (binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>. |
| </p></blockquote> |
| |
| <p> |
| In the description of <tt>upper_bound</tt> (25.3.3.2 [upper.bound]/2), however, the use is described as |
| "<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an |
| element of the sequence (a result of dereferencing |
| <tt>*<i>first</i></tt>). |
| </p> |
| |
| <p> |
| In the description of <tt>lexicographical_compare</tt>, we have both |
| "<tt>*<i>first1</i> < *<i>first2</i></tt>" and "<tt>*<i>first2</i> |
| < *<i>first1</i></tt>" (which presumably implies "<tt>comp( |
| *<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>, |
| *<i>first1</i> )</tt>". |
| </p> |
| |
| <p><i>[ |
| Toronto: Moved to Open. ConceptGCC seems to get <tt>lower_bound</tt> |
| and <tt>upper_bound</tt> to work withoutt these changes. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Logically, the <tt>BinaryPredicate</tt> is used as an ordering |
| relationship, with the semantics of "less than". Depending on the |
| function, it may be used to determine equality, or any of the inequality |
| relationships; doing this requires being able to use it with either |
| parameter first. I would thus suggest that the requirement be: |
| </p> |
| |
| <blockquote><p> |
| [...] <tt>BinaryPredicate</tt> always takes the first iterator |
| <tt>value_type</tt> as one of its arguments, it is unspecified which. If |
| an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its |
| argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its |
| iterator arguments, it should work correctly both in the construct |
| <tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and |
| <tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>. In |
| those cases when <tt>T <i>value</i></tt> is part of the signature, it |
| should work correctly in the context of <tt>if (binary_pred |
| (*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred |
| (<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two |
| types are not identical, and neither is convertable to the other, this |
| may require that the <tt>BinaryPredicate</tt> be a functional object |
| with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>] |
| </p></blockquote> |
| |
| <p> |
| Alternatively, one could specify an order for each function. IMHO, this |
| would be more work for the committee, more work for the implementors, |
| and of no real advantage for the user: some functions, such as |
| <tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both |
| functions, and it seems like a much easier rule to teach that both |
| functions are always required, rather than to have a complicated list of |
| when you only need one, and which one. |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="632"></a>632. Time complexity of size() for std::set</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Lionel B <b>Date:</b> 2007-02-01</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| A recent news group discussion: |
| </p> |
| <blockquote> |
| <p> |
| Anyone know if the Standard has anything to say about the time complexity |
| of size() for std::set? I need to access a set's size (/not/ to know if it is empty!) heavily |
| during an algorithm and was thus wondering whether I'd be better off |
| tracking the size "manually" or whether that'd be pointless. |
| </p> |
| <p> |
| That would be pointless. size() is O(1). |
| </p> |
| <p> |
| Nit: the standard says "should" have constant time. Implementations may take |
| license to do worse. I know that some do this for <tt>std::list<></tt> as a part of |
| some trade-off with other operation. |
| </p> |
| |
| <p> |
| I was aware of that, hence my reluctance to use size() for std::set. |
| </p> |
| <p> |
| However, this reason would not apply to <tt>std::set<></tt> as far as I can see. |
| </p> |
| <p> |
| Ok, I guess the only option is to try it and see... |
| </p> |
| </blockquote> |
| |
| <p> |
| If I have any recommendation to the C++ Standards Committee it is that |
| implementations must (not "should"!) document clearly[1], where known, the |
| time complexity of *all* container access operations. |
| </p> |
| <p> |
| [1] In my case (gcc 4.1.1) I can't swear that the time complexity of size() |
| for std::set is not documented... but if it is it's certainly well hidden |
| away. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| <p><i>[ |
| Kona (2007): This issue affects all the containers. We'd love to see a |
| paper dealing with the broad issue. We think that the complexity of the |
| <tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be |
| O(1). Alan has volunteered to provide wording. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Mandating O(1) size will not fly, too many implementations would be |
| invalidated. Alan to provide wording that toughens wording, but that |
| does not absolutely mandate O(1). |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-08</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The table of allocator requirements in 20.1.2 [allocator.requirements] describes |
| <tt>allocator::address</tt> as: |
| </p> |
| <blockquote><pre>a.address(r) |
| a.address(s) |
| </pre></blockquote> |
| <p> |
| where <tt>r</tt> and <tt>s</tt> are described as: |
| </p> |
| <blockquote><p> |
| a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>. |
| </p></blockquote> |
| |
| <p> |
| and <tt>p</tt> is |
| </p> |
| |
| <blockquote><p> |
| a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>, |
| where <tt>a1 == a</tt> |
| </p></blockquote> |
| |
| <p> |
| This all implies that to get the address of some value of type <tt>T</tt> that |
| value must have been allocated by this allocator or a copy of it. |
| </p> |
| |
| <p> |
| However sometimes container code needs to compare the address of an external value of |
| type <tt>T</tt> with an internal value. For example <tt>list::remove(const T& t)</tt> |
| may want to compare the address of the external value <tt>t</tt> with that of a value |
| stored within the list. Similarly <tt>vector</tt> or <tt>deque insert</tt> may |
| want to make similar comparisons (to check for self-referencing calls). |
| </p> |
| |
| <p> |
| Mandating that <tt>allocator::address</tt> can only be called for values which the |
| allocator allocated seems overly restrictive. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 20.1.2 [allocator.requirements]: |
| </p> |
| |
| <blockquote> |
| <p> |
| <tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>. |
| </p> |
| <p> |
| <tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the |
| expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| post Oxford: This would be rendered NAD Editorial by acceptance of |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Kona (2007): This issue is section 8 of N2387. There was some discussion of it but |
| no resolution to this issue was recorded. Moved to Open. |
| ]</i></p> |
| |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="644"></a>644. Possible typos in 'function' description</h3> |
| <p><b>Section:</b> X [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| X [func.wrap.func.undef] |
| </p> |
| <p> |
| The note in paragraph 2 refers to 'undefined void operators', while the |
| section declares a pair of operators returning bool. |
| </p> |
| |
| <p><i>[ |
| Post-Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Changed from Pending WP to Open. This issue was voted to WP at the same time the operators were |
| changed from private to deleted. The two issues stepped on each other. What do we want the return |
| type of these deleted functions to be? |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 20.6.15.2 [func.wrap.func] |
| </p> |
| |
| <blockquote><pre>... |
| private: |
| // X [func.wrap.func.undef], undefined operators: |
| template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&); |
| template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&); |
| }; |
| </pre></blockquote> |
| |
| <p> |
| Change X [func.wrap.func.undef] |
| </p> |
| |
| <blockquote><pre>template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&); |
| template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&); |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="659"></a>659. istreambuf_iterator should have an operator->()</h3> |
| <p><b>Section:</b> 24.5.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-03-25</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Greg Herlihy has clearly demonstrated that a user defined input |
| iterator should have an operator->(), even if its |
| value type is a built-in type (comp.std.c++, "Re: Should any iterator |
| have an operator->() in C++0x?", March 2007). And as Howard |
| Hinnant remarked in the same thread that the input iterator |
| <tt>istreambuf_iterator</tt> doesn't have one, this must be a |
| defect! |
| </p> |
| <p> |
| Based on Greg's example, the following code demonstrates the issue: |
| </p><pre> #include <iostream> |
| #include <fstream> |
| #include <streambuf> |
| |
| typedef char C; |
| int main () |
| { |
| std::ifstream s("filename", std::ios::in); |
| std::istreambuf_iterator<char> i(s); |
| |
| (*i).~C(); // This is well-formed... |
| i->~C(); // ... so this should be supported! |
| } |
| </pre> |
| |
| <p> |
| Of course, operator-> is also needed when the value_type of |
| istreambuf_iterator is a class. |
| </p> |
| <p> |
| The operator-> could be implemented in various ways. For instance, |
| by storing the current value inside the iterator, and returning its |
| address. Or by returning a proxy, like operator_arrow_proxy, from |
| <a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a> |
| </p> |
| <p> |
| I hope that the resolution of this issue will contribute to getting a |
| clear and consistent definition of iterator concepts. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add to the synopsis in 24.5.3 [istreambuf.iterator]: |
| </p> |
| |
| <blockquote><pre>charT operator*() const; |
| <ins>pointer operator->() const;</ins> |
| istreambuf_iterator<charT,traits>& operator++(); |
| </pre></blockquote> |
| |
| <p> |
| Change 24.5.3 [istreambuf.iterator], p1: |
| </p> |
| |
| <blockquote><p> |
| The class template <tt>istreambuf_iterator</tt> reads successive |
| characters from the <tt>streambuf</tt> for which it was constructed. |
| <tt>operator*</tt> provides access to the current input character, if |
| any. <ins><tt>operator-></tt> may return a proxy.</ins> Each time |
| <tt>operator++</tt> is evaluated, the iterator advances to the next |
| input character. If the end of stream is reached |
| (<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the |
| iterator becomes equal to the end of stream iterator value. The default |
| constructor <tt>istreambuf_iterator()</tt> and the constructor |
| <tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator |
| object suitable for use as an end-of-range. |
| </p></blockquote> |
| |
| |
| |
| <p><i>[ |
| Kona (2007): The proposed resolution is inconsistent because the return |
| type of <tt>istreambuf_iterator::operator->()</tt> is specified to be <tt>pointer</tt>, |
| but the proposed text also states that "<tt>operator-></tt> may return a proxy." |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Niels Dekker (mailed to Howard Hinnant): |
| ]</i></p> |
| |
| <blockquote> |
| <p> |
| The proposed resolution does |
| not seem inconsistent to me. <tt>istreambuf_iterator::operator->()</tt> should |
| have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type |
| may in fact be a proxy. |
| </p> |
| <p> |
| AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt> |
| unspecified for some iterator categories") implies that for any iterator |
| class <tt>Iter</tt>, the return type of <tt>operator->()</tt> is <tt>Iter::pointer</tt>, by |
| definition. I don't think <tt>Iter::pointer</tt> needs to be a raw pointer. |
| </p> |
| <p> |
| Still I wouldn't mind if the text "<tt>operator-></tt> may return a proxy" would |
| be removed from the resolution. I think it's up to the library |
| implementation, how to implement <tt>istreambuf_iterator::operator->()</tt>. As |
| longs as it behaves as expected: <tt>i->m</tt> should have the same effect as |
| <tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i->~C()</tt>. The main issue |
| is just: <tt>istreambuf_iterator</tt> should have an <tt>operator->()</tt>! |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3> |
| <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| 22.2.6.1.2 [locale.money.get.virtuals], para 1 says: |
| </p> |
| |
| <blockquote><p> |
| The result is returned as an integral value |
| stored in <tt>units</tt> or as a sequence of digits possibly preceded by a |
| minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range |
| from '0' through '9', inclusive) stored in <tt>digits</tt>. |
| </p></blockquote> |
| |
| <p> |
| The following |
| objection has been raised: |
| </p> |
| |
| <blockquote><p> |
| Some implementations interpret this to mean that a facet derived from |
| <tt>ctype<wchar_t></tt> can provide its own member <tt>do_widen(char)</tt> |
| which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the |
| <tt>'@'</tt> symbol will appear in the resulting sequence of digits. Other |
| implementations have assumed that one or more places in the standard permit the |
| implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign. Are |
| both interpretations permissible, or only one? |
| </p></blockquote> |
| |
| <p> |
| [Plum ref _222612Y14] |
| </p> |
| |
| <p> |
| Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a |
| parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33] |
| </p> |
| |
| <p><i>[ |
| Kona (2007): Bill and Dietmar to provide proposed wording. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| post Bellevue: Bill adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>. |
| The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt> |
| which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>; |
| the widened characters are not relevant to the parsing of the subject string. |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3> |
| <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| 22.2.6.1.2 [locale.money.get.virtuals], para 3 says: |
| </p> |
| |
| <blockquote><p> |
| If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is |
| optional, and if no sign is detected, the result is given the sign |
| that corresponds to the source of the empty string. |
| </p></blockquote> |
| |
| <p> |
| The following |
| objection has been raised: |
| </p> |
| |
| <blockquote><p> |
| A <tt>negative_sign</tt> of "" means "there is no |
| way to write a negative sign" not "any null sequence is a negative |
| sign, so it's always there when you look for it". |
| </p></blockquote> |
| |
| <p> |
| [Plum ref _222612Y32] |
| </p> |
| |
| <p><i>[ |
| Kona (2007): Bill to provide proposed wording and interpretation of existing wording. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3> |
| <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| 22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says: |
| </p> |
| |
| <blockquote><p> |
| If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>, |
| or if both strings are empty, the result is given a positive sign. |
| </p></blockquote> |
| |
| <p> |
| One interpretation is that an input sequence must match either the |
| positive pattern or the negative pattern, and then in either event it |
| is interpreted as positive. The following objections has been raised: |
| </p> |
| |
| <blockquote><p> |
| The input can successfully match only a positive sign, so the negative |
| pattern is an unsuccessful match. |
| </p></blockquote> |
| |
| <p> |
| [Plum ref _222612Y34, 222612Y51b] |
| </p> |
| |
| <p><i>[ |
| Bill to provide proposed wording and interpretation of existing wording. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3> |
| <p><b>Section:</b> 22.2.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a></p> |
| <p><b>Discussion:</b></p> |
| |
| |
| <p> |
| 22.2.6.3 [locale.moneypunct], para 2 says: |
| </p> |
| |
| <blockquote><p> |
| The value <tt>space</tt> indicates that at least one space is required at |
| that position. |
| </p></blockquote> |
| |
| <p> |
| The following objection has been raised: |
| </p> |
| |
| <blockquote><p> |
| Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.) |
| </p></blockquote> |
| |
| <p> |
| [Plum ref _22263Y22] |
| </p> |
| |
| <p><i>[ |
| Kona (2007): Bill to provide proposed wording. We agree that C++03 is |
| ambiguous, and that we want C++0X to say "space" means 0 or more |
| whitespace characters on input. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="671"></a>671. precision of hexfloat</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> John Salmon <b>Date:</b> 2007-04-20</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| I am trying to understand how TR1 supports hex float (%a) output. |
| </p> |
| <p> |
| As far as I can tell, it does so via the following: |
| </p> |
| <p> |
| 8.15 Additions to header <locale> [tr.c99.locale] |
| </p> |
| <p> |
| In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after |
| the line: |
| floatfield == ios_base::scientific %E |
| </p> |
| <p> |
| add the two lines: |
| </p> |
| <blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a |
| floatfield == ios_base::fixed | ios_base::scientific %A 2 |
| </pre></blockquote> |
| <p> |
| [Note: The additional requirements on print and scan functions, later |
| in this clause, ensure that the print functions generate hexadecimal |
| floating-point fields with a %a or %A conversion specifier, and that |
| the scan functions match hexadecimal floating-point fields with a %g |
| conversion specifier. end note] |
| </p> |
| <p> |
| Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find: |
| </p> |
| <p> |
| For conversion from a floating-point type, if (flags & fixed) != 0 or |
| if str.precision() > 0, then str.precision() is specified in the |
| conversion specification. |
| </p> |
| <p> |
| This would seem to imply that when floatfield == fixed|scientific, the |
| precision of the conversion specifier is to be taken from |
| str.precision(). Is this really what's intended? I sincerely hope |
| that I'm either missing something or this is an oversight. Please |
| tell me that the committee did not intend to mandate that hex floats |
| (and doubles) should by default be printed as if by %.6a. |
| </p> |
| |
| <p><i>[ |
| Howard: I think the fundamental issue we overlooked was that with %f, |
| %e, %g, the default precision was always 6. With %a the default |
| precision is not 6, it is infinity. So for the first time, we need to |
| distinguish between the default value of precision, and the precision |
| value 6. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| <p><i>[ |
| Kona (2007): Robert volunteers to propose wording. |
| ]</i></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="675"></a>675. Move assignment of containers</h3> |
| <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#Review">Review</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| James Hopkin pointed out to me that if <tt>vector<T></tt> move assignment is O(1) |
| (just a <tt>swap</tt>) then containers such as <tt>vector<shared_ptr<ostream>></tt> might have |
| the wrong semantics under move assignment when the source is not truly an rvalue, but a |
| moved-from lvalue (destructors could run late). |
| </p> |
| |
| <blockquote><pre><tt>vector<shared_ptr<ostream>></tt> v1; |
| <tt>vector<shared_ptr<ostream>></tt> v2; |
| ... |
| v1 = v2; // #1 |
| v1 = std::move(v2); // #2 |
| </pre></blockquote> |
| |
| <p> |
| Move semantics means not caring what happens to the source (<tt>v2</tt> in this example). |
| It doesn't mean not caring what happens to the target (<tt>v1</tt>). In the above example |
| both assignments should have the same effect on <tt>v1</tt>. Any non-shared <tt>ostream</tt>'s |
| <tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing |
| copy assignment or move assignment. |
| </p> |
| |
| <p> |
| This implies that the semantics of move assignment of a generic container should be |
| <tt>clear, swap</tt> instead of just swap. An alternative which could achieve the same |
| effect would be to move assign each element. In either case, the complexity of move |
| assignment needs to be relaxed to <tt>O(v1.size())</tt>. |
| </p> |
| |
| <p> |
| The performance hit of this change is not nearly as drastic as it sounds. |
| In practice, the target of a move assignment has always just been move constructed |
| or move assigned <i>from</i>. Therefore under <tt>clear, swap</tt> semantics (in |
| this common use case) we are still achieving O(1) complexity. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 23.1 [container.requirements]: |
| </p> |
| |
| <blockquote> |
| <table border="1"> |
| <caption>Table 89: Container requirements</caption> |
| <tbody><tr> |
| <th>expression</th><th>return type</th><th>operational semantics</th> |
| <th>assertion/note pre/post-condition</th><th>complexity</th> |
| </tr> |
| <tr> |
| <td><tt>a = rv;</tt></td><td><tt>X&</tt></td> |
| <td>All existing elements of <tt>a</tt> are either move assigned or destructed</td> |
| <td><tt>a</tt> shall be equal to the |
| value that <tt>rv</tt> had |
| before this construction |
| </td> |
| <td><del>(Note C)</del> <ins>linear</ins></td> |
| </tr> |
| </tbody></table> |
| |
| <p> |
| Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and |
| <tt>lexicographical_compare()</tt> are defined in clause 25. Those |
| entries marked "(Note A)" should have constant complexity. Those entries |
| marked "(Note B)" have constant complexity unless |
| <tt>allocator_propagate_never<X::allocator_type>::value</tt> is |
| <tt>true</tt>, in which case they have linear complexity. |
| <del>Those entries |
| marked "(Note C)" have constant complexity if <tt>a.get_allocator() == |
| rv.get_allocator()</tt> or if either |
| <tt>allocator_propagate_on_move_assignment<X::allocator_type>::value</tt> |
| is <tt>true</tt> or |
| <tt>allocator_propagate_on_copy_assignment<X::allocator_type>::value</tt> |
| is <tt>true</tt> and linear complexity otherwise.</del> |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><i>[ |
| post Bellevue Howard adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| This issue was voted to WP in Bellevue, but accidently got stepped on by |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a> |
| which was voted to WP simulataneously. Moving back to Open for the purpose of getting |
| the wording right. The intent of this issue and N2525 are not in conflict. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| post Sophia Antipolis Howard updated proposed wording: |
| ]</i></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="676"></a>676. Moving the unordered containers</h3> |
| <p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Move semantics are missing from the <tt>unordered</tt> containers. The proposed |
| resolution below adds move-support consistent with |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a> |
| and the current working draft. |
| </p> |
| |
| <p> |
| The current proposed resolution simply lists the requirements for each function. |
| These might better be hoisted into the requirements table for unordered associative containers. |
| Futhermore a mild reorganization of the container requirements could well be in order. |
| This defect report is purposefully ignoring these larger issues and just focusing |
| on getting the unordered containers "moved". |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| Add to 23.4 [unord]: |
| </p> |
| |
| <blockquote><pre>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, |
| unordered_map<Key, T, Hash, Pred, Alloc>& y); |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, |
| unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins> |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, |
| unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins> |
| |
| template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, |
| unordered_multimap<Key, T, Hash, Pred, Alloc>& y); |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, |
| unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins> |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, |
| unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins> |
| |
| ... |
| |
| template <class Value, class Hash, class Pred, class Alloc> |
| void swap(unordered_set<Value, Hash, Pred, Alloc>& x, |
| unordered_set<Value, Hash, Pred, Alloc>& y); |
| |
| <ins>template <class Value, class Hash, class Pred, class Alloc> |
| void swap(unordered_set<Value, Hash, Pred, Alloc>& x, |
| unordered_set<Value, Hash, Pred, Alloc>&& y);</ins> |
| |
| <ins>template <class Value, class Hash, class Pred, class Alloc> |
| void swap(unordered_set<Value, Hash, Pred, Alloc>&& x, |
| unordered_set<Value, Hash, Pred, Alloc>& y);</ins> |
| |
| template <class Value, class Hash, class Pred, class Alloc> |
| void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, |
| unordered_multiset<Value, Hash, Pred, Alloc>& y); |
| |
| <ins>template <class Value, class Hash, class Pred, class Alloc> |
| void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x, |
| unordered_multiset<Value, Hash, Pred, Alloc>&& y);</ins> |
| |
| <ins>template <class Value, class Hash, class Pred, class Alloc> |
| void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x, |
| unordered_multiset<Value, Hash, Pred, Alloc>& y);</ins> |
| </pre></blockquote> |
| |
| <p><b><tt>unordered_map</tt></b></p> |
| |
| <p> |
| Change 23.4.1 [unord.map]: |
| </p> |
| |
| <blockquote><pre>class unordered_map |
| { |
| ... |
| unordered_map(const unordered_map&); |
| <ins>unordered_map(unordered_map&&);</ins> |
| ~unordered_map(); |
| unordered_map& operator=(const unordered_map&); |
| <ins>unordered_map& operator=(unordered_map&&);</ins> |
| ... |
| // modifiers |
| <del>std::</del>pair<iterator, bool> insert(const value_type& obj); |
| <ins>template <class P> pair<iterator, bool> insert(P&& obj);</ins> |
| iterator insert(iterator hint, const value_type& obj); |
| <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins> |
| const_iterator insert(const_iterator hint, const value_type& obj); |
| <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins> |
| ... |
| void swap(unordered_map&<ins>&</ins>); |
| ... |
| mapped_type& operator[](const key_type& k); |
| <ins>mapped_type& operator[](key_type&& k);</ins> |
| ... |
| }; |
| |
| template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, |
| unordered_map<Key, T, Hash, Pred, Alloc>& y); |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, |
| unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins> |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, |
| unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins> |
| </pre></blockquote> |
| |
| <p> |
| Add to 23.4.1.1 [unord.map.cnstr]: |
| </p> |
| |
| <blockquote> |
| <pre>template <class InputIterator> |
| unordered_map(InputIterator f, InputIterator l, |
| size_type n = <i>implementation-defined</i>, |
| const hasher& hf = hasher(), |
| const key_equal& eql = key_equal(), |
| const allocator_type& a = allocator_type()); |
| </pre> |
| |
| <blockquote><p> |
| <ins> |
| <i>Requires:</i> If the iterator's dereference operator returns an |
| lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>, |
| then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be |
| <tt>CopyConstructible</tt>. |
| </ins> |
| </p></blockquote> |
| </blockquote> |
| |
| <p> |
| Add to 23.4.1.2 [unord.map.elem]: |
| </p> |
| |
| <blockquote> |
| |
| <pre>mapped_type& operator[](const key_type& k);</pre> |
| |
| <blockquote> |
| <p>...</p> |
| <p><ins> |
| <i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt> |
| and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>. |
| </ins></p> |
| </blockquote> |
| |
| <pre><ins>mapped_type& operator[](key_type&& k);</ins></pre> |
| |
| <blockquote> |
| <p><ins> |
| <i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an |
| element whose key is equivalent to <tt>k</tt> , inserts the value |
| <tt>std::pair<const key_type, mapped_type>(std::move(k), mapped_type())</tt>. |
| </ins></p> |
| |
| <p><ins> |
| <i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>. |
| </ins></p> |
| |
| <p><ins> |
| <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the |
| (unique) element whose key is equivalent to <tt>k</tt>. |
| </ins></p> |
| |
| </blockquote> |
| |
| </blockquote> |
| |
| <p> |
| Add new section [unord.map.modifiers]: |
| </p> |
| |
| <blockquote> |
| <pre><ins>pair<iterator, bool> insert(const value_type& x);</ins> |
| <ins>template <class P> pair<iterator, bool> insert(P&& x);</ins> |
| <ins>iterator insert(iterator hint, const value_type& x);</ins> |
| <ins>template <class P> iterator insert(iterator hint, P&& x);</ins> |
| <ins>const_iterator insert(const_iterator hint, const value_type& x);</ins> |
| <ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins> |
| <ins>template <class InputIterator> |
| void insert(InputIterator first, InputIterator last);</ins> |
| </pre> |
| |
| <blockquote> |
| <p><ins> |
| <i>Requires:</i> Those signatures taking a <tt>const value_type&</tt> parameter |
| requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be |
| <tt>CopyConstructible</tt>. |
| </ins></p> |
| |
| <p><ins> |
| <tt>P</tt> shall be convertible to <tt>value_type</tt>. |
| If <tt>P</tt> is instantiated as a reference |
| type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt> |
| is considered to be an rvalue as it is converted to <tt>value_type</tt> |
| and inserted into the <tt>unordered_map</tt>. Specifically, in such |
| cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or |
| <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically |
| requires it (e.g. if <tt>P</tt> is a <tt>tuple<const key_type, |
| mapped_type></tt>, then <tt>key_type</tt> must be |
| <tt>CopyConstructible</tt>). |
| </ins></p> |
| |
| <p><ins> |
| The signature taking <tt>InputIterator</tt> |
| parameters requires <tt>CopyConstructible</tt> of both |
| <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced |
| <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue |
| <tt>value_type</tt>. |
| </ins></p> |
| |
| </blockquote> |
| |
| </blockquote> |
| |
| <p> |
| Add to 23.4.1.3 [unord.map.swap]: |
| </p> |
| |
| <blockquote> |
| <pre>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, |
| unordered_map<Key, T, Hash, Pred, Alloc>& y); |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x, |
| unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins> |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x, |
| unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins> |
| </pre> |
| </blockquote> |
| |
| <p><b><tt>unordered_multimap</tt></b></p> |
| |
| <p> |
| Change 23.4.2 [unord.multimap]: |
| </p> |
| |
| <blockquote><pre>class unordered_multimap |
| { |
| ... |
| unordered_multimap(const unordered_multimap&); |
| <ins>unordered_multimap(unordered_multimap&&);</ins> |
| ~unordered_multimap(); |
| unordered_multimap& operator=(const unordered_multimap&); |
| <ins>unordered_multimap& operator=(unordered_multimap&&);</ins> |
| ... |
| // modifiers |
| iterator insert(const value_type& obj); |
| <ins>template <class P> iterator insert(P&& obj);</ins> |
| iterator insert(iterator hint, const value_type& obj); |
| <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins> |
| const_iterator insert(const_iterator hint, const value_type& obj); |
| <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins> |
| ... |
| void swap(unordered_multimap&<ins>&</ins>); |
| ... |
| }; |
| |
| template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, |
| unordered_multimap<Key, T, Hash, Pred, Alloc>& y); |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, |
| unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins> |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, |
| unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins> |
| </pre></blockquote> |
| |
| <p> |
| Add to 23.4.2.1 [unord.multimap.cnstr]: |
| </p> |
| |
| <blockquote> |
| <pre>template <class InputIterator> |
| unordered_multimap(InputIterator f, InputIterator l, |
| size_type n = <i>implementation-defined</i>, |
| const hasher& hf = hasher(), |
| const key_equal& eql = key_equal(), |
| const allocator_type& a = allocator_type()); |
| </pre> |
| |
| <blockquote><p> |
| <ins> |
| <i>Requires:</i> If the iterator's dereference operator returns an |
| lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>, |
| then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be |
| <tt>CopyConstructible</tt>. |
| </ins> |
| </p></blockquote> |
| </blockquote> |
| |
| <p> |
| Add new section [unord.multimap.modifiers]: |
| </p> |
| |
| <blockquote> |
| <pre><ins>iterator insert(const value_type& x);</ins> |
| <ins>template <class P> iterator insert(P&& x);</ins> |
| <ins>iterator insert(iterator hint, const value_type& x);</ins> |
| <ins>template <class P> iterator insert(iterator hint, P&& x);</ins> |
| <ins>const_iterator insert(const_iterator hint, const value_type& x);</ins> |
| <ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins> |
| <ins>template <class InputIterator> |
| void insert(InputIterator first, InputIterator last);</ins> |
| </pre> |
| |
| <blockquote> |
| <p><ins> |
| <i>Requires:</i> Those signatures taking a <tt>const value_type&</tt> parameter |
| requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be |
| <tt>CopyConstructible</tt>. |
| </ins></p> |
| |
| <p><ins> |
| <tt>P</tt> shall be convertible to <tt>value_type</tt>. |
| If <tt>P</tt> is instantiated as a reference |
| type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt> |
| is considered to be an rvalue as it is converted to <tt>value_type</tt> |
| and inserted into the <tt>unordered_multimap</tt>. Specifically, in such |
| cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or |
| <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically |
| requires it (e.g. if <tt>P</tt> is a <tt>tuple<const key_type, |
| mapped_type></tt>, then <tt>key_type</tt> must be |
| <tt>CopyConstructible</tt>). |
| </ins></p> |
| |
| <p><ins> |
| The signature taking <tt>InputIterator</tt> |
| parameters requires <tt>CopyConstructible</tt> of both |
| <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced |
| <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue |
| <tt>value_type</tt>. |
| </ins></p> |
| </blockquote> |
| |
| </blockquote> |
| |
| <p> |
| Add to 23.4.2.2 [unord.multimap.swap]: |
| </p> |
| |
| <blockquote> |
| <pre>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, |
| unordered_multimap<Key, T, Hash, Pred, Alloc>& y); |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x, |
| unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins> |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x, |
| unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins> |
| </pre> |
| </blockquote> |
| |
| <p><b><tt>unordered_set</tt></b></p> |
| |
| <p> |
| Change 23.4.3 [unord.set]: |
| </p> |
| |
| <blockquote><pre>class unordered_set |
| { |
| ... |
| unordered_set(const unordered_set&); |
| <ins>unordered_set(unordered_set&&);</ins> |
| ~unordered_set(); |
| unordered_set& operator=(const unordered_set&); |
| <ins>unordered_set& operator=(unordered_set&&);</ins> |
| ... |
| // modifiers |
| <del>std::</del>pair<iterator, bool> insert(const value_type& obj); |
| <ins>pair<iterator, bool> insert(value_type&& obj);</ins> |
| iterator insert(iterator hint, const value_type& obj); |
| <ins>iterator insert(iterator hint, value_type&& obj);</ins> |
| const_iterator insert(const_iterator hint, const value_type& obj); |
| <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins> |
| ... |
| void swap(unordered_set&<ins>&</ins>); |
| ... |
| }; |
| |
| template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, |
| unordered_set<Key, T, Hash, Pred, Alloc>& y); |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, |
| unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins> |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, |
| unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins> |
| </pre></blockquote> |
| |
| <p> |
| Add to 23.4.3.1 [unord.set.cnstr]: |
| </p> |
| |
| <blockquote> |
| <pre>template <class InputIterator> |
| unordered_set(InputIterator f, InputIterator l, |
| size_type n = <i>implementation-defined</i>, |
| const hasher& hf = hasher(), |
| const key_equal& eql = key_equal(), |
| const allocator_type& a = allocator_type()); |
| </pre> |
| |
| <blockquote><p> |
| <ins> |
| <i>Requires:</i> If the iterator's dereference operator returns an |
| lvalue or a const rvalue <tt>value_type</tt>, then the |
| <tt>value_type</tt> shall be <tt>CopyConstructible</tt>. |
| </ins> |
| </p></blockquote> |
| </blockquote> |
| |
| <p> |
| Add new section [unord.set.modifiers]: |
| </p> |
| |
| <blockquote> |
| <pre><ins>pair<iterator, bool> insert(const value_type& x);</ins> |
| <ins>pair<iterator, bool> insert(value_type&& x);</ins> |
| <ins>iterator insert(iterator hint, const value_type& x);</ins> |
| <ins>iterator insert(iterator hint, value_type&& x);</ins> |
| <ins>const_iterator insert(const_iterator hint, const value_type& x);</ins> |
| <ins>const_iterator insert(const_iterator hint, value_type&& x);</ins> |
| <ins>template <class InputIterator> |
| void insert(InputIterator first, InputIterator last);</ins> |
| </pre> |
| |
| <blockquote> |
| |
| <p><ins> |
| <i>Requires:</i> Those signatures taking a <tt>const |
| value_type&</tt> parameter requires the <tt>value_type</tt> to |
| be <tt>CopyConstructible</tt>. |
| </ins></p> |
| |
| <p><ins> |
| The signature taking <tt>InputIterator</tt> parameters requires |
| <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced |
| <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue |
| <tt>value_type</tt>. |
| </ins></p> |
| |
| </blockquote> |
| |
| </blockquote> |
| |
| <p> |
| Add to 23.4.3.2 [unord.set.swap]: |
| </p> |
| |
| <blockquote> |
| <pre>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, |
| unordered_set<Key, T, Hash, Pred, Alloc>& y); |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x, |
| unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins> |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x, |
| unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins> |
| </pre> |
| </blockquote> |
| |
| <p><b><tt>unordered_multiset</tt></b></p> |
| |
| <p> |
| Change 23.4.4 [unord.multiset]: |
| </p> |
| |
| <blockquote><pre>class unordered_multiset |
| { |
| ... |
| unordered_multiset(const unordered_multiset&); |
| <ins>unordered_multiset(unordered_multiset&&);</ins> |
| ~unordered_multiset(); |
| unordered_multiset& operator=(const unordered_multiset&); |
| <ins>unordered_multiset& operator=(unordered_multiset&&);</ins> |
| ... |
| // modifiers |
| iterator insert(const value_type& obj); |
| <ins>iterator insert(value_type&& obj);</ins> |
| iterator insert(iterator hint, const value_type& obj); |
| <ins>iterator insert(iterator hint, value_type&& obj);</ins> |
| const_iterator insert(const_iterator hint, const value_type& obj); |
| <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins> |
| ... |
| void swap(unordered_multiset&<ins>&</ins>); |
| ... |
| }; |
| |
| template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, |
| unordered_multiset<Key, T, Hash, Pred, Alloc>& y); |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, |
| unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins> |
| |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, |
| unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins> |
| </pre></blockquote> |
| |
| <p> |
| Add to 23.4.4.1 [unord.multiset.cnstr]: |
| </p> |
| |
| <blockquote> |
| <pre>template <class InputIterator> |
| unordered_multiset(InputIterator f, InputIterator l, |
| size_type n = <i>implementation-defined</i>, |
| const hasher& hf = hasher(), |
| const key_equal& eql = key_equal(), |
| const allocator_type& a = allocator_type()); |
| </pre> |
| |
| <blockquote><p> |
| <ins> |
| <i>Requires:</i> If the iterator's dereference operator returns an |
| lvalue or a const rvalue <tt>value_type</tt>, then the |
| <tt>value_type</tt> shall be <tt>CopyConstructible</tt>. |
| </ins> |
| </p></blockquote> |
| </blockquote> |
| |
| <p> |
| Add new section [unord.multiset.modifiers]: |
| </p> |
| |
| <blockquote> |
| <pre><ins>iterator insert(const value_type& x);</ins> |
| <ins>iterator insert(value_type&& x);</ins> |
| <ins>iterator insert(iterator hint, const value_type& x);</ins> |
| <ins>iterator insert(iterator hint, value_type&& x);</ins> |
| <ins>const_iterator insert(const_iterator hint, const value_type& x);</ins> |
| <ins>const_iterator insert(const_iterator hint, value_type&& x);</ins> |
| <ins>template <class InputIterator> |
| void insert(InputIterator first, InputIterator last);</ins> |
| </pre> |
| |
| <blockquote> |
| |
| <p><ins> |
| <i>Requires:</i> Those signatures taking a <tt>const |
| value_type&</tt> parameter requires the <tt>value_type</tt> to |
| be <tt>CopyConstructible</tt>. |
| </ins></p> |
| |
| <p><ins> |
| The signature taking <tt>InputIterator</tt> parameters requires |
| <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced |
| <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue |
| <tt>value_type</tt>. |
| </ins></p> |
| |
| </blockquote> |
| |
| </blockquote> |
| |
| <p> |
| Add to 23.4.4.2 [unord.multiset.swap]: |
| </p> |
| |
| <blockquote> |
| <pre>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, |
| unordered_multiset<Key, T, Hash, Pred, Alloc>& y); |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x, |
| unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins> |
| <ins>template <class Key, class T, class Hash, class Pred, class Alloc> |
| void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x, |
| unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins> |
| </pre> |
| </blockquote> |
| |
| |
| |
| <p><i>[ |
| Voted to WP in Bellevue. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| post Bellevue, Pete notes: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Please remind people who are reviewing issues to check that the text |
| modifications match the current draft. Issue 676, for example, adds two |
| overloads for unordered_map::insert taking a hint. One takes a |
| const_iterator and returns a const_iterator, and the other takes an |
| iterator and returns an iterator. This was correct at the time the issue |
| was written, but was changed in Toronto so there is only one hint |
| overload, taking a const_iterator and returning an iterator. |
| </p> |
| <p> |
| This issue is not ready. In addition to the relatively minor signature |
| problem I mentioned earlier, it puts requirements in the wrong places. |
| Instead of duplicating requirements throughout the template |
| specifications, it should put them in the front matter that talks about |
| requirements for unordered containers in general. This presentation |
| problem is editorial, but I'm not willing to do the extensive rewrite |
| that it requires. Please put it back into Open status. |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3> |
| <p><b>Section:</b> 20.6.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using |
| the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads |
| to a dangling reference being stored into the <tt>reference_wrapper</tt> object. |
| Now that we have a mechanism to detect an rvalue, we can fix them to |
| disallow this source of undefined behavior. |
| </p> |
| |
| <p> |
| Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 20.6 [function.objects], add the following two signatures to the synopsis: |
| </p> |
| |
| <blockquote><pre>template <class T> void ref(const T&& t) = delete; |
| template <class T> void cref(const T&& t) = delete; |
| </pre></blockquote> |
| |
| |
| |
| <p><i>[ |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a> |
| addresses the first part of the resolution but not the second. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Bellevue: Doug noticed problems with the current wording. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| post Bellevue: Howard and Peter provided revised wording. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| This resolution depends on a "favorable" resolution of CWG 606: that is, |
| the "special deduction rule" is disabled with the const T&& pattern. |
| ]</i></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3> |
| <p><b>Section:</b> 23.4 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> JoaquÃn M López Muñoz <b>Date:</b> 2007-06-14</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The last version of TR1 does not include the following member |
| functions |
| for unordered containers: |
| </p> |
| |
| <blockquote><pre>const_local_iterator cbegin(size_type n) const; |
| const_local_iterator cend(size_type n) const; |
| </pre></blockquote> |
| |
| <p> |
| which looks like an oversight to me. I've checked th TR1 issues lists |
| and the latest working draft of the C++0x std (N2284) and haven't |
| found any mention to these menfuns or to their absence. |
| </p> |
| <p> |
| Is this really an oversight, or am I missing something? |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add the following two rows to table 93 (unordered associative container |
| requirements) in section 23.1.5 [unord.req]: |
| </p> |
| |
| <blockquote> |
| <table border="1"> |
| <caption>Unordered associative container requirements (in addition to container)</caption> |
| <tbody><tr> |
| <th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th> |
| </tr> |
| <tr> |
| <td><ins><tt>b.cbegin(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>. Note: <tt>[b.cbegin(n), b.cend(n))</tt> is a valid range containing all of the elements in the <tt>n</tt><sup><i>th</i></sup> bucket.</ins></td> <td><ins>Constant</ins></td> |
| </tr> |
| <tr> |
| <td><ins><tt>b.cend(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>.</ins></td> <td><ins>Constant</ins></td> |
| </tr> |
| </tbody></table> |
| </blockquote> |
| |
| <p> |
| Add to the synopsis in 23.4.1 [unord.map]: |
| </p> |
| |
| <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const; |
| const_local_iterator cend(size_type n) const;</ins> |
| </pre></blockquote> |
| |
| <p> |
| Add to the synopsis in 23.4.2 [unord.multimap]: |
| </p> |
| |
| <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const; |
| const_local_iterator cend(size_type n) const;</ins> |
| </pre></blockquote> |
| |
| <p> |
| Add to the synopsis in 23.4.3 [unord.set]: |
| </p> |
| |
| <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const; |
| const_local_iterator cend(size_type n) const;</ins> |
| </pre></blockquote> |
| |
| <p> |
| Add to the synopsis in 23.4.4 [unord.multiset]: |
| </p> |
| |
| <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const; |
| const_local_iterator cend(size_type n) const;</ins> |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3> |
| <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#Review">Review</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In a private email Bill Plauger notes: |
| </p> |
| <blockquote><p> |
| I believe that the function that implements <code>get_money</code> |
| [from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>] |
| should behave as a formatted input function, and the function that |
| implements <code>put_money</code> should behave as a formatted output |
| function. This has implications regarding the skipping of whitespace |
| and the handling of errors, among other things. |
| </p> |
| <p> |
| The words don't say that right now and I'm far from convinced that |
| such a change is editorial. |
| </p></blockquote> |
| <p> |
| Martin's response: |
| </p> |
| <blockquote><p> |
| I agree that the manipulators should handle exceptions the same way as |
| formatted I/O functions do. The text in N2072 assumes so but the |
| <i>Returns</i> clause explicitly omits exception handling for the sake |
| of brevity. The spec should be clarified to that effect. |
| </p> |
| <p> |
| As for dealing with whitespace, I also agree it would make sense for |
| the extractors and inserters involving the new manipulators to treat |
| it the same way as formatted I/O. |
| </p></blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the |
| following text: |
| </p> |
| <blockquote><p> |
| <i>Effects</i>: The expression <code><i>in</i> >> get_money(mon, intl)</code> |
| described below behaves as a formatted input function (as |
| described in 27.6.1.2.1 [istream.formatted.reqmts]). |
| </p></blockquote> |
| <p> |
| Also change p4 of 27.6.4 [ext.manip] as follows: |
| </p> |
| <blockquote><p> |
| <i>Returns</i>: An object <code>s</code> of unspecified type such that |
| if <code>in</code> is an object of type <code>basic_istream<charT, |
| traits></code> then the expression <code><i>in</i> >> get_money(mon, intl)</code> behaves as <ins>a formatted input function |
| that calls </ins><code>f(in, mon, intl)</code><del> were |
| called</del>. The function <code>f</code> can be defined as... |
| </p></blockquote> |
| |
| |
| <p><i>[ |
| post Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| We recommend moving immediately to Review. We've looked at the issue and |
| have a consensus that the proposed resolution is correct, but want an |
| iostream expert to sign off. Alisdair has taken the action item to putt |
| this up on the reflector for possible movement by Howard to Tenatively |
| Ready. |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="696"></a>696. <code>istream::operator>>(int&)</code> broken</h3> |
| <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-23</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| From message c++std-lib-17897: |
| </p> |
| <p> |
| The code shown in 27.6.1.2.2 [istream.formatted.arithmetic] as the "as if" |
| implementation of the two arithmetic extractors that don't have a |
| corresponding <code>num_get</code> interface (i.e., the |
| <code>short</code> and <code>int</code> overloads) is subtly buggy in |
| how it deals with <code>EOF</code>, overflow, and other similar |
| conditions (in addition to containing a few typos). |
| </p> |
| <p> |
| One problem is that if <code>num_get::get()</code> reaches the EOF |
| after reading in an otherwise valid value that exceeds the limits of |
| the narrower type (but not <code>LONG_MIN</code> or |
| <code>LONG_MAX</code>), it will set <code><i>err</i></code> to |
| <code>eofbit</code>. Because of the if condition testing for |
| <code>(<i>err</i> == 0)</code>, the extractor won't set |
| <code>failbit</code> (and presumably, return a bogus value to the |
| caller). |
| </p> |
| <p> |
| Another problem with the code is that it never actually sets the |
| argument to the extracted value. It can't happen after the call to |
| <code>setstate()</code> since the function may throw, so we need to |
| show when and how it's done (we can't just punt as say: "it happens |
| afterwards"). However, it turns out that showing how it's done isn't |
| quite so easy since the argument is normally left unchanged by the |
| facet on error except when the error is due to a misplaced thousands |
| separator, which causes <code>failbit</code> to be set but doesn't |
| prevent the facet from storing the value. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3> |
| <p><b>Section:</b> 19.4.5.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In 19.4.5.1 [syserr.syserr.overview] we have the class definition of |
| <tt>std::system_error</tt>. In contrast to all exception classes, which |
| are constructible with a <tt>what_arg string</tt> (see 19.1 [std.exceptions], |
| or <tt>ios_base::failure</tt> in 27.4.2.1.1 [ios::failure]), only overloads with with |
| <tt>const string&</tt> are possible. For consistency with the re-designed |
| remaining exception classes this class should also provide |
| c'tors which accept a const <tt>char* what_arg</tt> string. |
| </p> |
| <p> |
| Please note that this proposed addition makes sense even |
| considering the given implementation hint for <tt>what()</tt>, because |
| <tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class |
| <tt>runtime_error</tt>, which now has the additional c'tor overload |
| accepting a <tt>const char*</tt>. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| This proposed wording assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> has been accepted and applied to the working paper. |
| </p> |
| |
| <p> |
| Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated: |
| </p> |
| |
| <blockquote><pre>public: |
| system_error(error_code ec, const string& what_arg); |
| <ins>system_error(error_code ec, const char* what_arg);</ins> |
| system_error(error_code ec); |
| system_error(int ev, const error_category* ecat, |
| const string& what_arg); |
| <ins>system_error(int ev, const error_category* ecat, |
| const char* what_arg);</ins> |
| system_error(int ev, const error_category* ecat); |
| </pre></blockquote> |
| |
| <p> |
| To 19.4.5.2 [syserr.syserr.members] Class system_error members add: |
| </p> |
| |
| <blockquote> |
| <pre>system_error(error_code ec, const char* what_arg); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Effects:</i> Constructs an object of class <tt>system_error</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>. |
| </p> |
| </blockquote> |
| |
| <pre>system_error(int ev, const error_category* ecat, const char* what_arg); |
| </pre> |
| |
| <blockquote> |
| <p> |
| <i>Effects:</i> Constructs an object of class <tt>system_error</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="701"></a>701. assoc laguerre poly's</h3> |
| <p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| I see that the definition the associated Laguerre |
| polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>. |
| However, the draft standard only specifies ranks of integer value <tt>m</tt>, |
| while the associated Laguerre polynomials are actually valid for real |
| values of <tt>m > -1</tt>. In the case of non-integer values of <tt>m</tt>, the |
| definition <tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt> |
| must be used, which also holds for integer values of <tt>m</tt>. See |
| Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for |
| the integer case. In fact fractional values are most commonly used in |
| physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic |
| oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3 |
| dimensions. |
| </p> |
| <p> |
| If I am correct, the calculation of the more general case is no |
| more difficult, and is in fact the function implemented in the GNU |
| Scientific Library. I would urge you to consider upgrading the |
| standard, either adding extra functions for real <tt>m</tt> or switching the |
| current ones to <tt>double</tt>. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="702"></a>702. Restriction in associated Legendre functions</h3> |
| <p><b>Section:</b> TR1 5.2.1.2 [tr.num.sf.Plm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be |
| <tt>|x| <= 1</tt>, not <tt>x >= 0</tt>.</p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-20</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>. |
| Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from |
| most of the member functions of node-based containers. But the move-related changes |
| unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to |
| require <tt>CopyAssignable</tt>. |
| </p> |
| |
| <p> |
| We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt> |
| from some of the sequence requirements. Additionally the <i>in-place</i> construction |
| work may further reduce requirements. For purposes of an easy reference, here are the |
| minimum sequence requirements as I currently understand them. Those items in requirements |
| table in the working draft which do not appear below have been purposefully omitted for |
| brevity as they do not have any requirements of this nature. Some items which do not |
| have any requirements of this nature are included below just to confirm that they were |
| not omitted by mistake. |
| </p> |
| |
| <table border="1"> |
| <caption>Container Requirements</caption> |
| <tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr> |
| <tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> and containers with a <tt>propagate_never</tt> allocator require <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr> |
| <tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>. |
| Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr> |
| <tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>. |
| Sequences and Associative containers with <tt>propagate_never</tt> and <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and |
| <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr> |
| </tbody></table> |
| |
| <p> |
| </p> |
| |
| <table border="1"> |
| <caption>Sequence Requirements</caption> |
| <tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr> |
| <tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr> |
| <tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>. |
| If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>. |
| The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr> |
| <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>. |
| The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr> |
| <tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>. |
| The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr> |
| <tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>. |
| The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue. |
| If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>. |
| The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr> |
| <tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr> |
| <tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr> |
| <tr><td><tt>a.clear()</tt></td><td></td></tr> |
| <tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>. |
| If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr> |
| <tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr> |
| <tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>. |
| The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr> |
| </tbody></table> |
| |
| <p> |
| </p> |
| |
| <table border="1"> |
| <caption>Optional Sequence Requirements</caption> |
| <tbody><tr><td><tt>a.front()</tt></td><td></td></tr> |
| <tr><td><tt>a.back()</tt></td><td></td></tr> |
| <tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr> |
| <tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr> |
| <tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a.pop_front()</tt></td><td></td></tr> |
| <tr><td><tt>a.pop_back()</tt></td><td></td></tr> |
| <tr><td><tt>a[n]</tt></td><td></td></tr> |
| <tr><td><tt>a.at[n]</tt></td><td></td></tr> |
| </tbody></table> |
| |
| <p> |
| </p> |
| |
| <table border="1"> |
| <caption>Associative Container Requirements</caption> |
| <tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>. |
| If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr> |
| <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr> |
| <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr> |
| <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>. |
| If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr> |
| </tbody></table> |
| |
| <p> |
| </p> |
| |
| <table border="1"> |
| <caption>Unordered Associative Container Requirements</caption> |
| <tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>. |
| If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr> |
| <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr> |
| <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr> |
| <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>. |
| If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr> |
| </tbody></table> |
| |
| <p> |
| </p> |
| |
| <table border="1"> |
| <caption>Miscellaneous Requirements</caption> |
| <tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>. |
| The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr> |
| <tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>. |
| The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr> |
| </tbody></table> |
| |
| <p><i>[ |
| Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures. |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Bellevue: This should be handled as part of the concepts work. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3> |
| <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-07-28</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The POSIX "Extended API Set Part 4," |
| </p> |
| <blockquote><p> |
| <a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a> |
| </p></blockquote> |
| <p> |
| introduces extensions to the C locale mechanism that |
| allow multiple concurrent locales to be used in the same application |
| by introducing a type <tt>locale_t</tt> that is very similar to |
| <tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it. |
| </p> |
| <p> |
| The global locale (set by setlocale) is now specified to be per- |
| process. If a thread does not call <tt>uselocale</tt>, the global locale is |
| in effect for that thread. It can install a per-thread locale by |
| using <tt>uselocale</tt>. |
| </p> |
| <p> |
| There is also a nice <tt>querylocale</tt> mechanism by which one can obtain |
| the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined |
| locales, with no <tt>std::locale</tt> equivalent. |
| </p> |
| <p> |
| <tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt> |
| mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>. |
| </p> |
| |
| <p><i>[ |
| Kona (2007): Bill and Nick to provide wording. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3> |
| <p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> |
| <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The changes made for <tt>constexpr</tt> in 21.1.3 [char.traits.specializations] have |
| not only changed the <tt>not_eof</tt> function from pass by const reference to |
| pass by value, it has also changed the parameter type from <tt>int_type</tt> to |
| <tt>char_type</tt>. |
| </p> |
| <p> |
| This doesn't work for type <tt>char</tt>, and is inconsistent with the |
| requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require]. |
| </p> |
| |
| <p> |
| Pete adds: |
| </p> |
| |
| <blockquote><p> |
| For what it's worth, that may not have been an intentional change. |
| N2349, which detailed the changes for adding constant expressions to |
| the library, has strikeout bars through the <tt>const</tt> and the <tt>&</tt> that |
| surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself. |
| So the intention may have been just to change to pass by value, with |
| text incorrectly copied from the standard. |
| </p></blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change the signature in 21.1.3.1 [char.traits.specializations.char], |
| 21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t], |
| and 21.1.3.4 [char.traits.specializations.wchar.t] to |
| </p> |
| |
| <blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c); |
| </pre></blockquote> |
| |
| |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Resolution: NAD editorial - up to Pete's judgment |
| </blockquote> |
| |
| <p><i>[ |
| Post Sophia Antipolis |
| ]</i></p> |
| |
| |
| <blockquote> |
| Moved from Pending NAD Editorial to Review. The proposed wording appears to be correct but non-editorial. |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3> |
| <p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| A discussion on |
| <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a> |
| has identified a contradiction in the <tt>shared_ptr</tt> specification. |
| The note: |
| </p> |
| |
| <blockquote><p> |
| [ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer. |
| -end note ] |
| </p></blockquote> |
| |
| <p> |
| after the aliasing constructor |
| </p> |
| |
| <blockquote><pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p); |
| </pre></blockquote> |
| |
| <p> |
| reflects the intent of |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a> |
| to, well, allow the creation of an empty <tt>shared_ptr</tt> |
| with a non-NULL stored pointer. |
| </p> |
| |
| <p> |
| This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]: |
| </p> |
| |
| <blockquote> |
| <pre>T* get() const; |
| </pre> |
| <blockquote><p> |
| <i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty. |
| </p></blockquote> |
| </blockquote> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Adopt option 1 and move to review, not ready. |
| </p> |
| <p> |
| There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term |
| isn't defined anywhere), and whether we have a good mental model for how |
| one behaves. We think it might be possible to deduce what the definition |
| should be, but the words just aren't there. We need to open an issue on |
| the use of this undefined term. (The resolution of that issue might |
| affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.) |
| </p> |
| <p> |
| The LWG is getting more uncomfortable with the aliasing proposal (N2351) |
| now that we realize some of its implications, and we need to keep an eye |
| on it, but there isn't support for removing this feature at this time. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| We heard from Peter Dimov, who explained his reason for preferring solution 1. |
| </p> |
| <p> |
| Because it doesn't seem to add anything. It simply makes the behavior |
| for p = 0 undefined. For programmers who don't create empty pointers |
| with p = 0, there is no difference. Those who do insist on creating them |
| presumably have a good reason, and it costs nothing for us to define the |
| behavior in this case. |
| </p> |
| <p> |
| The aliasing constructor is sharp enough as it is, so "protecting" users |
| doesn't make much sense in this particular case. |
| </p> |
| <p> |
| > Do you have a use case for r being empty and r being non-null? |
| </p> |
| <p> |
| I have received a few requests for it from "performance-conscious" |
| people (you should be familiar with this mindset) who don't like the |
| overhead of allocating and maintaining a control block when a null |
| deleter is used to approximate a raw pointer. It is obviously an "at |
| your own risk", low-level feature; essentially a raw pointer behind a |
| shared_ptr facade. |
| </p> |
| <p> |
| We could not agree upon a resolution to the issue; some of us thought |
| that Peter's description above is supporting an undesirable behavior. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]: |
| </p> |
| |
| <blockquote> |
| <pre>T* get() const; |
| </pre> |
| <blockquote><p> |
| <i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del> |
| </p></blockquote> |
| </blockquote> |
| |
| <p> |
| Alternative proposed resolution: (I won't be happy if we do this, but it's possible): |
| </p> |
| |
| <p> |
| Change 20.7.12.2.1 [util.smartptr.shared.const]: |
| </p> |
| |
| <blockquote> |
| <pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p); |
| </pre> |
| <blockquote> |
| <p> |
| <ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins> |
| </p> |
| <p> |
| <del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt> |
| instance with a non-NULL stored pointer. |
| -- <i>end note</i> ]</del> |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3> |
| <p><b>Section:</b> 25.3.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N |
| log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the |
| average", with no worst case complicity specified. The intention was to |
| allow a median-of-three quicksort implementation, which is usually <tt>O(N |
| log N)</tt> but can be quadratic for pathological inputs. However, there is |
| no longer any reason to allow implementers the freedom to have a |
| worst-cast-quadratic sort algorithm. Implementers who want to use |
| quicksort can use a variant like David Musser's "Introsort" (Software |
| Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N |
| log N)</tt> in the worst case without incurring additional overhead in the |
| average case. Most C++ library implementers already do this, and there |
| is no reason not to guarantee it in the standard. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266: |
| </p> |
| |
| <blockquote> |
| <p> |
| <i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> (where <i>N</i> == <i>last</i> - <i>first</i> ) |
| comparisons<del> on the average</del>.<del><sup>266)</sup></del> |
| </p> |
| <p> |
| <del><sup>266)</sup> |
| If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt> |
| (25.3.1.3) should be used.</del> |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3> |
| <p><b>Section:</b> 25.1.12 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The complexity for <tt>search_n</tt> (25.1.12 [alg.search] par 7) is specified as "At most |
| (last - first ) * count applications of the corresponding predicate if |
| count is positive, or 0 otherwise." This is unnecessarily pessimistic. |
| Regardless of the value of count, there is no reason to examine any |
| element in the range more than once. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change the complexity to "At most (last - first) applications of the corresponding predicate". |
| </p> |
| |
| <blockquote> |
| <pre>template<class ForwardIterator, class Size, class T> |
| ForwardIterator |
| search_n(ForwardIterator first , ForwardIterator last , Size count , |
| const T& value ); |
| |
| template<class ForwardIterator, class Size, class T, |
| class BinaryPredicate> |
| ForwardIterator |
| search_n(ForwardIterator first , ForwardIterator last , Size count , |
| const T& value , BinaryPredicate pred ); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate |
| <del>if <tt>count</tt> is positive, or 0 otherwise</del>. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3> |
| <p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-08-31</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say: |
| </p> |
| |
| <blockquote> |
| <p> |
| The following productions within the ECMAScript grammar are modified as follows: |
| </p> |
| |
| <blockquote><pre>CharacterClass :: |
| [ [lookahead ∉ {^}] ClassRanges ] |
| [ ^ ClassRanges ] |
| </pre></blockquote> |
| |
| </blockquote> |
| |
| <p> |
| This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262. |
| </p> |
| |
| <p> |
| Was an actual modification intended here and accidentally omitted, or was this production accidentally included? |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Remove this mention of the CharacterClass production. |
| </p> |
| |
| <blockquote><pre><del>CharacterClass :: |
| [ [lookahead ∉ {^}] ClassRanges ] |
| [ ^ ClassRanges ]</del> |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-18</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Paragraph 21.3 [basic.string]/3 states: |
| </p> |
| |
| <blockquote> |
| <p> |
| The class template <tt>basic_string</tt> conforms to the requirements for a |
| Sequence (23.1.1) and for a Reversible Container (23.1). |
| </p> |
| </blockquote> |
| |
| <p> |
| First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container". |
| Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>, |
| <tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not |
| even close to conform to the current requirements. |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <ul> |
| <li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li> |
| <li>with concepts do we need to maintain string as sequence container?</li> |
| <li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li> |
| </ul> |
| <ul> |
| <li>basic_string already has push_back</li> |
| <li>const_iterator parameters to insert and erase should be added to basic_string</li> |
| <li>this leaves emplace to handle -- we have the following options: |
| <ul> |
| <li>option 1: add it to string even though it's optional</li> |
| <li>option 2: make emplace optional to sequences (move from table 89 to 90)</li> |
| <li>option 3: say string not sequence (the proposal),</li> |
| <li>option 4: add an exception to basic string wording.</li> |
| </ul> |
| </li> |
| </ul> |
| General consensus is to suggest option 2. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is |
| not just a <tt>vector</tt>-light for literal types, but something quite |
| different, a string abstraction in its own right. |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3> |
| <p><b>Section:</b> 20.5 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have |
| a new type category "literal", which is defined in 3.9 [basic.types]/p.11: |
| </p> |
| |
| <blockquote> |
| <p> |
| -11- A type is a <i>literal</i> type if it is: |
| </p> |
| <ul> |
| <li>a scalar type; or</li> |
| <li><p>a class type (clause 9) with</p> |
| <ul> |
| <li>a trivial copy constructor,</li> |
| <li>a trivial destructor,</li> |
| <li>at least one constexpr constructor other than the copy constructor,</li> |
| <li>no virtual base classes, and</li> |
| <li>all non-static data members and base classes of literal types; or</li> |
| </ul> |
| </li> |
| <li>an array of literal type.</li> |
| </ul> |
| </blockquote> |
| |
| <p> |
| I strongly suggest that the standard provides a type traits for |
| literal types in 20.5.4.3 [meta.unary.prop] for several reasons: |
| </p> |
| |
| <ol type="a"> |
| <li>To keep the traits in sync with existing types.</li> |
| <li>I see many reasons for programmers to use this trait in template |
| code to provide optimized template definitions for these types, |
| see below.</li> |
| <li>A user-provided definition of this trait is practically impossible |
| to write portably.</li> |
| </ol> |
| |
| <p> |
| The special problem of reason (c) is that I don't see currently a |
| way to portably test the condition for literal class types: |
| </p> |
| |
| <blockquote> |
| <ul> |
| <li>at least one constexpr constructor other than the copy constructor,</li> |
| </ul> |
| </blockquote> |
| |
| <p> |
| Here follows a simply example to demonstrate it's usefulness: |
| </p> |
| |
| <blockquote><pre>template <typename T> |
| constexpr typename std::enable_if<std::is_literal<T>::value, T>::type |
| abs(T x) { |
| return x < T() ? -x : x; |
| } |
| |
| template <typename T> |
| typename std::enable_if<!std::is_literal<T>::value, T>::type |
| abs(const T& x) { |
| return x < T() ? -x : x; |
| } |
| </pre></blockquote> |
| |
| <p> |
| Here we have the possibility to provide a general <tt>abs</tt> function |
| template that can be used in ICE's if it's argument is a literal |
| type which's value is a constant expression, otherwise we |
| have an optimized version for arguments which are expensive |
| to copy and therefore need the usage of arguments of |
| reference type (instead of <tt>const T&</tt> we could decide to |
| use <tt>T&&</tt>, but that is another issue). |
| </p> |
| |
| <p><i>[ |
| Alisdair is considering preparing a paper listing a number of missing |
| type traits, and feels that it might be useful to handle them all |
| together rather than piecemeal. This would affect issue 719 and 750. |
| These two issues should move to OPEN pending AM paper on type traits. |
| ]</i></p> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 20.5.2 [meta.type.synop] in the group "type properties", |
| just below the line |
| </p> |
| |
| <blockquote><pre>template <class T> struct is_pod; |
| </pre></blockquote> |
| |
| <p> |
| add a new one: |
| </p> |
| |
| <blockquote><pre>template <class T> struct is_literal; |
| </pre></blockquote> |
| |
| <p> |
| In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just |
| below the line for the <tt>is_pod</tt> property add a new line: |
| </p> |
| |
| <table border="1"> |
| <tbody><tr> |
| <th>Template</th><th>Condition</th><th>Preconditions</th> |
| </tr> |
| <tr> |
| <td><tt>template <class T> struct is_literal;</tt></td> |
| <td><tt>T</tt> is a literal type (3.9)</td> |
| <td><tt>T</tt> shall be a complete type, an |
| array of unknown bound, or |
| (possibly cv-qualified) <tt>void</tt>.</td> |
| </tr> |
| </tbody></table> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="720"></a>720. Omissions in constexpr usages</h3> |
| <p><b>Section:</b> 23.2.1 [array], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <ol> |
| <li> |
| The member function <tt>bool array<T,N>::empty() const</tt> should be a |
| <tt>constexpr</tt> because this is easily to proof and to implement following it's operational |
| semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>. |
| </li> |
| <li> |
| The member function <tt>bool bitset<N>::test() const</tt> must be a |
| <tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr |
| bitset<N>::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>). |
| </li> |
| <li> |
| I wonder how the constructor <tt>bitset<N>::bitset(unsigned long)</tt> can |
| be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt> |
| c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a |
| non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the |
| initialisation. What have I overlooked here? |
| </li> |
| </ol> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| We handle this as two parts |
| </p> |
| <ol> |
| <li> |
| The proposed resolution is correct; move to ready. |
| </li> |
| <li> |
| The issue points out a real problem, but the issue is larger than just |
| this solution. We believe a paper is needed, applying the full new |
| features of C++ (including extensible literals) to update <tt>std::bitset</tt>. |
| We note that we do not consider this new work, and that is should be |
| handled by the Library Working Group. |
| </li> |
| </ol> |
| <p> |
| In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <ol> |
| <li> |
| <p>In the class template definition of 23.2.1 [array]/p. 3 change</p> |
| <blockquote><pre><ins>constexpr</ins> bool empty() const; |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p>In the class template definition of 23.3.5 [template.bitset]/p. 1 change</p> |
| <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const; |
| </pre></blockquote> |
| |
| <p> |
| and in 23.3.5.2 [bitset.members] change |
| </p> |
| |
| <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const; |
| </pre></blockquote> |
| |
| </li> |
| </ol> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3> |
| <p><b>Section:</b> 22.1.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-27</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the |
| requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot |
| be used (because of a protected destructor). |
| </p> |
| |
| <p> |
| How are we going to explain this code to beginning programmers? |
| </p> |
| |
| <blockquote><pre>template<class I, class E, class S> |
| struct codecvt : std::codecvt<I, E, S> |
| { |
| ~codecvt() |
| { } |
| }; |
| |
| void main() |
| { |
| std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok; |
| |
| std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok; |
| } |
| </pre></blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3> |
| <p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-29</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| According to the current state of the standard draft, the class |
| template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is |
| neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>. |
| IMO it should be, because typical regex state machines tend |
| to have a rather large data quantum and I have seen several |
| use cases, where a factory function returns regex values, |
| which would take advantage of moveabilities. |
| </p> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Needs wording for the semantics, the idea is agreed upon. |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <ol type="a"> |
| <li> |
| <p> |
| In the header <tt><regex></tt> synopsis 28.4 [re.syn], just below the function |
| template <tt>swap</tt> add two further overloads: |
| </p> |
| <blockquote><pre>template <class charT, class traits> |
| void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>& e2); |
| <ins>template <class charT, class traits> |
| void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2); |
| template <class charT, class traits> |
| void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);</ins> |
| </pre></blockquote> |
| <p> |
| In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3, |
| perform the following changes: |
| </p> |
| </li> |
| |
| <li> |
| <p>Just after the copy c'tor:</p> |
| <blockquote><pre>basic_regex(basic_regex&&); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p>Just after the copy-assignment op.:</p> |
| <blockquote><pre>basic_regex& operator=(basic_regex&&); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p>Just after the first <tt>assign</tt> overload insert:</p> |
| <blockquote><pre>basic_regex& assign(basic_regex&& that); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p>Change the current <tt>swap</tt> function to read:</p> |
| <blockquote><pre>void swap(basic_regex&&); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p>In 28.8.2 [re.regex.construct], just below the copy c'tor add a |
| corresponding member definition of:</p> |
| <blockquote><pre>basic_regex(basic_regex&&); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p>Also in 28.8.2 [re.regex.construct], just below the copy assignment |
| c'tor add a corresponding member definition of:</p> |
| <blockquote><pre>basic_regex& operator=(basic_regex&&); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p>In 28.8.3 [re.regex.assign], just below the first <tt>assign</tt> overload add |
| a corresponding member definition of:</p> |
| <blockquote><pre>basic_regex& assign(basic_regex&& that); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p>In 28.8.6 [re.regex.swap], change the signature of <tt>swap</tt> to |
| say:</p> |
| <blockquote><pre>void swap(basic_regex&& e); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p>In 28.8.7.1 [re.regex.nmswap], just below the single binary <tt>swap</tt> |
| function, add the two missing overloads:</p> |
| <blockquote><pre>template <class charT, class traits> |
| void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2); |
| template <class charT, class traits> |
| void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2); |
| </pre></blockquote> |
| </li> |
| </ol> |
| |
| <p> |
| Of course there would be need of corresponding proper standardese |
| to describe these additions. |
| </p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2007-09-12</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The <tt>DefaultConstructible</tt> requirement is referenced in |
| several places in the August 2007 working draft |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>, |
| but is not defined anywhere. |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Walking into the default/value-initialization mess... |
| </p> |
| <p> |
| Why two lines? Because we need both expressions to be valid. |
| </p> |
| <p> |
| AJM not sure what the phrase "default constructed" means. This is |
| unfortunate, as the phrase is already used 24 times in the library! |
| </p> |
| <p> |
| Example: const int would not accept first line, but will accept the second. |
| </p> |
| <p> |
| This is an issue that must be solved by concepts, but we might need to solve it independantly first. |
| </p> |
| <p> |
| It seems that the requirements are the syntax in the proposed first |
| column is valid, but not clear what semantics we need. |
| </p> |
| <p> |
| A table where there is no post-condition seems odd, but appears to sum up our position best. |
| </p> |
| <p> |
| At a minimum an object is declared and is destuctible. |
| </p> |
| <p> |
| Move to open, as no-one happy to produce wording on the fly. |
| </p> |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In section 20.1.1 [utility.arg.requirements], before table 33, add the |
| following table: |
| </p> |
| |
| <p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p> |
| |
| <div align="center"> |
| |
| <table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0"> |
| <tbody><tr> |
| <td style="border-style: solid none double solid; border-color: navy -moz-use-text-color navy navy; border-width: 1pt medium 1.5pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114"> |
| <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p> |
| </td> |
| <td style="border-style: solid solid double none; border-color: navy navy navy -moz-use-text-color; border-width: 1pt 1pt 1.5pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324"> |
| <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p> |
| </td> |
| </tr> |
| <tr> |
| <td style="border-style: none none solid solid; border-color: -moz-use-text-color -moz-use-text-color navy navy; border-width: medium medium 1pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114"> |
| <p style="margin: 0in 0in 0.0001pt;"><tt>T |
| t;</tt><br> |
| <tt>T()</tt></p> |
| </td> |
| <td style="border-style: none solid solid none; border-color: -moz-use-text-color navy navy -moz-use-text-color; border-width: medium 1pt 1pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324"> |
| <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt> |
| is <i>default constructed.</i></p> |
| </td> |
| </tr> |
| </tbody></table> |
| |
| </div> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3> |
| <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Two overloads of <tt>regex_replace()</tt> are currently provided: |
| </p> |
| |
| <blockquote><pre>template <class OutputIterator, class BidirectionalIterator, |
| class traits, class charT> |
| OutputIterator |
| regex_replace(OutputIterator out, |
| BidirectionalIterator first, BidirectionalIterator last, |
| const basic_regex<charT, traits>& e, |
| const basic_string<charT>& fmt, |
| regex_constants::match_flag_type flags = |
| regex_constants::match_default); |
| |
| template <class traits, class charT> |
| basic_string<charT> |
| regex_replace(const basic_string<charT>& s, |
| const basic_regex<charT, traits>& e, |
| const basic_string<charT>& fmt, |
| regex_constants::match_flag_type flags = |
| regex_constants::match_default); |
| </pre></blockquote> |
| |
| <ol> |
| <li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and |
| <tt>regex_search()</tt>, but not <tt>regex_replace()</tt>. This is inconsistent.</li> |
| <li> |
| <p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p> |
| |
| <blockquote><pre>const string s("kitten"); |
| const regex r("en"); |
| cout << regex_replace(s, r, "y") << endl; |
| </pre></blockquote> |
| |
| <p> |
| The compiler error message will be something like "could not deduce |
| template argument for 'const std::basic_string<_Elem> &' from 'const |
| char[1]'". |
| </p> |
| |
| <p> |
| Users expect that anything taking a <tt>basic_string<charT></tt> can also take a |
| <tt>const charT *</tt>. In their own code, when they write a function taking |
| <tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const |
| wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor. Because the |
| regex algorithms are templated on <tt>charT</tt>, they can't rely on |
| <tt>basic_string</tt>'s implicit constructor (as the compiler error message |
| indicates, template argument deduction fails first). |
| </p> |
| |
| <p> |
| If a user figures out what the compiler error message means, workarounds |
| are available - but they are all verbose. Explicit template arguments |
| could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit |
| constructor to be invoked - but <tt>charT</tt> is the last template argument, not |
| the first, so this would be extremely verbose. Therefore, constructing |
| a <tt>basic_string</tt> from each C string is the simplest workaround. |
| </p> |
| </li> |
| |
| <li> |
| There is an efficiency consideration: constructing <tt>basic_string</tt>s can |
| impose performance costs that could be avoided by a library |
| implementation taking C strings and dealing with them directly. |
| (Currently, for replacement sources, C strings can be converted into |
| iterator pairs at the cost of verbosity, but for format strings, there |
| is no way to avoid constructing a <tt>basic_string</tt>.) |
| </li> |
| </ol> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| We note that Boost already has these overloads. However, the proposed |
| wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis |
| as well. We also note that this has impact on <tt>match_results::format</tt>, |
| which may require further overloads. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Provide additional overloads for <tt>regex_replace()</tt>: one additional |
| overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three |
| additional overloads of the convenience form (one taking <tt>const charT* |
| str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const |
| charT* str</tt> and <tt>const charT* fmt</tt>). 28.11.4 [re.alg.replace]: |
| </p> |
| |
| <blockquote> |
| <pre>template <class OutputIterator, class BidirectionalIterator, |
| class traits, class charT> |
| OutputIterator |
| regex_replace(OutputIterator out, |
| BidirectionalIterator first, BidirectionalIterator last, |
| const basic_regex<charT, traits>& e, |
| const basic_string<charT>& fmt, |
| regex_constants::match_flag_type flags = |
| regex_constants::match_default); |
| |
| <ins>template <class OutputIterator, class BidirectionalIterator, |
| class traits, class charT> |
| OutputIterator |
| regex_replace(OutputIterator out, |
| BidirectionalIterator first, BidirectionalIterator last, |
| const basic_regex<charT, traits>& e, |
| const charT* fmt, |
| regex_constants::match_flag_type flags = |
| regex_constants::match_default);</ins> |
| </pre> |
| <p>...</p> |
| <pre>template <class traits, class charT> |
| basic_string<charT> |
| regex_replace(const basic_string<charT>& s, |
| const basic_regex<charT, traits>& e, |
| const basic_string<charT>& fmt, |
| regex_constants::match_flag_type flags = |
| regex_constants::match_default); |
| |
| <ins>template <class traits, class charT> |
| basic_string<charT> |
| regex_replace(const basic_string<charT>& s, |
| const basic_regex<charT, traits>& e, |
| const charT* fmt, |
| regex_constants::match_flag_type flags = |
| regex_constants::match_default);</ins> |
| |
| <ins>template <class traits, class charT> |
| basic_string<charT> |
| regex_replace(const charT* s, |
| const basic_regex<charT, traits>& e, |
| const basic_string<charT>& fmt, |
| regex_constants::match_flag_type flags = |
| regex_constants::match_default);</ins> |
| |
| <ins>template <class traits, class charT> |
| basic_string<charT> |
| regex_replace(const charT* s, |
| const basic_regex<charT, traits>& e, |
| const charT* fmt, |
| regex_constants::match_flag_type flags = |
| regex_constants::match_default);</ins> |
| </pre> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3> |
| <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string<charT, ST, |
| SA>&</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string<charT>&</tt>. This prevents |
| <tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and |
| allocators. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally |
| templated on <tt>class ST, class SA</tt> and take <tt>const basic_string<charT, ST, |
| SA>&</tt>. Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place |
| <tt>class ST, class SA</tt> as the first template arguments; compatibility with |
| existing code using TR1 and giving explicit template arguments to |
| <tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template |
| arguments. |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3> |
| <p><b>Section:</b> 26.4.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given |
| as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization |
| of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate |
| for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in |
| which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M. |
| Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister |
| [<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>]. |
| </p> |
| |
| <p> |
| I see two possible resolutions: |
| </p> |
| |
| <ol type="a"> |
| <li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the |
| multiplier from [the above reference] for the 64-bit case (my preference)</li> |
| <li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte |
| order) and always employ the 32-bit algorithm for seeding |
| </li> |
| </ol> |
| |
| <p> |
| See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> |
| for further discussion. |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Stephan Tolksdorf has additional comments on N2424. He comments: "there |
| is a typo in the required behaviour for mt19937_64: It should be the |
| 10000th (not 100000th) invocation whose value is given, and the value |
| should be 9981545732273789042 (not 14002232017267485025)." These values |
| need checking. |
| </p> |
| <p> |
| Take the proposed recommendation in N2424 and move to REVIEW. |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> |
| for the proposed resolution. |
| </p> |
| |
| <p><i>[ |
| Stephan Tolksdorf adds pre-Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| I support the proposed resolution in |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>, |
| but there is a typo in the |
| required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not |
| 100000<sup>th</sup>) invocation whose value is given, and the value should be |
| 9981545732273789042 (not 14002232017267485025). The change to para. 8 |
| proposed by Charles Karney should also be included in the proposed |
| wording. |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Note the main part of the issue is resolved by |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>. |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3> |
| <p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a></p> |
| <p><b>Discussion:</b></p> |
| <p> |
| 26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is |
| meant to simulate random numbers from any general distribution given only the density and the |
| support of the distribution. I'm not aware of any general purpose algorithm that would be capable |
| of correctly and efficiently implementing the described functionality. From what I know, this is |
| essentially an unsolved research problem. Existing algorithms either require more knowledge |
| about the distribution and the problem domain or work only under very limited circumstances. |
| Even the state of the art special purpose library UNU.RAN does not solve the problem in full |
| generality, and in any case, testing and customer support for such a library feature would be a |
| nightmare. |
| </p> |
| |
| <p> |
| <b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf]. |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Disagreement persists. |
| </p> |
| <p> |
| Objection to this issue is that this function takes a general functor. |
| The general approach would be to normalize this function, integrate it, |
| and take the inverse of the integral, which is not possible in general. |
| An example function is sin(1+n*x) -- for any spatial frequency that the |
| implementor chooses, there is a value of n that renders that choice |
| arbitrarily erroneous. |
| </p> |
| <p> |
| Correction: The formula above should instead read 1+sin(n*x). |
| </p> |
| <p> |
| Objector proposes the following possible compromise positions: |
| </p> |
| <ul> |
| <li> |
| rand.dist.samp.genpdf takes an number of points so that implementor need not guess. |
| </li> |
| <li>replace rand.disk.samp.genpdf with an extension to either or both |
| of the discrete functions to take arguments that take a functor and |
| number of points in place of the list of probabilities. Reference |
| issues 793 and 794. |
| </li> |
| </ul> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> |
| for the proposed resolution. |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3> |
| <p><b>Section:</b> 26.4.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> |
| <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt> |
| have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the |
| following two reasons this is an unnecessary restriction: First, in many applications such as |
| Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param- |
| eters as continuous variables. Second, the standard non-naive algorithms (i.e. |
| O(1) algorithms) |
| for simulating from these distributions work with floating-point parameters anyway (all three |
| distributions could be easily implemented using the Gamma distribution, for instance). |
| </p> |
| |
| <p> |
| Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete |
| <tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous |
| parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt> |
| the implementation would be significantly complicated by a non-discrete parameter (in most |
| implementations one would need an approximation of the log-gamma function instead of just the |
| log-factorial function). |
| </p> |
| |
| <p> |
| <b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters |
| to double. |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| In N2424. Not wildly enthusiastic, not really felt necessary. Less |
| frequently used in practice. Not terribly bad either. Move to OPEN. |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test. |
| </p> |
| <p> |
| Marc Paterno: Ask implementers whether floating-point is a significant burden. |
| </p> |
| <p> |
| Alisdair: It's neater to do it now, do ask Bill Plauger. |
| </p> |
| <p> |
| Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> |
| for the proposed resolution. |
| </p> |
| |
| <p><i>[ |
| Stephan Tolksdorf adds pre-Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| In 26.4.8.4.3 [rand.dist.norm.chisq]: |
| </p> |
| |
| <blockquote> |
| <p> |
| Delete ", where <tt>n</tt> is a positive integer" in the first paragraph. |
| </p> |
| |
| <p> |
| Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>" |
| with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>". |
| </p> |
| |
| <p> |
| Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>". |
| </p> |
| |
| </blockquote> |
| |
| <p> |
| In 26.4.8.4.5 [rand.dist.norm.f]: |
| </p> |
| <blockquote> |
| <p> |
| Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph. |
| </p> |
| |
| <p> |
| Replace both occurrences of |
| </p> |
| <blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1); |
| </pre></blockquote> |
| <p> |
| with |
| </p> |
| <blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1); |
| </pre></blockquote> |
| |
| <p> |
| Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>". |
| </p> |
| |
| <p> |
| Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>". |
| </p> |
| </blockquote> |
| |
| <p> |
| In 26.4.8.4.6 [rand.dist.norm.t]: |
| </p> |
| |
| <blockquote> |
| <p> |
| Delete ", where <tt>n</tt> is a positive integer" in the first paragraph. |
| </p> |
| |
| <p> |
| Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>" |
| with "<tt>explicit student_t_distribution(RealType n = 1);</tt>". |
| </p> |
| |
| <p> |
| Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>". |
| </p> |
| </blockquote> |
| |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just |
| deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt> |
| requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to |
| <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>. |
| </p> |
| |
| <p> |
| This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators. Here |
| is example code: |
| </p> |
| |
| <blockquote><pre>namespace Mine { |
| |
| template <class T> |
| struct proxy {...}; |
| |
| template <class T> |
| struct proxied_iterator |
| { |
| typedef T value_type; |
| typedef proxy<T> reference; |
| reference operator*() const; |
| ... |
| }; |
| |
| struct A |
| { |
| // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable |
| void swap(A&); |
| ... |
| }; |
| |
| void swap(A&, A&); |
| void swap(proxy<A>, A&); |
| void swap(A&, proxy<A>); |
| void swap(proxy<A>, proxy<A>); |
| |
| } // Mine |
| |
| ... |
| |
| Mine::proxied_iterator<Mine::A> i(...) |
| Mine::A a; |
| <b>swap(*i1, a);</b> |
| </pre></blockquote> |
| |
| <p> |
| The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt> |
| and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the |
| same type). A secondary point is that to support proxies, one must be able to pass rvalues |
| to <tt>swap</tt>. But note that I am not stating that the general purpose <tt>std::swap</tt> |
| should accept rvalues! Only that overloaded <tt>swap</tt>s, as in the example above, be allowed |
| to take rvalues. |
| </p> |
| |
| <p> |
| That is, no standard library code needs to change. We simply need to have a more flexible |
| definition of <tt>Swappable</tt>. |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| While we believe Concepts work will define a swappable concept, we |
| should still resolve this issue if possible to give guidance to the |
| Concepts work. |
| </p> |
| <p> |
| Would an ambiguous swap function in two namespaces found by ADL break |
| this wording? Suggest that the phrase "valid expression" means such a |
| pair of types would still not be swappable. |
| </p> |
| <p> |
| Motivation is proxy-iterators, but facility is considerably more |
| general. Are we happy going so far? |
| </p> |
| <p> |
| We think this wording is probably correct and probably an improvement on |
| what's there in the WP. On the other hand, what's already there in the |
| WP is awfully complicated. Why do we need the two bullet points? They're |
| too implementation-centric. They don't add anything to the semantics of |
| what swap() means, which is there in the post-condition. What's wrong |
| with saying that types are swappable if you can call swap() and it |
| satisfies the semantics of swapping? |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 20.1.1 [utility.arg.requirements]: |
| </p> |
| |
| <blockquote> |
| |
| <p> |
| -1- The template definitions in the C++ Standard Library refer to various |
| named requirements whose details are set out in tables 31-38. In these |
| tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program |
| instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are |
| values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable |
| lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly |
| <tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt> |
| rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>. |
| </p> |
| |
| <table border="1"> |
| <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption> |
| <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr> |
| <tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td> |
| <td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally |
| held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and |
| <del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held |
| by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr> |
| <tr><td colspan="3"> |
| <p> |
| The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions: |
| </p> |
| <ul> |
| <li> |
| <tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are |
| the same type and </ins> <tt>T</tt> satisfies the |
| <del><tt>CopyConstructible</tt></del> |
| <ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del> |
| <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> |
| <ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del> |
| <ins>35</ins>); |
| </li> |
| <li> |
| <tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named |
| <tt>swap</tt> exists in the same namespace as the definition of |
| <tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression |
| <tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the |
| semantics described in this table. |
| </li> |
| </ul> |
| </td></tr> |
| </tbody></table> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3> |
| <p><b>Section:</b> 20.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| We have 3 separate type traits to identify classes supporting no-throw |
| operations, which are very useful when trying to provide exception safety |
| guarantees. However, I'm not entirely clear on what the current wording |
| requires of a conforming implementation. To quote from |
| <tt>has_nothrow_default_constructor</tt>: |
| </p> |
| <blockquote><p> |
| or <tt>T</tt> is a class type with a default constructor that is known not to throw |
| any exceptions |
| </p></blockquote> |
| <p> |
| What level of magic do we expect to deduce if this is known? |
| </p> |
| <p> |
| E.g. |
| </p> |
| |
| <blockquote><pre>struct test{ |
| int x; |
| test() : x() {} |
| }; |
| </pre></blockquote> |
| <p> |
| Should I expect a conforming compiler to |
| <tt>assert( has_nothrow_constructor<test>::value )</tt> |
| </p> |
| <p> |
| Is this a QoI issue? |
| </p> |
| <p> |
| Should I expect to 'know' only if-and-only-if there is an inline definition |
| available? |
| </p> |
| <p> |
| Should I never expect that to be true, and insist that the user supplies an |
| empty throw spec if they want to assert the no-throw guarantee? |
| </p> |
| <p> |
| It would be helpful to maybe have a footnote explaining what is required, |
| but right now I don't know what to suggest putting in the footnote. |
| </p> |
| <p> |
| (agreement since is that trivial ops and explicit no-throws are required. |
| Open if QoI should be allowed to detect further) |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| This looks like a QoI issue. |
| In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI. |
| Move to OPEN. Need to talk to Core about this. |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be |
| implicitly convertible, so explicit constructors are ignored.</h3> |
| <p><b>Section:</b> 20.5.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| With the pending arrival of explicit conversion functions though, I'm |
| wondering if we want an additional trait, <tt>is_explictly_convertible</tt>? |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Alisdair is considering preparing a paper listing a number of missing |
| type traits, and feels that it might be useful to handle them all |
| together rather than piecemeal. This would affect issue 719 and 750. |
| These two issues should move to OPEN pending AM paper on type traits. |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="751"></a>751. change pass-by-reference members of <tt>vector<bool></tt> to pass-by-value?</h3> |
| <p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| A number of vector<bool> members take const bool& as arguments. |
| Is there any chance we could change them to pass-by-value or would I |
| be wasting everyone's time if wrote up an issue? |
| </p> |
| |
| <p><i>[ |
| post Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| As we understand it, the original requester (Martin Sebor) would like |
| for implementations to be permitted to pass-by-value. Alisdair suggests |
| that if this is to be resolved, it should be resolved more generally, |
| e.g. in other containers as well. |
| </p> |
| <p> |
| We note that this would break ABI. However, we also suspect that this |
| might be covered under the "as-if" rule in section 1.9. |
| </p> |
| <p> |
| Many in the group feel that for vector<bool>, this is a "don't care", |
| and that at this point in the process it's not worth the bandwidth. |
| </p> |
| <p> |
| Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a> -- which was in ready status pre-Bellevue and is |
| now in the working paper -- is related to this, though not a duplicate. |
| </p> |
| <p> |
| Moving to Open with a task for Alisdair to craft a informative note to |
| be put whereever appropriate in the WP. This note would clarify places |
| where pass-by-const-ref can be transformed to pass-by-value under the |
| as-if rule. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="752"></a>752. Allocator complexity requirement</h3> |
| <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#Review">Review</a> |
| <b>Submitter:</b> Hans Boehm <b>Date:</b> 2007-10-11</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations |
| on the allocators are expected to be amortized constant time."? |
| </p> |
| <p> |
| As I think I pointed out earlier, this is currently fiction for |
| <tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to |
| me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with |
| large objects. Would it be controversial to officially let these take |
| time linear in the size of the object, as they already do in real life? |
| </p> |
| <p> |
| <tt>Allocate()</tt> more blatantly takes time proportional to the size of the |
| object if you mix in GC. But it's not really a new problem, and I think |
| we'd be confusing things by leaving the bogus requirements there. The |
| current requirement on <tt>allocate()</tt> is generally not important anyway, |
| since it takes O(size) to construct objects in the resulting space. |
| There are real performance issues here, but they're all concerned with |
| the constants, not the asymptotic complexity. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 20.1.2 [allocator.requirements]/2: |
| </p> |
| |
| <blockquote> |
| <p> |
| -2- Table 39 describes the requirements on types manipulated through |
| allocators. <del>All the operations on the allocators are expected to be |
| amortized constant time.</del> Table 40 describes the |
| requirements on allocator types. |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="753"></a>753. Move constructor in draft</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Yechezkel Mett <b>Date:</b> 2007-10-14</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The draft standard n2369 uses the term <i>move constructor</i> in a few |
| places, but doesn't seem to define it. |
| </p> |
| |
| <p> |
| <tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as |
| follows: |
| </p> |
| |
| <blockquote> |
| <table border="1"> |
| <caption><tt>MoveConstructible</tt> requirements</caption> |
| <tbody><tr> |
| <th>expression</th> <th>post-condition</th> |
| </tr> |
| <tr> |
| <td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td> |
| </tr> |
| <tr> |
| <td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the |
| construction. <i>-- end note</i>]</td> |
| </tr> |
| </tbody></table> |
| </blockquote> |
| |
| <p> |
| (where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>). |
| </p> |
| |
| <p> |
| So I assume the move constructor is the constructor that would be used |
| in filling the above requirement. |
| </p> |
| |
| <p> |
| For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in |
| 23.2.6.4 [vector.modifiers] we have |
| </p> |
| |
| <blockquote> |
| <i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall |
| not throw any exceptions. |
| </blockquote> |
| |
| <p> |
| Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every |
| type which can be put into a <tt>vector</tt> has a move constructor (a copy |
| constructor is also a move constructor). Secondly it means that for |
| any <tt>value_type</tt> which has a throwing copy constructor and no other move |
| constructor these functions cannot be used -- which I think will come |
| as a shock to people who have been using such types in <tt>vector</tt> until |
| now! |
| </p> |
| |
| <p> |
| I can see two ways to correct this. The simpler, which is presumably |
| what was intended, is to say "If <tt>value_type</tt> has a move constructor and |
| no copy constructor, the move constructor shall not throw any |
| exceptions" or "If <tt>value_type</tt> has a move constructor which changes the |
| value of its parameter,". |
| </p> |
| |
| <p> |
| The other alternative is add to <tt>MoveConstructible</tt> the requirement that |
| the expression does not throw. This would mean that not every type |
| that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the |
| <tt>MoveConstructible</tt> requirements. It would mean changing requirements in |
| various places in the draft to allow either <tt>MoveConstructible</tt> or |
| <tt>CopyConstructible</tt>, but I think the result would be clearer and |
| possibly more concise too. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add new defintions to 17.1 [definitions]: |
| </p> |
| |
| <blockquote> |
| <p> |
| <b>move constructor</b> |
| </p> |
| <p> |
| a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a |
| side effect during the construction. |
| </p> |
| <p> |
| <b>move assignment operator</b> |
| </p> |
| <p> |
| an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a |
| side effect during the assignment. |
| </p> |
| <p> |
| <b>move assignment</b> |
| </p> |
| <p> |
| use of the move assignment operator. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| Howard adds post-Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect. <tt>reserve</tt> et. al. will use a move constructor |
| if one is available, else it will use a copy constructor. A type may have both. If the move constructor is |
| used, it must not throw. If the copy constructor is used, it can throw. The sentence in the proposed wording |
| is correct without the recommended insertion. The Bellevue LWG recommended moving this issue to Ready. I am |
| unfortunately pulling it back to Open. But I'm drafting wording to atone for this egregious action. :-) |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3> |
| <p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> |
| <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-10-31</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Consider the following program: |
| </p> |
| |
| <blockquote><pre>int main() { |
| shared_ptr<int> p(nullptr); |
| return 0; |
| } |
| </pre></blockquote> |
| |
| <p> |
| This program will fail to compile because <tt>shared_ptr</tt> uses the following |
| template constructor to construct itself from pointers: |
| </p> |
| |
| <blockquote><pre>template <class Y> shared_ptr(Y *); |
| </pre></blockquote> |
| |
| <p> |
| According |
| to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>, |
| the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not |
| deducible, so the above constructor will not be found. There are similar problems with the |
| constructors that take a pointer and a <tt>deleter</tt> or a |
| pointer, a <tt>deleter</tt> and an allocator, as well as the |
| corresponding forms of <tt>reset()</tt>. Note that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a> |
| will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use |
| <tt>deleters</tt> or allocators or for <tt>reset()</tt>. |
| </p> |
| |
| <p> |
| In the case of the functions that take deleters, there is the additional |
| question of what argument should be passed to the deleter when it is |
| eventually called. There are two reasonable possibilities: <tt>nullptr</tt> or |
| <tt>static_cast<T *>(0)</tt>, where <tt>T</tt> is the template argument of the |
| <tt>shared_ptr</tt>. It is not immediately clear which of these is better. If |
| <tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s |
| constructor, then <tt>d(static_cast<T*>(0))</tt> will compile and <tt>d(nullptr)</tt> |
| will not. On the other hand, if <tt>D::operator()()</tt> takes a parameter that |
| is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives |
| from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast<T *>(0))</tt> may not. |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| The general idea is right, we need to be able to pass a nullptr to a |
| shared_ptr, but there are a few borderline editorial issues here. (For |
| example, the single-argument nullptr_t constructor in the class synopsis |
| isn't marked explicit, but it is marked explicit in the proposed wording |
| for 20.6.6.2.1. There is a missing empty parenthesis in the form that |
| takes a nullptr_t, a deleter, and an allocator.) |
| </p> |
| <p> |
| More seriously: this issue says that a shared_ptr constructed from a |
| nullptr is empty. Since "empty" is undefined, it's hard to know whether |
| that's right. This issue is pending on handling that term better. |
| </p> |
| <p> |
| Peter suggests definition of empty should be "does not own anything" |
| </p> |
| <p> |
| Is there an editorial issue that post-conditions should refer to get() = |
| nullptr, rather than get() = 0? |
| </p> |
| <p> |
| No strong feeling towards accept or NAD, but prefer to make a decision than leave it open. |
| </p> |
| <p> |
| Seems there are no technical merits between NAD and Ready, comes down to |
| "Do we intentially want to allow/disallow null pointers with these |
| functions". Staw Poll - support null pointers 5 - No null pointers 0 |
| </p> |
| <p> |
| Move to Ready, modulo editorial comments |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| post Bellevue Peter adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| The following wording changes are less intrusive: |
| </p> |
| |
| <p> |
| In 20.7.12.2.1 [util.smartptr.shared.const], add: |
| </p> |
| |
| <blockquote><pre>shared_ptr(nullptr_t); |
| </pre></blockquote> |
| |
| <p> |
| after: |
| </p> |
| |
| <blockquote><pre>shared_ptr(); |
| </pre></blockquote> |
| |
| <p> |
| (Absence of explicit intentional.) |
| </p> |
| |
| <p> |
| <tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so |
| I'm not convinced of its utility. |
| </p> |
| <p> |
| It's similarly not clear to me whether the deleter constructors need to be |
| extended to take <tt>nullptr</tt>, but if they need to: |
| </p> |
| <p> |
| Add |
| </p> |
| |
| <blockquote><pre>template<class D> shared_ptr(nullptr_t p, D d); |
| template<class D, class A> shared_ptr(nullptr_t p, D d, A a); |
| </pre></blockquote> |
| |
| <p> |
| after |
| </p> |
| |
| <blockquote><pre>template<class Y, class D> shared_ptr(Y* p, D d); |
| template<class Y, class D, class A> shared_ptr(Y* p, D d, A a); |
| </pre></blockquote> |
| |
| <p> |
| Note that this changes the semantics of the new constructors such that they |
| consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>. |
| </p> |
| <p> |
| The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt> |
| has repeatedly been requested by users, but the other additions that the |
| proposed resolution makes are not supported by real world demand or |
| motivating examples. |
| </p> |
| <p> |
| It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt> |
| constructor into a separate issue. Waiting for "empty" to be clarified is |
| unnecessary; this is effectively an alias for the default constructor. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| We want to remove the reset functions from the proposed resolution. |
| </p> |
| <p> |
| The remaining proposed resolution text (addressing the constructors) are wanted. |
| </p> |
| <p> |
| Disposition: move to review. The review should check the wording in the then-current working draft. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add the following constructors to 20.7.12.2 [util.smartptr.shared]: |
| </p> |
| |
| <blockquote><pre>shared_ptr(nullptr_t); |
| template <class D> shared_ptr(nullptr_t, D d); |
| template <class D, class A> shared_ptr(nullptr_t, D d, A a); |
| </pre></blockquote> |
| |
| |
| |
| <p> |
| Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]: |
| </p> |
| |
| <blockquote> |
| <pre> explicit shared_ptr(nullptr_t); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Effects:</i> Constructs an empty shared_ptr object. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>use_count() == 0 && get() == 0</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> nothing. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <blockquote> |
| <pre>template <class D> shared_ptr(nullptr_t, D d); |
| template <class D, class A> shared_ptr<nullptr_t, D d, A a); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Requires:</i> <tt>D</tt> shall be <tt>CopyConstructible</tt>. The copy constructor and |
| destructor of <tt>D</tt> shall not throw exceptions. The expression |
| <tt>d(static_cast<T *>(0))</tt> shall be well-formed, shall have well defined behavior, |
| and shall not throw exceptions. <tt>A</tt> shall be an allocator (20.1.2 [allocator.requirements]). |
| The copy constructor and destructor of <tt>A</tt> shall not throw |
| exceptions. |
| </p> |
| <p> |
| <i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that owns a null pointer of type <tt>T *</tt> |
| and deleter <tt>d</tt>. The |
| second constructor shall use a copy of <tt>a</tt> to allocate memory for |
| internal use. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>use_count() == 1</tt> and <tt>get() == 0</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> <tt>bad_alloc</tt>, or an implementation-defined exception when a |
| resource other than memory could not be obtained. |
| </p> |
| <p> |
| <i>Exception safety:</i> If an exception is thrown, <tt>d(static_cast<Y *>(nullptr))</tt> is called. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="760"></a>760. The emplace issue</h3> |
| <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#Open">Open</a> |
| <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-11</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In an emplace member function the function parameter pack may be bound |
| to a priori unlimited number of objects: some or all of them can be |
| elements of the container itself. Apparently, in order to conform to the |
| blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for |
| that possibility. A possible solution can involve extending the |
| exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the |
| <tt>push_back</tt> and <tt>push_front</tt> member functions are luckily not affected by |
| this problem, can be efficiently implemented anyway |
| </p> |
| |
| <p><i>[ |
| Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a> |
| ]</i></p> |
| |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| The proposed addition (13) is partially redundant with the existing |
| paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why |
| does it not cover subelements and pointers? |
| </p> |
| <p> |
| Resolution: Alan Talbot to rework language, then set state to Review. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add after 23.1 [container.requirements]/12: |
| </p> |
| |
| <blockquote> |
| <p> |
| -12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No |
| diagnostic required. |
| </p> |
| <p> |
| <ins> |
| -13- Objects bound to the function parameter pack of the <tt>emplace</tt> member function shall not be elements or |
| sub-objects of elements of the container. No diagnostic required. |
| </ins> |
| </p> |
| |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3> |
| <p><b>Section:</b> 20.7.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-11-30</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt> |
| does currently not support incomplete types, because it |
| gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with |
| an incomplete pointee type <tt>T</tt> automatically belongs to |
| undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last |
| bullet. This is an unnecessary restriction and prevents |
| many well-established patterns - like the bridge pattern - |
| for <tt>std::unique_ptr</tt>. |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Move to open. The LWG is comfortable with the intent of allowing |
| incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are |
| not comfortable with the wording. The specification for <tt>unique_ptr</tt> |
| should be more like that of <tt>shared_ptr</tt>. We need to know, for individual |
| member functions, which ones require their types to be complete. The |
| <tt>shared_ptr</tt> specification is careful to say that for each function, and |
| we need the same level of care here. We also aren't comfortable with the |
| "part of the operational semantic" language; it's not used elsewhere in |
| the standard, and it's not clear what it means. We need a volunteer to |
| produce new wording. |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| The proposed changes in the following revision refers to the current state of |
| N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed |
| according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>. |
| </p> |
| <p> |
| The specialization <tt>unique_ptr<T[]></tt> has some more restrictive constraints on |
| type-completeness on <tt>T</tt> than <tt>unique_ptr<T></tt>. The following proposed wordings |
| try to cope with that. If the committee sees less usefulness on relaxed |
| constraints on <tt>unique_ptr<T[]></tt>, the alternative would be to stop this relaxation |
| e.g. by adding one further bullet to 20.7.11.3 [unique.ptr.runtime]/1: |
| "<tt>T</tt> shall be a complete type, if used as template argument of |
| <tt>unique_ptr<T[], D></tt> |
| </p> |
| <p> |
| This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, but it seems not to cause any |
| problems with this one, |
| because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict |
| with the here discussed |
| ones, provided that <tt>D::pointer</tt>'s operations (including default |
| construction, copy construction/assignment, |
| and pointer conversion) are specified <em>not</em> to throw, otherwise this |
| would have impact on the |
| current specification of <tt>unique_ptr</tt>. |
| </p> |
| |
| <ol> |
| <li> |
| <p> |
| In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para: |
| </p> |
| |
| <blockquote> |
| The <tt>unique_ptr</tt> provides a semantics of strict ownership. A |
| <tt>unique_ptr</tt> owns the object it holds a pointer to. A |
| <tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor |
| <tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and |
| <tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of |
| <tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The |
| uses of <tt>unique_ptr</tt> include providing exception safety for |
| dynamically allcoated memory, passing ownership of dynamically allocated |
| memory to a function, and returning dynamically allocated memory from a |
| function. -- <i>end note</i> ] |
| </blockquote> |
| </li> |
| |
| <li> |
| <p> |
| 20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary. |
| </p> |
| |
| <blockquote> |
| <p><i>[ |
| N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>. |
| The current wording says just this. |
| ]</i></p> |
| |
| </blockquote> |
| </li> |
| |
| <li> |
| <p> |
| In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say: |
| </p> |
| |
| <blockquote> |
| <p> |
| <i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor |
| of <tt>D</tt> shall not throw an exception.</del> |
| <del><tt>D</tt> must not be a reference type.</del> |
| <ins> |
| <tt>D</tt> shall be default constructible, and that construction |
| shall not throw an exception. |
| </ins> |
| </p> |
| <p><i>[ |
| N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at |
| this point. I assume that the current wording is based on the |
| corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this |
| requirement is necessary, because the corresponding c'tor *can* fail |
| and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in |
| this regard. The *only* functions that must insist on well-formedness |
| and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1) |
| the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to |
| explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that |
| invocation of |
| <tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that |
| we do *not* need the |
| requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>. |
| <tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which |
| potentially requires <tt>Convertible<Y*, X*></tt>, which |
| again requires Completeness of <tt>Y</tt>, if <tt>!SameType<X, Y></tt> |
| ]</i></p> |
| |
| </blockquote> |
| </li> |
| |
| <li> |
| <p> |
| Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence |
| of 12, but transferring the "requires" to 13: |
| </p> |
| |
| <blockquote> |
| <p> |
| <i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..] |
| </p> |
| <p><i>[ |
| N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is |
| well-formed/well-defined at this point. The current wording guarantees |
| all what we need, namely that the initialization of both the <tt>T*</tt> |
| pointer and the <tt>D</tt> deleter are well-formed and well-defined. |
| ]</i></p> |
| |
| </blockquote> |
| </li> |
| |
| <li> |
| 20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary. |
| </li> |
| <li> |
| <p>20.7.11.2.1 [unique.ptr.single.ctor]/21:</p> |
| |
| <blockquote> |
| <i>Requires:</i> If <tt>D</tt> is not a reference type, construction of |
| the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well |
| formed and shall not throw an exception. If <tt>D</tt> is a reference |
| type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic |
| required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>. |
| <ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt> |
| be complete types. <i>-- end note</i>]</ins> |
| </blockquote> |
| |
| <p><i>[ |
| N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt> |
| is completely defined, because it requires that <tt>Convertible<U*, T*></tt> is |
| true. If the committee wishes this explicit requirement can be added, |
| e.g. "<tt>U</tt> shall be a complete type." |
| ]</i></p> |
| |
| </li> |
| |
| <li> |
| <p> |
| 20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph: |
| </p> |
| <blockquote> |
| <p> |
| <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed, |
| shall have well-defined behavior, and shall not throw exceptions. |
| <ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to |
| be a complete type. <i>-- end note</i>]</ins> |
| </p> |
| <p><i>[ |
| N.B.: This requirement ensures that the whole responsibility on |
| type-completeness of <tt>T</tt> is delegated to this expression. |
| ]</i></p> |
| |
| </blockquote> |
| </li> |
| |
| <li> |
| <p> |
| 20.7.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the |
| current editorial issue, that "must shall" has to be changed to |
| "shall", but this change is not a special part of this resolution. |
| </p> |
| |
| <p><i>[ |
| N.B. The current wording is sufficient, because we can delegate all |
| further requirements on the requirements of the effects clause |
| ]</i></p> |
| |
| </li> |
| |
| <li> |
| <p> |
| 20.7.11.2.3 [unique.ptr.single.asgn]/6: |
| </p> |
| |
| <blockquote> |
| <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue |
| <tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly |
| convertible to <tt>T*</tt>. |
| <ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt> |
| be complete types. <i>-- end note</i>]</ins> |
| </blockquote> |
| |
| <p><i>[ |
| N.B.: The current wording of p. 6 already implicitly guarantees that |
| <tt>U</tt> is completely defined, because it requires that <tt>Convertible<U*, T*></tt> |
| is true, see (6)+(8). |
| ]</i></p> |
| |
| </li> |
| |
| <li> |
| <p> |
| 20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary. |
| </p> |
| <p><i>[ |
| N.B.: Delegation to requirements of effects clause is sufficient. |
| ]</i></p> |
| |
| </li> |
| |
| <li> |
| 20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: |
| </li> |
| |
| <blockquote> |
| <pre>T* operator->() const;</pre> |
| <blockquote> |
| <ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins> |
| </blockquote> |
| </blockquote> |
| |
| <li> |
| 20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary. |
| </li> |
| |
| <li> |
| <p> |
| 20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph: |
| </p> |
| <blockquote> |
| <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed, |
| shall have well-defined behavior, and shall not throw exceptions. |
| </blockquote> |
| </li> |
| |
| <li> |
| 20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary. |
| </li> |
| |
| <li> |
| <p> |
| 20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1: |
| </p> |
| |
| <blockquote> |
| <p> |
| A specialization for array types is provided with a slightly altered interface. |
| </p> |
| |
| <ul> |
| <li> |
| ... |
| </li> |
| <li> |
| <ins><tt>T</tt> shall be a complete type.</ins> |
| </li> |
| </ul> |
| </blockquote> |
| </li> |
| </ol> |
| |
| <p><i>[ |
| post Bellevue: Daniel provided revised wording. |
| ]</i></p> |
| |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="765"></a>765. more on iterator validity</h3> |
| <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#New">New</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-12-14</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> |
| defines the meaning of the term "invalid iterator" as one that may be |
| singular. |
| |
| </p> |
| <p> |
| |
| Consider the following code: |
| |
| </p> |
| <pre> std::deque<int> x, y; |
| std::deque<int>::iterator i = x.end(), j = y.end(); |
| x.swap(y); |
| </pre> |
| <p> |
| |
| Given that <code>swap()</code> is required not to invalidate iterators |
| and using the definition above, what should be the expected result of |
| comparing <code>i</code> and <code>j</code> to <code>x.end()</code> |
| and <code>y.end()</code>, respectively, after the <code>swap()</code>? |
| |
| </p> |
| <p> |
| |
| I.e., is the expression below required to evaluate |
| to <code>true</code>? |
| |
| </p> |
| <pre> i == y.end() && j == x.end() |
| </pre> |
| <p> |
| |
| (There are at least two implementations where the expression |
| returns <code>false</code>.) |
| |
| </p> |
| <p> |
| |
| More generally, is the definition introduced in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> meant to |
| make any guarantees about whether iterators actually point to the same |
| elements or be associated with the same containers after a |
| non-invalidating operation as they did before? |
| |
| </p> |
| <p> |
| |
| Here's a motivating example intended to demonstrate the importance of |
| the question: |
| |
| </p> |
| <pre> Container x, y ({ 1, 2}); // pseudocode to initialize y with { 1, 2 } |
| Container::iterator i = y.begin() + 1; |
| Container::iterator j = y.end(); |
| std::swap(x, y); |
| std::find(i, j, 3); |
| </pre> |
| <p> |
| |
| <code>swap()</code> guarantees that <code>i</code> and <code>j</code> |
| continue to be valid. Unless the spec says that even though they are |
| valid they may no longer denote a valid range the code above must be |
| well-defined. Expert opinions on this differ as does the behavior of |
| popular implementations for some standard <code>Containers</code>. |
| |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3> |
| <p><b>Section:</b> 20.6.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed |
| (implicit) conversion operator to "unspecified-bool-type" by the new |
| explicit bool conversion, but the inverse conversion should also |
| use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer- |
| type". |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| In 20.6 [function.objects], header <tt><functional></tt> synopsis replace: |
| </p> |
| |
| <blockquote><pre>template<class R, class... ArgTypes> |
| bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); |
| template<class R, class... ArgTypes> |
| bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&); |
| template<class R, class... ArgTypes> |
| bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); |
| template<class R, class... ArgTypes> |
| bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&); |
| </pre></blockquote> |
| |
| <p> |
| In the class function synopsis of 20.6.15.2 [func.wrap.func] replace |
| </p> |
| |
| <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); |
| ... |
| function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); |
| </pre></blockquote> |
| |
| <p> |
| In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace: |
| </p> |
| |
| <blockquote><pre>template <class R, class... ArgTypes> |
| bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); |
| template <class R, class... ArgTypes> |
| bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&); |
| template <class R, class... ArgTypes> |
| bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); |
| template <class R, class... ArgTypes> |
| bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&); |
| </pre></blockquote> |
| |
| <p> |
| In 20.6.15.2.1 [func.wrap.func.con], replace |
| </p> |
| |
| <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); |
| ... |
| function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); |
| </pre></blockquote> |
| |
| <p> |
| In 20.6.15.2.6 [func.wrap.func.nullptr], replace |
| </p> |
| |
| <blockquote><pre>template <class R, class... ArgTypes> |
| bool operator==(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); |
| template <class R, class... ArgTypes> |
| bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f); |
| </pre></blockquote> |
| |
| <p> |
| and replace |
| </p> |
| |
| <blockquote><pre>template <class R, class... ArgTypes> |
| bool operator!=(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); |
| template <class R, class... ArgTypes> |
| bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f); |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3> |
| <p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.4 [string.conversions] |
| have throws clauses (paragraphs 8 and 16) which say: |
| </p> |
| |
| <blockquote> |
| <i>Throws:</i> nothing |
| </blockquote> |
| |
| <p> |
| Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value |
| this throws clause is impossible to realize in general, since the <tt>basic_string</tt> |
| constructors can fail due to out-of-memory conditions. Either these throws |
| clauses should be removed or should be more detailled like: |
| </p> |
| |
| <blockquote> |
| <i>Throws:</i> Nothing if the string construction throws nothing |
| </blockquote> |
| |
| <p> |
| Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt> |
| overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The |
| header <tt><string></tt> synopsis of 21.2 [string.classes] is correct in this |
| regard). |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 21.4 [string.conversions], remove the paragraphs 8 and 16. |
| </p> |
| |
| <blockquote> |
| <pre>string to_string(long long val); |
| string to_string(unsigned long long val); |
| string to_string(long double val); |
| </pre> |
| <blockquote> |
| <del><i>Throws:</i> nothing</del> |
| </blockquote> |
| </blockquote> |
| |
| <blockquote> |
| <pre><ins>w</ins>string to_wstring(long long val); |
| <ins>w</ins>string to_wstring(unsigned long long val); |
| <ins>w</ins>string to_wstring(long double val); |
| </pre> |
| <blockquote> |
| <del><i>Throws:</i> nothing</del> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="772"></a>772. Impossible return clause in [string.conversions]</h3> |
| <p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt> |
| overloads says: |
| </p> |
| |
| <blockquote> |
| <i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character |
| representation of the value of its argument that would be generated by |
| calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>, |
| or <tt>L"%f"</tt>, respectively. |
| </blockquote> |
| |
| <p> |
| Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked |
| the 2nd edition of ISO 9899, and the first and the second corrigenda from |
| 2001-09-01 and 2004-11-15). What probably meant here is the function |
| <tt>swprintf</tt> from <tt><wchar.h>/<cwchar></tt>, but this has the non-equivalent |
| declaration: |
| </p> |
| |
| <blockquote><pre>int swprintf(wchar_t * restrict s, size_t n, |
| const wchar_t * restrict format, ...); |
| </pre></blockquote> |
| |
| <p> |
| therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change the current wording of 21.4 [string.conversions]/p. 15 to: |
| </p> |
| |
| <blockquote> |
| <i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a |
| <tt>wstring</tt> object holding the character representation of the |
| value of its argument that would be generated by calling |
| <tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt, |
| val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>, |
| <tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt> |
| designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>. |
| </blockquote> |
| |
| <p> |
| [Hint to the editor: The resolution also adds to mention the name of |
| the format specifier "fmt"] |
| </p> |
| |
| <p> |
| I also would like to remark that the current wording of it's equivalent |
| paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>. |
| </p> |
| |
| <p> |
| Change the current wording of 21.4 [string.conversions]/p. 7 to: |
| </p> |
| |
| <blockquote> |
| <i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the |
| character representation of the value of its argument that would be |
| generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of |
| <tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal |
| character buffer of sufficient size</ins>. |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="774"></a>774. Member swap undefined for most containers</h3> |
| <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-14</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| It appears most containers declare but do not define a member-swap |
| function. |
| </p> |
| |
| <p> |
| This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the |
| member-swap function! |
| (required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements |
| [Table 87]) |
| </p> |
| |
| <p> |
| Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>, |
| yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular |
| definition. |
| </p> |
| |
| <p> |
| A quick survey of clause 23 shows that the following containers provide a |
| definition for member-swap: |
| </p> |
| |
| <blockquote><pre>array |
| queue |
| stack |
| vector |
| </pre></blockquote> |
| |
| <p> |
| Whereas the following declare it, but do not define the semantics: |
| </p> |
| |
| <blockquote><pre>deque |
| list |
| map |
| multimap |
| multiset |
| priority_queue |
| set |
| unordered_map |
| unordered_multi_map |
| unordered_multi_set |
| unordered_set |
| </pre></blockquote> |
| |
| <p> |
| Suggested resolution: |
| </p> |
| <blockquote> |
| Provide a definition for each of the affected containers... |
| </blockquote> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Move to Open and ask Alisdair to provide wording. |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Wording provided in |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>. |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="776"></a>776. Undescribed assign function of std::array</h3> |
| <p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-20</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The class template array synopsis in 23.2.1 [array]/3 declares a member |
| function |
| </p> |
| |
| <blockquote><pre>void assign(const T& u); |
| </pre></blockquote> |
| |
| <p> |
| which's semantic is no-where described. Since this signature is |
| not part of the container requirements, such a semantic cannot |
| be derived by those. |
| </p> |
| |
| <p> |
| I found only one reference to this function in the issue list, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised: |
| </p> |
| |
| <blockquote> |
| what's the effect of calling <tt>assign(T&)</tt> on a zero-sized array? |
| </blockquote> |
| |
| <p> |
| which does not answer the basic question of this issue. |
| </p> |
| |
| <p> |
| If this function shall be part of the <tt>std::array</tt>, it's probable |
| semantic should correspond to that of <tt>boost::array</tt>, but of |
| course such wording must be added. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Just after the section 23.2.1.4 [array.data] add the following new section: |
| </p> |
| |
| <p> |
| 23.2.1.5 array::fill [array.fill] |
| </p> |
| |
| <blockquote> |
| <pre>void fill(const T& u); |
| </pre> |
| |
| <p> |
| 1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt> |
| </p> |
| </blockquote> |
| |
| <p> |
| [N.B: I wonder, why class <tt>array</tt> does not have a "modifiers" |
| section. If it had, then <tt>assign</tt> would naturally belong to it] |
| </p> |
| |
| <p> |
| Change the synopsis in 23.2.1 [array]/3: |
| </p> |
| |
| <blockquote><pre>template <class T, size_t N> |
| struct array { |
| ... |
| void <del>assign</del> <ins>fill</ins>(const T& u); |
| ... |
| </pre></blockquote> |
| |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Suggest substituting "fill" instead of "assign". |
| </p> |
| <p> |
| Set state to Review given substitution of "fill" for "assign". |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="779"></a>779. Resolution of #283 incomplete</h3> |
| <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#Ready">Ready</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm |
| <tt>remove_copy[_if]</tt>, |
| which seems to be an oversight. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with: |
| </p> |
| |
| <blockquote> |
| <i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt> |
| and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be |
| valid.</ins> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3> |
| <p><b>Section:</b> 25.3.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open: |
| </p> |
| |
| <p> |
| Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461 |
| have no Requires element and the Effects element contains some requirements, |
| which is probably editorial. Worse is that: |
| </p> |
| |
| <ul> |
| <li> |
| no assignment requirements are specified (neither implicit nor explicit). |
| </li> |
| |
| <li> |
| the effects clause just speaks of "merges", which is badly worded |
| near to a circular definition. |
| </li> |
| |
| <li> |
| p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the |
| function arguments or otherwise. |
| </li> |
| |
| <li> |
| p. 2 says "according to the ordering defined by comp" which is both |
| incomplete (because |
| this excludes the first variant with <) and redundant (because the |
| following subordinate |
| clause mentions comp again) |
| </li> |
| </ul> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 25.3.4 [alg.merge] replace p.1+ 2: |
| </p> |
| |
| <blockquote> |
| <p> |
| <i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and |
| <tt>[first2,last2)</tt> into the range |
| <del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del> |
| <ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1 |
| - first1) + (last2 - first2))</tt>, such that resulting range will be |
| sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in |
| <tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i < *(i - 1)</tt> or, |
| respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>. |
| </p> |
| |
| <p> |
| <ins><i>Requires:</i></ins> The resulting range shall not overlap with either of the original ranges. <del>The list will be sorted in non-decreasing |
| order according to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt> in |
| <tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i < *(i - 1)</tt> or |
| <tt>comp(*i, *(i - 1))</tt> will be false.</del> <ins>The results of the expressions <tt>*first1</tt> and <tt>*first2</tt> |
| shall be writable to the output iterator.</ins> |
| </p> |
| </blockquote> |
| |
| <p> |
| [N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>, |
| therefore proposing to |
| insert ", respectively," between both predicate tests. This is no |
| strictly necessary as |
| other parts of <tt><algorithm></tt> show, just a matter of consistency] |
| </p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="785"></a>785. Random Number Requirements in TR1</h3> |
| <p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> John Maddock <b>Date:</b> 2008-01-15</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Table 16 of TR1 requires that all Pseudo Random Number generators have a |
| </p> |
| |
| <blockquote><pre>seed(integer-type s) |
| </pre></blockquote> |
| |
| <p> |
| member function that is equivalent to: |
| </p> |
| |
| <blockquote><pre>mygen = Generator(s) |
| </pre></blockquote> |
| |
| <p> |
| But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the |
| </p> |
| |
| <blockquote><pre>template <class Gen> |
| seed(Gen&); |
| </pre></blockquote> |
| |
| <p> |
| member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16. |
| </p> |
| |
| <p> |
| So... is this a bug in TR1? |
| </p> |
| |
| <p>This is a real issue BTW, since the Boost implementation does adhere |
| to the requirements of Table 16, while at least one commercial |
| implementation does not and follows a strict adherence to sections |
| 5.1.4.5 and 5.1.4.6 instead. |
| </p> |
| |
| <p><i>[ |
| Jens adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Both engines do have the necessary |
| constructor, therefore the omission of the <tt>seed()</tt> member |
| functions appears to be an oversight. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3> |
| <p><b>Section:</b> 25.3.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-08</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as |
| </p> |
| |
| <blockquote> |
| At most <tt>log(last - first) + 2</tt> comparisons. |
| </blockquote> |
| |
| <p> |
| This should be precised and brought in line with the nomenclature used for |
| <tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>. |
| </p> |
| |
| <p> |
| All existing libraries I'm aware of, delegate to |
| <tt>lower_bound</tt> (+ one further comparison). Since |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> |
| has now WP status, the resolution of #787 should |
| be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt> |
| to <tt>+ O(1)</tt>. |
| </p> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Alisdair prefers to apply an upper bound instead of O(1), but that would |
| require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really |
| cares about it, he'll send an issue to Howard. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 25.3.3.4 [binary.search]/3 |
| </p> |
| |
| <blockquote> |
| <i>Complexity:</i> At most <tt>log<ins><sub>2</sub></ins>(last - first) + <del>2</del> <ins><i>O</i>(1)</ins></tt> comparisons. |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3> |
| <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#New">New</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-02-06</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The description of how an istream_iterator object becomes an |
| end-of-stream iterator is a) ambiguous and b) out of date WRT |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>: |
| </p> |
| |
| <blockquote> |
| <tt>istream_iterator</tt> reads (using <tt>operator>></tt>) successive elements from the |
| input stream for which it was constructed. After it is constructed, and |
| every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If |
| the end of stream is reached (<tt>operator void*()</tt> on the stream returns |
| <tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value. |
| The constructor with no arguments <tt>istream_iterator()</tt> always constructs |
| an end of stream input iterator object, which is the only legitimate |
| iterator to be used for the end condition. The result of <tt>operator*</tt> on an |
| end of stream is not defined. For any other iterator value a <tt>const T&</tt> is |
| returned. The result of <tt>operator-></tt> on an end of stream is not defined. |
| For any other iterator value a <tt>const T*</tt> is returned. It is impossible to |
| store things into istream iterators. The main peculiarity of the istream |
| iterators is the fact that <tt>++</tt> operators are not equality preserving, |
| that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt> |
| is used a new value is read. |
| </blockquote> |
| |
| <p> |
| <tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>, |
| otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or |
| <tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't |
| necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after |
| extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will |
| have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator |
| void*()</tt> will return a non-null value). |
| </p> |
| |
| <p> |
| Also I would prefer to be explicit about calling <tt>fail()</tt> here |
| (there is no <tt>operator void*()</tt> anymore.) |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 24.5.1 [istream.iterator]/1: |
| </p> |
| |
| <blockquote> |
| <tt>istream_iterator</tt> reads (using <tt>operator>></tt>) successive elements from the |
| input stream for which it was constructed. After it is constructed, and |
| every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If |
| <del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins> |
| (<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns |
| <tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value. |
| The constructor with no arguments <tt>istream_iterator()</tt> always constructs |
| an end of stream input iterator object, which is the only legitimate |
| iterator to be used for the end condition. The result of <tt>operator*</tt> on an |
| end of stream is not defined. For any other iterator value a <tt>const T&</tt> is |
| returned. The result of <tt>operator-></tt> on an end of stream is not defined. |
| For any other iterator value a <tt>const T*</tt> is returned. It is impossible to |
| store things into istream iterators. The main peculiarity of the istream |
| iterators is the fact that <tt>++</tt> operators are not equality preserving, |
| that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt> |
| is used a new value is read. |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3> |
| <p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <tt>discrete_distribution</tt> should have a constructor like: |
| </p> |
| |
| <blockquote><pre>template<class _Fn> |
| discrete_distribution(result_type _Count, double _Low, double _High, |
| _Fn& _Func); |
| </pre></blockquote> |
| |
| <p> |
| (Makes it easier to fill a histogram with function values over a range.) |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| How do you specify the function so that it does not return negative |
| values? If you do it is a bad construction. This requirement is already |
| there. Where in each bin does one evaluate the function? In the middle. |
| Need to revisit tomorrow. |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Bill is not requesting this. |
| </p> |
| <p> |
| Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the |
| function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot |
| return 0 everywhere it is sampled. |
| </p> |
| <p> |
| Jens: lambda expressions are rvalues |
| </p> |
| <p> |
| Add a library issue to provide an |
| <tt>initializer_list<double></tt> constructor for |
| <tt>discrete_distribution</tt>. |
| </p> |
| <p> |
| Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda), |
| use <tt>std::ref</tt> to wrap giant-state function objects. |
| </p> |
| <p> |
| Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference. |
| </p> |
| <p> |
| Daniel to draft wording. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| Pre San Francisco, Daniel provided wording: |
| ]</i></p> |
| |
| |
| <blockquote> |
| The here proposed changes of the WP refer to the current state of |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>. |
| During the Sophia Antipolis meeting two different proposals came up |
| regarding the functor argument type, either by value or by rvalue-reference. |
| For consistence with existing conventions (state-free algorithms and the |
| <tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a |
| function argument that is provided by value. If severe concerns exists that |
| stateful functions would be of dominant relevance, it should be possible to |
| replace the two occurrences of <tt>Func</tt> by <tt>Func&&</tt> in this proposal as part |
| of an editorial process. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <ol> |
| <li> |
| <p> |
| In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just |
| <em>before</em> the member declaration |
| </p> |
| |
| <blockquote><pre>explicit discrete_distribution(const param_type& parm); |
| </pre></blockquote> |
| |
| <p> |
| insert: |
| </p> |
| |
| |
| <blockquote><pre>template<typename Func> |
| discrete_distribution(result_type nf, double xmin, double xmax, Func fw); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p> |
| Between p.4 and p.5 insert a series of new paragraphs as part of the |
| new member description:: |
| </p> |
| <blockquote><pre>template<typename Func> |
| discrete_distribution(result_type nf, double xmin, double xmax, Func fw); |
| </pre> |
| |
| <p> |
| <i>Complexity:</i> Exactly nf invocations of fw. |
| </p> |
| <p> |
| <i>Requires:</i> |
| </p> |
| <ol type="a"> |
| <li> |
| fw shall be callable with one argument of type double, and shall |
| return values of a type convertible to double;</li> |
| |
| <li>If nf > 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> < <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values |
| <tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN, |
| and non-infinity;</li> |
| |
| <li>The following relations shall hold: nf ≥ 0, and 0 < S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li> |
| |
| </ol> |
| |
| <p> |
| <i>Effects:</i> |
| </p> |
| <ol type="a"> |
| <li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and |
| consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li> |
| |
| <li> |
| <p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> + |
| 0.5 * deltax.</p> |
| <blockquote><pre>For each k = 0, . . . ,n-1, calculates: |
| <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax |
| <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>) |
| </pre></blockquote> |
| </li> |
| <li> |
| <p>Constructs a discrete_distribution object with probabilities:</p> |
| <blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S for k = 0, . . . , n-1. |
| </pre></blockquote> |
| </li> |
| </ol> |
| </blockquote> |
| </li> |
| </ol> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3> |
| <p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <tt>piecewise_constant_distribution</tt> should have a constructor like: |
| </p> |
| |
| <blockquote><pre>template<class _Fn> |
| piecewise_constant_distribution(size_t _Count, |
| _Ty _Low, _Ty _High, _Fn& _Func); |
| </pre></blockquote> |
| |
| <p> |
| (Makes it easier to fill a histogram with function values over a range. |
| The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>) make a sensible replacement for |
| <tt>general_pdf_distribution</tt>.) |
| </p> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Marc: uses variable width of bins and weight for each bin. This is not |
| giving enough flexibility to control both variables. |
| </p> |
| <p> |
| Add a library issue to provide an constructor taking an |
| <tt>initializer_list<double></tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>. |
| </p> |
| <p> |
| Daniel to draft wording. |
| </p> |
| </blockquote> |
| |
| <p><i>[ |
| Pre San Francisco, Daniel provided wording. |
| ]</i></p> |
| |
| |
| <blockquote> |
| The here proposed changes of the WP refer to the current state of |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>. |
| For reasons explained in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, the author decided to propose a function |
| argument that is provided by value. The issue proposes a c'tor signature, |
| that does not take advantage of the full flexibility of |
| <tt>piecewise_constant_distribution</tt>, |
| because it restricts on a constant bin width, but the use-case seems to |
| be popular enough to justify it's introduction. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <ol> |
| <li> |
| <p> |
| In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>, |
| just <em>before</em> the member declaration |
| </p> |
| |
| <blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm); |
| </pre></blockquote> |
| <p> |
| insert: |
| </p> |
| <blockquote><pre>template<typename Func> |
| piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p> |
| Between p.4 and p.5 insert a new sequence of paragraphs nominated |
| below as [p5_1], [p5_2], |
| [p5_3], and [p5_4] as part of the new member description: |
| </p> |
| |
| <blockquote><pre>template<typename Func> |
| piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw); |
| </pre> |
| <blockquote> |
| <p> |
| [p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>. |
| </p> |
| <p> |
| [p5_2] <i>Requires:</i> |
| </p> |
| <ol type="a"> |
| <li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall |
| return values of a type convertible to double; |
| </li> |
| <li> |
| For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight |
| value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity; |
| </li> |
| <li> |
| The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> < <tt><i>x<sub>max</sub></i></tt>, and |
| 0 < S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>. |
| </li> |
| </ol> |
| <p> |
| [p5_3] <i>Effects:</i> |
| </p> |
| <ol type="a"> |
| <li> |
| <p>If nf == 0,</p> |
| <ol type="a"> |
| <li> |
| sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li> |
| <li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single |
| value <tt><i>w<sub>0</sub></i></tt> = 1, and</li> |
| <li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and |
| <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt> |
| </li> |
| </ol> |
| </li> |
| <li> |
| <p>Otherwise,</p> |
| <ol type="a"> |
| <li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n, |
| <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and |
| </li> |
| <li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p> |
| <blockquote><pre>for each k = 0, . . . ,n-1, calculates: |
| <tt><i>dx<sub>k</sub></i></tt> = k * deltax |
| <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt> |
| <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt> |
| <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>), |
| </pre></blockquote> |
| <p> and</p> |
| </li> |
| <li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li> |
| </ol> |
| </li> |
| <li> |
| <p> |
| Constructs a <tt>piecewise_constant_distribution</tt> object with |
| the above computed sequence <tt>b</tt> as the interval boundaries |
| and with the probability densities: |
| </p> |
| <blockquote><pre><tt><i>ρ<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax) for k = 0, . . . , n-1. |
| </pre></blockquote> |
| </li> |
| </ol> |
| <p> |
| [p5_4] <i>Remarks:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly |
| known as the <i>bins</i> of a histogram. |
| </p> |
| </blockquote> |
| </blockquote> |
| </li> |
| </ol> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3> |
| <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is |
| defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities. |
| Previous versions of this algorithm and the general logic behind it |
| suggest that this is an oversight and that in the context of the |
| for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded |
| upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits |
| in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt> |
| to 0. |
| </p> |
| |
| <p> |
| There are two more minor issues: |
| </p> |
| |
| <ul> |
| <li> |
| Strictly speaking <tt>end - begin</tt> is not defined since |
| <tt>InputIterator</tt> is not required to be a random access iterator. |
| </li> |
| <li> |
| Currently all integral types are allowed as input to the <tt>seed_seq</tt> |
| constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily |
| complicates the implementation without any real benefit to the user. |
| I'd suggest to exclude <tt>bool</tt>s as input. |
| </li> |
| </ul> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Move to OPEN Bill will try to propose a resolution by the next meeting. |
| </blockquote> |
| |
| <p><i>[ |
| post Bellevue: Bill provided wording. |
| ]</i></p> |
| |
| |
| <p> |
| This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> is accepted. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with: |
| </p> |
| |
| <blockquote> |
| <p> |
| <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the |
| low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin, |
| end)</tt> |
| in ascending order of significance to make a (possibly very large) unsigned |
| binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the |
| following |
| algorithm: |
| </p> |
| |
| <blockquote><pre>for( v.clear(); n > 0; n -= 32 ) |
| v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>; |
| </pre></blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3> |
| <p><b>Section:</b> 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Classes with trivial special member functions are inherently more |
| efficient than classes without such functions. This efficiency is |
| particularly pronounced on modern ABIs that can pass small classes |
| in registers. Examples include value classes such as complex numbers |
| and floating-point intervals. Perhaps more important, though, are |
| classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>. When the |
| parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s |
| themselves can be trivial, leading to substantial performance wins. |
| </p> |
| <p> |
| The current working draft make specification of trivial functions |
| (where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions. |
| As long as the semantics of defaulted and deleted functions match |
| the intended semantics, specification of defaulted and deleted |
| functions will yield more efficient programs. |
| </p> |
| <p> |
| There are at least two cases where specification of an explicitly |
| defaulted function may be desirable. |
| </p> |
| <p> |
| First, the <tt>std::pair</tt> template has a non-trivial default constructor, |
| which prevents static initialization of the pair even when the |
| types are statically initializable. Changing the definition to |
| </p> |
| |
| <blockquote><pre>pair() = default; |
| </pre></blockquote> |
| |
| <p> |
| would enable such initialization. Unfortunately, the change is |
| not semantically neutral in that the current definition effectively |
| forces value initialization whereas the change would not value |
| initialize in some contexts. |
| </p> |
| |
| <p> |
| ** Does the committee confirm that forced value initialization |
| was the intent? If not, does the committee wish to change the |
| behavior of <tt>std::pair</tt> in C++0x? |
| </p> |
| <p> |
| Second, the same default constructor issue applies to <tt>std::tuple</tt>. |
| Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial, |
| which effectively prevents passing it in registers. To enable |
| passing <tt>tuples</tt> in registers, the copy constructor should be |
| make explicitly <tt>default</tt>ed. The new declarations are: |
| </p> |
| |
| <blockquote><pre>tuple() = default; |
| tuple(const tuple&) = default; |
| </pre></blockquote> |
| |
| <p> |
| This changes is not implementation neutral. In particular, it |
| prevents implementations based on pointers to the parameter |
| types. It does however, permit implementations using the |
| parameter types as bases. |
| </p> |
| <p> |
| ** How does the committee wish to trade implementation |
| efficiency versus implementation flexibility? |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| General agreement; the first half of the issue is NAD. |
| </p> |
| <p> |
| Before voting on the second half, it was agreed that a "Strongly Favor" |
| vote meant support for trivial tuples (assuming usual requirements met), |
| even at the expense of other desired qualities. A "Weakly Favor" vote |
| meant support only if not at the expense of other desired qualities. |
| </p> |
| <p> |
| Concensus: Go forward, but not at expense of other desired qualities. |
| </p> |
| <p> |
| It was agreed to Alisdair should fold this work in with his other |
| pair/tuple action items, above, and that issue 801 should be "open", but |
| tabled until Alisdair's proposals are disposed of. |
| </p> |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3> |
| <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> |
| <b>Submitter:</b> Charles Karney <b>Date:</b> 2008-02-22</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt> |
| object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a |
| 32-bit vector. |
| </p> |
| <p> |
| This repacking triggers several problems: |
| </p> |
| <ol> |
| <li> |
| Distinctness of the output of <tt>seed_seq::generate</tt> required the |
| introduction of the initial "<tt>if (w < 32) v.push_back(n);</tt>" (Otherwise |
| the unsigned short vectors [1, 0] and [1] generate the same sequence.) |
| </li> |
| <li> |
| Portability demanded the introduction of the template parameter <tt>u</tt>. |
| (Otherwise some sequences could not be obtained on computers where no |
| integer types are exactly 32-bits wide.) |
| </li> |
| <li> |
| The description and algorithm have become unduly complicated. |
| </li> |
| </ol> |
| <p> |
| I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only". |
| Despite it's being simpler, there is NO loss of functionality (see |
| below). |
| </p> |
| <p> |
| Here's how the description would read |
| </p> |
| <blockquote> |
| <p> |
| 26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt> |
| </p> |
| |
| <blockquote> |
| <pre>template<class InputIterator> |
| seed_seq(InputIterator begin, InputIterator end); |
| </pre> |
| <blockquote> |
| <p> |
| 5 <i>Requires:</i> NO CHANGE |
| </p> |
| <p> |
| 6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by |
| </p> |
| <blockquote> |
| <pre>for (InputIterator s = begin; s != end; ++s) |
| v.push_back((*s) mod 2^32); |
| </pre> |
| </blockquote> |
| </blockquote> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Discussion: |
| </p> |
| <p> |
| The chief virtues here are simplicity, portability, and generality. |
| </p> |
| <ul> |
| <li> |
| Simplicity -- compare the above specification with the |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal. |
| </li> |
| <li> |
| Portability -- with <tt>iterator_traits<InputIterator>::value_type = |
| uint_least32_t</tt> the user is guaranteed to get the same behavior across |
| platforms. |
| </li> |
| <li> |
| Generality -- any behavior that the |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> |
| proposal can achieve can be |
| obtained with this simpler proposal (albeit with a shuffling of bits |
| in the input sequence). |
| </li> |
| </ul> |
| <p> |
| Arguments (and counter-arguments) against making this change (and |
| retaining the |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> |
| behavior) are: |
| </p> |
| <ul> |
| <li> |
| <p> |
| The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely |
| repack it. |
| </p> |
| <p> |
| Response: So what? Consider the seed string "ABC". The |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> |
| proposal results in |
| </p> |
| <blockquote><pre>v = { 0x3, 0x434241 }; |
| </pre></blockquote> |
| <p> |
| while the simplified proposal yields |
| </p> |
| <blockquote><pre>v = { 0x41, 0x42, 0x43 }; |
| </pre></blockquote> |
| <p> |
| The results produced by <tt>seed_seq::generate</tt> with the two inputs are |
| different but nevertheless equivalently "mixed up" and this remains |
| true even if the seed string is long. |
| </p> |
| </li> |
| <li> |
| <p> |
| With long strings (e.g., with bit-length comparable to the number of |
| bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified |
| proposal and <tt>seed_seq::generate</tt> will be slower. |
| </p> |
| <p> |
| Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will |
| be a big issue. If it is, the user is free to repack the seed vector |
| before constructing <tt>seed_seq</tt>. |
| </p> |
| </li> |
| <li> |
| <p> |
| A user can pass an array of 64-bit integers and all the bits will be |
| used. |
| </p> |
| <p> |
| Response: Indeed. However, there are many instances in the |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> |
| where integers are silently coerced to a narrower width and this |
| should just be a case of the user needing to read the documentation. |
| The user can of course get equivalent behavior by repacking his seed |
| into 32-bit pieces. Furthermore, the unportability of the |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> |
| proposal with |
| </p> |
| <blockquote><pre>unsigned long s[] = {1, 2, 3, 4}; |
| seed_seq q(s, s+4); |
| </pre></blockquote> |
| <p> |
| which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in |
| <tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for |
| unsuspecting users. |
| </p> |
| </li> |
| </ul> |
| |
| <p> |
| Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>. |
| </p> |
| |
| <p><i>[ |
| Bellevue: |
| ]</i></p> |
| |
| |
| <blockquote> |
| Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution. |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Marc Paterno wants portable behavior between 32bit and 64bit machines; |
| we've gone to significant trouble to support portability of engines and |
| their values. |
| </p> |
| <p> |
| Jens: the new algorithm looks perfectly portable |
| </p> |
| <p> |
| Marc Paterno to review off-line. |
| </p> |
| <p> |
| Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..." |
| </p> |
| <p> |
| Disposition: move to review; unanimous consent. |
| </p> |
| <p> |
| (moots <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>) |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 26.4.7.1 [rand.util.seedseq]: |
| </p> |
| |
| <blockquote> |
| <pre>template<class InputIterator<del>, |
| size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>> |
| seed_seq(InputIterator begin, InputIterator end); |
| </pre> |
| <blockquote> |
| <p> |
| -5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1) |
| such that <tt>iterator_traits<InputIterator>::value_type</tt> shall denote an integral type. |
| </p> |
| <p> |
| -6- Constructs a <tt>seed_seq</tt> object by <ins>the following algorithm</ins> <del>rearranging some or all of the bits of the supplied sequence |
| <tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del> |
| </p> |
| <p> |
| <del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end |
| - begin</tt> elements of the supplied sequence and concatenate all the |
| extracted bits to initialize a single (possibly very large) unsigned |
| binary number, <tt>b = ∑<sup>n-1</sup><sub>i=0</sub> (begin[i] |
| mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt> |
| are treated as denoting an unsigned quantity). Then carry out |
| the following algorithm:</del> |
| </p> |
| <blockquote><pre><del> |
| v.clear(); |
| if ($w$ < 32) |
| v.push_back($n$); |
| for( ; $n$ > 0; --$n$) |
| v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>; |
| </del></pre></blockquote> |
| <blockquote> |
| <pre><ins> |
| for (InputIterator s = begin; s != end; ++s) |
| v.push_back((*s) mod 2<sup>32</sup>); |
| </ins></pre> |
| </blockquote> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3> |
| <p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-24</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <ol type="A"> |
| <li> |
| <p> |
| 19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and |
| 19.4.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses |
| declare an expository data member <tt>cat_</tt>: |
| </p> |
| <blockquote><pre>const error_category& cat_; // exposition only |
| </pre></blockquote> |
| <p> |
| which is used to define the semantics of several members. The decision |
| to use a member of reference type lead to several problems: |
| </p> |
| <ol> |
| <li> |
| The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent. |
| </li> |
| <li> |
| The post conditions of all modifiers from |
| 19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp., |
| cannot be fulfilled. |
| </li> |
| </ol> |
| <p> |
| The simple fix would be to replace the reference by a pointer member. |
| </p> |
| </li> |
| |
| <li> |
| I would like to give the editorial remark that in both classes the |
| constrained <tt>operator=</tt> |
| overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid |
| usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt> |
| parameter the return type would be defined to be <tt>void&</tt> even in otherwise |
| valid circumstances - this return type must be explicitly provided (In |
| <tt>error_condition</tt> the first declaration uses an explicit value, but of wrong |
| type). |
| </li> |
| |
| <li> |
| The member function <tt>message</tt> throws clauses ( |
| 19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and |
| 19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing", |
| although |
| they return a <tt>std::string</tt> by value, which might throw in out-of-memory |
| conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>). |
| </li> |
| </ol> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Part A: NAD (editorial), cleared by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>. |
| </p> |
| <p> |
| Part B: Technically correct, save for typo. Rendered moot by the concept proposal |
| (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial). |
| </p> |
| <p> |
| Part C: We agree; this is consistent with the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>. |
| </p> |
| <p> |
| Howard: please ping Beman, asking him to clear away parts A and B from |
| the wording in the proposed resolution, so it is clear to the editor |
| what needs to be applied to the working paper. |
| </p> |
| <p> |
| Beman provided updated wording. Since issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> is not going |
| forward, the provided wording includes resolution of part A. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| Resolution of part A: |
| </p> |
| <blockquote> |
| <p> |
| Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated: |
| </p> |
| |
| <blockquote><pre>private: |
| int val_; // exposition only |
| const error_category<del>&</del><ins>*</ins> cat_; // exposition only |
| </pre></blockquote> |
| |
| <p> |
| Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>error_code(); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Effects:</i> Constructs an object of type <tt>error_code</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>system_category</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| <pre>error_code(int val, const error_category& cat); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Effects:</i> Constructs an object of type <tt>error_code</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>void assign(int val, const error_category& cat); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated: |
| </p> |
| |
| <blockquote> |
| const error_category& category() const; |
| <blockquote> |
| <p> |
| <i>Returns:</i> <tt><ins>*</ins>cat_</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated: |
| </p> |
| |
| <blockquote><pre>private: |
| int val_; // exposition only |
| const error_category<del>&</del><ins>*</ins> cat_; // exposition only |
| </pre></blockquote> |
| |
| <p> |
| Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: |
| </p> |
| <p><i>[ |
| (If the proposed resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has already been applied, the |
| name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has |
| no effect on this resolution.) |
| ]</i></p> |
| |
| |
| <blockquote> |
| <pre>error_condition(); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>posix_category</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| <pre>error_condition(int val, const error_category& cat); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: |
| </p> |
| |
| <blockquote> |
| void assign(int val, const error_category& cat); |
| <blockquote> |
| <p> |
| <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: |
| </p> |
| |
| <blockquote> |
| const error_category& category() const; |
| <blockquote> |
| <p> |
| <i>Returns:</i> <tt><ins>*</ins>cat_</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Resolution of part C: |
| </p> |
| |
| <blockquote> |
| |
| <p> |
| In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10. |
| </p> |
| |
| <blockquote> |
| <pre>virtual string message(int ev) const = 0; |
| </pre> |
| |
| <blockquote> |
| <p> |
| <i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>. |
| </p> |
| <p> |
| <del><i>Throws:</i> Nothing.</del> |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. |
| </p> |
| |
| <blockquote> |
| <pre>string message() const; |
| </pre> |
| <blockquote> |
| <p> |
| <i>Returns:</i> <tt>category().message(value())</tt>. |
| </p> |
| <p> |
| <del><i>Throws:</i> Nothing.</del> |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. |
| </p> |
| |
| <blockquote> |
| <pre>string message() const; |
| </pre> |
| <blockquote> |
| <p> |
| <i>Returns:</i> <tt>category().message(value())</tt>. |
| </p> |
| <p> |
| <del><i>Throws:</i> Nothing.</del> |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3> |
| <p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-02-24</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| 19.4 [syserr] |
| </p> |
| |
| <blockquote><pre>namespace posix_error { |
| enum posix_errno { |
| address_family_not_supported, // EAFNOSUPPORT |
| ... |
| </pre></blockquote> |
| |
| <p> |
| should rather use the new scoped-enum facility (7.2 [dcl.enum]), |
| which would avoid the necessity for a new <tt>posix_error</tt> |
| namespace, if I understand correctly. |
| </p> |
| |
| <p><i>[ |
| Further discussion: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>, |
| Strongly Typed Enums, since renamed Scoped Enums. |
| </p> |
| <p> |
| Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution. |
| </p> |
| <p> |
| Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed. |
| </p> |
| <p> |
| The wording for the Proposed resolution was provided by Beman Dawes. |
| </p> |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change System error support 19.4 [syserr] as indicated: |
| </p> |
| |
| <blockquote><pre><del>namespace posix_error {</del> |
| enum <del>posix_errno</del> <ins>class errc</ins> { |
| address_family_not_supported, // EAFNOSUPPORT |
| ... |
| wrong_protocol_type, // EPROTOTYPE |
| }; |
| <del>} // namespace posix_error</del> |
| |
| template <> struct is_error_condition_enum<<del>posix_error::posix_errno</del> <ins>errc</ins>> |
| : public true_type {} |
| |
| <del>namespace posix_error {</del> |
| error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e); |
| error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e); |
| <del>} // namespace posix_error</del> |
| </pre></blockquote> |
| |
| <p> |
| Change System error support 19.4 [syserr] : |
| </p> |
| |
| <blockquote> |
| <del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be |
| specialized for user-defined types to indicate that such a type is |
| eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic |
| conversions, respectively.</del> |
| </blockquote> |
| |
| <p> |
| Change System error support 19.4 [syserr] and its subsections: |
| </p> |
| |
| <blockquote> |
| <ul> |
| <li> |
| remove all occurrences of <tt>posix_error::</tt> |
| </li> |
| <li> |
| change all instances of <tt>posix_errno</tt> to <tt>errc</tt> |
| </li> |
| <li> |
| change all instances of <tt>posix_category</tt> to <tt>generic_category</tt> |
| </li> |
| <li> |
| change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt> |
| </li> |
| </ul> |
| </blockquote> |
| |
| <p> |
| Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2: |
| </p> |
| |
| <blockquote> |
| <i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual |
| functions shall behave as specified for the class <tt>error_category</tt>. The |
| object's name virtual function shall return a pointer to the string |
| <del>"POSIX"</del> <ins>"GENERIC"</ins>. |
| </blockquote> |
| |
| <p> |
| Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e); |
| </pre> |
| |
| <blockquote> |
| <i>Returns:</i> <tt>error_code(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>. |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e); |
| </pre> |
| |
| <blockquote> |
| <i>Returns:</i> <tt>error_condition(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>. |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| <p><b>Rationale:</b></p> |
| <table border="1"> |
| <tbody><tr> |
| <th colspan="2">Names Considered</th> |
| </tr> |
| |
| <tr> |
| <td><tt>portable</tt></td> |
| <td> |
| Too non-specific. Did not wish to reserve such a common word in |
| namespace std. Not quite the right meaning, either. |
| </td> |
| </tr> |
| |
| <tr> |
| <td><tt>portable_error</tt></td> |
| <td> |
| Too long. Explicit qualification is always required for scoped enums, so |
| a short name is desirable. Not quite the right meaning, either. May be |
| misleading because <tt>*_error</tt> in the std lib is usually an exception class |
| name. |
| </td> |
| </tr> |
| |
| <tr> |
| <td><tt>std_error</tt></td> |
| <td> |
| Fairly short, yet explicit. But in fully qualified names like |
| <tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not |
| quite the right meaning, either. May be misleading because <tt>*_error</tt> in |
| the std lib is usually an exception class name. |
| </td> |
| </tr> |
| |
| <tr> |
| <td><tt>generic</tt></td> |
| <td> |
| Short enough. The category could be <tt>generic_category</tt>. Fully qualified |
| names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in |
| namespace std seems dicey. |
| </td> |
| </tr> |
| |
| <tr> |
| <td><tt>generic_error</tt></td> |
| <td> |
| Longish. The category could be <tt>generic_category</tt>. Fully qualified names |
| like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because |
| <tt>*_error</tt> in the std lib is usually an exception class name. |
| </td> |
| </tr> |
| |
| <tr> |
| <td><tt>generic_err</tt></td> |
| <td> |
| A bit less longish. The category could be <tt>generic_category</tt>. Fully |
| qualified names like <tt>std::generic_err::not_enough_memory</tt> read well. |
| </td> |
| </tr> |
| |
| <tr> |
| <td><tt>gen_err</tt></td> |
| <td> |
| Shorter still. The category could be <tt>generic_category</tt>. Fully qualified |
| names like <tt>std::gen_err::not_enough_memory</tt> read well. |
| </td> |
| </tr> |
| |
| <tr> |
| <td><tt>generr</tt></td> |
| <td> |
| Shorter still. The category could be <tt>generic_category</tt>. Fully qualified |
| names like <tt>std::generr::not_enough_memory</tt> read well. |
| </td> |
| </tr> |
| |
| <tr> |
| <td><tt>error</tt></td> |
| <td> |
| Shorter still. The category could be <tt>generic_category</tt>. Fully qualified |
| names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use |
| this general a name? |
| </td> |
| </tr> |
| |
| <tr> |
| <td><tt>err</tt></td> |
| <td> |
| Shorter still. The category could be <tt>generic_category</tt>. Fully qualified |
| names like <tt>std::err::not_enough_memory</tt> read well. Although alone it |
| looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, |
| it seems fairly intuitive. |
| Problem: <tt>err</tt> is used throughout the standard library as an argument name |
| and in examples as a variable name; it seems too confusing to add yet |
| another use of the name. |
| </td> |
| </tr> |
| |
| <tr> |
| <td><tt>errc</tt></td> |
| <td> |
| Short enough. The "c" stands for "constant". The category could be |
| <tt>generic_category</tt>. Fully qualified names like |
| <tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a |
| name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly |
| intuitive. There are no uses of <tt>errc</tt> in the current C++ standard. |
| </td> |
| </tr> |
| </tbody></table> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3> |
| <p><b>Section:</b> 20.7.11.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-03-13</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as: |
| </p> |
| |
| <blockquote> |
| <i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. |
| </blockquote> |
| |
| <p> |
| There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the |
| deleter is called with a NULL pointer, and this is probably not what's |
| intended (the destructor avoids calling the deleter with 0.) |
| </p> |
| |
| <p> |
| Two, the special check for <tt>get() == p</tt> is generally not needed and such a |
| situation usually indicates an error in the client code, which is being |
| masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such |
| self-resets in 2001 and there were no complaints. |
| </p> |
| |
| <p> |
| One might think that self-resets are necessary for operator= to work; it's specified to perform |
| </p> |
| |
| <blockquote><pre>reset( u.release() ); |
| </pre></blockquote> |
| |
| <p> |
| and the self-assignment |
| </p> |
| |
| <blockquote><pre>p = move(p); |
| </pre></blockquote> |
| |
| <p> |
| might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is |
| performed first, zeroing the stored pointer. In other words, <tt>p.reset( |
| q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there |
| is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar |
| scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| Change 20.7.11.2.5 [unique.ptr.single.modifiers]: |
| </p> |
| |
| <blockquote> |
| <pre>void reset(T* p = 0); |
| </pre> |
| <blockquote> |
| -4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]: |
| </p> |
| |
| <blockquote> |
| <pre>void reset(T* p = 0); |
| </pre> |
| <blockquote> |
| <p>...</p> |
| <p> |
| -2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3> |
| <p><b>Section:</b> 20.4.1.2 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-13</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors. I believe the same throws clause |
| should be added to <tt>tuple</tt> except it ought to take into account move constructors as well. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add to 20.4.1.2 [tuple.cnstr]: |
| </p> |
| |
| <blockquote> |
| <p> |
| For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction |
| or assignment of one of the types in <tt>Types</tt> throws an exception. |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="808"></a>808. [forward] incorrect redundant specification</h3> |
| <p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-13</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| p4 (forward) says: |
| </p> |
| <blockquote> |
| <i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue. |
| </blockquote> |
| |
| <p> |
| First of all, lvalue-ness and rvalue-ness are properties of an expression, |
| not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong. |
| Second, the phrase says exactly what the core language wording says for |
| folding references in 14.3.1 [temp.arg.type]/p4 and for function return values |
| in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should |
| at most be a note with cross-references to those sections.) |
| </p> |
| <p> |
| The prose after the example talks about "forwarding as an <tt>int&</tt> (an lvalue)" etc. |
| In my opinion, this is a category error: "<tt>int&</tt>" is a type, "lvalue" is a |
| property of an expression, orthogonal to its type. (Btw, expressions cannot |
| have reference type, ever.) |
| </p> |
| <p> |
| Similar with move: |
| </p> |
| <blockquote> |
| Return type: an rvalue. |
| </blockquote> |
| <p> |
| is just wrong and also redundant. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 20.2.2 [forward] as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>template <class T> T&& forward(typename identity<T>::type&& t); |
| </pre> |
| |
| <blockquote> |
| <p>...</p> |
| <p> |
| <del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del> |
| </p> |
| <p>...</p> |
| <p> |
| -7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor |
| as <del>an <tt>int&&</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced |
| as <tt>int&</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&</tt> (</del>an lvalue<del>)</del>. |
| In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as |
| <del><tt>double&&</tt> (</del>an rvalue<del>)</del>. |
| </p> |
| </blockquote> |
| |
| <pre>template <class T> typename remove_reference<T>::type&& move(T&& t); |
| </pre> |
| |
| <blockquote> |
| <p>...</p> |
| <p> |
| <del><i>Return type:</i> an rvalue.</del> |
| </p> |
| </blockquote> |
| |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="809"></a>809. std::swap should be overloaded for array types</h3> |
| <p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-02-28</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| For the sake of generic programming, the header <code><algorithm></code> should provide an |
| overload of <code>std::swap</code> for array types: |
| </p><pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]); |
| </pre> |
| |
| |
| <p> |
| It became apparent to me that this overload is missing, when I considered how to write a swap |
| function for a generic wrapper class template. |
| (Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.) |
| Please look at the following template, <code>W</code>, and suppose that is intended to be a very |
| <em>generic</em> wrapper: |
| </p><pre>template<class T> class W { |
| public: |
| T data; |
| }; |
| </pre> |
| Clearly <code>W<T></code> is <em>CopyConstructible and CopyAssignable</em>, and therefore |
| <em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>. |
| Moreover, <code>W<T></code> is <em>also</em> Swappable when <code>T</code> is an array type |
| whose element type is CopyConstructible and CopyAssignable. |
| Still it is recommended to add a <em>custom</em> swap function template to such a class template, |
| for the sake of efficiency and exception safety. |
| (E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing |
| swap</em>.) |
| This function template is typically written as follows: |
| <pre>template<class T> void swap(W<T>& x, W<T>& y) { |
| using std::swap; |
| swap(x.data, y.data); |
| } |
| </pre> |
| Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array. |
| For instance, <code>W<std::string[8]></code> is Swappable, but the current Standard does not |
| allow calling the custom swap function that was especially written for <code>W</code>! |
| <pre>W<std::string[8]> w1, w2; // Two objects of a Swappable type. |
| std::swap(w1, w2); // Well-defined, but inefficient. |
| using std::swap; |
| swap(w1, w2); // Ill-formed, just because ADL finds W's swap function!!! |
| </pre> |
| |
| <code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array, |
| <code>std::string[8]</code>, which is not supported by the Standard Library. |
| This issue is easily solved by providing an overload of <code>std::swap</code> for array types. |
| This swap function should be implemented in terms of swapping the elements of the arrays, so that |
| it would be non-throwing for arrays whose element types have a non-throwing swap. |
| |
| |
| <p> |
| Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em> |
| arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by |
| means of recursion. |
| </p> |
| |
| <p> |
| For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard |
| Library] Shouldn't std::swap be overloaded for C-style arrays?</a> |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]: |
| </p> |
| <blockquote> |
| - <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>. |
| </blockquote> |
| <p> |
| Add the following to 25.2.3 [alg.swap]: |
| </p> |
| <blockquote> |
| <pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]); |
| </pre> |
| <blockquote> |
| <i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>. |
| </blockquote> |
| <blockquote> |
| <i>Effects:</i> <code>swap_ranges(a, a + N, b);</code> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3> |
| <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#New">New</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-03-01</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The recent draft (as well as the original proposal n2072) uses an |
| operational semantic |
| for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses |
| </p> |
| |
| <blockquote><pre>istreambuf_iterator<charT> |
| </pre></blockquote> |
| |
| <p> |
| and |
| </p> |
| |
| <blockquote><pre>ostreambuf_iterator<charT> |
| </pre></blockquote> |
| |
| <p> |
| resp, instead of the iterator instances, with explicitly provided |
| traits argument (The operational semantic defined by <tt>f</tt> is also traits |
| dependent). This is an obvious oversight because both <tt>*stream_buf</tt> |
| c'tors expect a <tt>basic_streambuf<charT,traits></tt> as argument. |
| </p> |
| <p> |
| The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p. |
| 7 and p. 9) |
| of n2071 incorporated in N2521, where additional to the problem we |
| have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of |
| <tt>istreambuf_iterator</tt>). |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line |
| </p> |
| |
| <blockquote><pre>template <class charT, class traits, class moneyT> |
| void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) { |
| typedef istreambuf_iterator<charT<ins>, traits</ins>> Iter; |
| ... |
| </pre></blockquote> |
| |
| <p> |
| In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter: |
| </p> |
| |
| <blockquote><pre>template <<del>class charT, </del>class moneyT> unspecified put_money(const moneyT& mon, bool intl = false<ins>)</ins>; |
| </pre></blockquote> |
| |
| <p> |
| In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line |
| </p> |
| |
| <blockquote><pre>template <class charT, class traits, class moneyT> |
| void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) { |
| typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter; |
| ... |
| </pre></blockquote> |
| |
| <p> |
| In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line |
| </p> |
| |
| <blockquote><pre>template <class charT, class traits> |
| void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) { |
| typedef <ins>i</ins>streambuf_iterator<charT<ins>, traits</ins>> Iter; |
| ... |
| </pre></blockquote> |
| |
| <p> |
| In 27.6.4 [ext.manip]/8 add const: |
| </p> |
| |
| <blockquote><pre>template <class charT> unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt); |
| </pre></blockquote> |
| |
| <p> |
| In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line |
| </p> |
| |
| <blockquote><pre>template <class charT, class traits> |
| void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) { |
| typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter; |
| ... |
| </pre></blockquote> |
| |
| <p> |
| Add to the <tt><iomanip></tt> synopsis in 27.6 [iostream.format] |
| </p> |
| |
| <blockquote><pre>template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false); |
| template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false); |
| template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt); |
| template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt); |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3> |
| <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#New">New</a> |
| <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <blockquote><pre>#include <utility> |
| |
| int main() |
| { |
| std::pair<char *, char *> p (0,0); |
| } |
| </pre></blockquote> |
| |
| <p> |
| I just got a bug report about that, because it's valid C++03, but not |
| C++0x. The important realization, for me, is that the emplace |
| proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt> |
| issue---didn't cause this break in backward compatibility. The break |
| actually happened when we added this pair constructor as part of adding |
| rvalue references into the language, long before variadic templates or |
| emplace came along: |
| </p> |
| |
| <blockquote><pre>template<class U, class V> pair(U&& x, V&& y); |
| </pre></blockquote> |
| |
| <p> |
| Now, concepts will address this issue by constraining that <tt>pair</tt> |
| constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and |
| "second", e.g. (from |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>): |
| </p> |
| |
| <blockquote><pre>template<class U , class V > |
| requires Constructible<T1, U&&> && Constructible<T2, V&&> |
| pair(U&& x , V&& y ); |
| </pre></blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3> |
| <p><b>Section:</b> 25.3.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Multi-threading is a good thing, but unsolicited multi-threading can |
| potentially be harmful. For example, <tt>sort()</tt> performance might be |
| greatly increased via a multithreaded implementation. However, such |
| a multithreaded implementation could result in concurrent invocations |
| of the user-supplied comparator. This would in turn result in problems |
| given a caching comparator that might be written for complex sort keys. |
| Please note that this is not a theoretical issue, as multithreaded |
| implementations of <tt>sort()</tt> already exist. |
| </p> |
| <p> |
| Having a multithreaded <tt>sort()</tt> available is good, but it should not |
| be the default for programs that are not explicitly multithreaded. |
| Users should not be forced to deal with concurrency unless they have |
| asked for it. |
| </p> |
| |
| <p><i>[ |
| This may be covered by |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a> |
| Thread-Safety in the Standard Library (Rev 1). |
| ]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3> |
| <p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Matt Austern <b>Date:</b> 2008-02-26</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>. |
| However, that term is nowhere defined. The closest thing we have to a |
| definition is that the default constructor creates an empty <tt>shared_ptr</tt> |
| and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any |
| other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What |
| are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this |
| term or stop using it. |
| </p><p> |
| </p> |
| One reason it's not good enough to leave this term up to the reader's |
| intuition is that, in light of |
| <a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a> |
| and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers' |
| intuitive understanding is likely to be wrong. Intuitively one might |
| expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer, |
| but, whatever the definition is, that isn't it. |
| |
| |
| <p><i>[ |
| Peter adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Or, what is an "empty" <tt>shared_ptr</tt>? |
| </p> |
| |
| <ul> |
| <li> |
| <p> |
| Are any other <tt>shared_ptrs</tt> empty? |
| </p> |
| <p> |
| Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*) |
| completely specified by the last mutating operation on that instance. |
| Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or |
| not. |
| </p> |
| <blockquote> |
| (*) If it isn't, this is a legitimate defect. |
| </blockquote> |
| </li> |
| |
| <li> |
| <p> |
| For example, is <tt>shared_ptr((T*) 0)</tt> empty? |
| </p> |
| <p> |
| No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is |
| specified to have an <tt>use_count()</tt> of 1. |
| </p> |
| </li> |
| |
| <li> |
| <p> |
| What are the properties of an empty <tt>shared_ptr</tt>? |
| </p> |
| <p> |
| The properties of an empty <tt>shared_ptr</tt> can be derived from the |
| specification. One example is that its destructor is a no-op. Another is |
| that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you |
| really like. |
| </p> |
| </li> |
| |
| <li> |
| <p> |
| We should either clarify this term or stop using it. |
| </p> |
| <p> |
| I don't agree with the imperative tone |
| </p> |
| <p> |
| A clarification would be either a no-op - if it doesn't contradict the |
| existing wording - or a big mistake if it does. |
| </p> |
| <p> |
| I agree that a clarification that is formally a no-op may add value. |
| </p> |
| </li> |
| |
| <li> |
| <p> |
| However, that term is nowhere defined. |
| </p> |
| <p> |
| Terms can be useful without a definition. Consider the following |
| simplistic example. We have a type <tt>X</tt> with the following operations |
| defined: |
| </p> |
| <blockquote><pre>X x; |
| X x2(x); |
| X f(X x); |
| X g(X x1, X x2); |
| </pre></blockquote> |
| <p> |
| A default-constructed value is green.<br> |
| A copy has the same color as the original.<br> |
| <tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br> |
| <tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise. |
| </p> |
| |
| <p> |
| Given these definitions, you can determine the color of every instance |
| of type <tt>X</tt>, even if you have absolutely no idea what green and red mean. |
| </p> |
| |
| <p> |
| Green and red are "nowhere defined" and completely defined at the same time. |
| </p> |
| </li> |
| </ul> |
| |
| <p> |
| Alisdair's wording is fine. |
| </p> |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Append the following sentance to 20.7.12.2 [util.smartptr.shared] |
| </p> |
| <blockquote> |
| The <code>shared_ptr</code> class template stores a pointer, usually obtained |
| via <code>new</code>. <code>shared_ptr</code> implements semantics of |
| shared ownership; the last remaining owner of the pointer is responsible for |
| destroying the object, or otherwise releasing the resources associated with |
| the stored pointer. <ins>A <code>shared_ptr</code> object that does not own |
| a pointer is said to be <i>empty</i>.</ins> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="814"></a>814. <tt>vector<bool>::swap(reference, reference)</tt> not defined</h3> |
| <p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-17</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <tt>vector<bool>::swap(reference, reference)</tt> has no definition. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3> |
| <p><b>Section:</b> 20.6.15.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-16</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as |
| described in the rvalue core proposal. |
| </p> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect |
| forwarding can not be obtained because of type erasure. Not everyone |
| agreed with this diagnosis of forwarding. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3> |
| <p><b>Section:</b> 20.6.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-02-08</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt> |
| should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors. |
| </p> |
| <p> |
| However, no guarantees are provided for the copy ctor of the functor |
| returned by <tt>bind()</tt>. (It's guaranteed to have a copy ctor, which can |
| throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding |
| call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper, |
| TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4. |
| Everything without an exception-specification may throw |
| implementation-defined exceptions unless otherwise specified, C++03 |
| 17.4.4.8/3.) |
| </p> |
| <p> |
| Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended |
| to cover both calling <tt>bind()</tt> and copying the returned functor? |
| </p> |
| |
| <p><i>[ |
| Howard adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <tt>tuple</tt> construction should probably have a similar guarantee. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3> |
| <p><b>Section:</b> 20.6.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-17</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The functor retureed by <tt>bind()</tt> should have a move constructor that |
| requires only move construction of its contained functor and bound arguments. |
| That way move-only functors can be passed to objects such as <tt>thread</tt>. |
| </p> |
| <p> |
| This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="818"></a>818. wording for memory ordering</h3> |
| <p><b>Section:</b> 29.1 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-22</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| 29.1 [atomics.order] p1 says in the table that |
| </p> |
| |
| <blockquote> |
| <table border="1"> |
| <tbody><tr> |
| <th>Element</th><th>Meaning</th> |
| </tr> |
| <tr> |
| <td><tt>memory_order_acq_rel</tt></td> |
| <td>the operation has both acquire and release semantics</td> |
| </tr> |
| </tbody></table> |
| </blockquote> |
| |
| <p> |
| To my naked eye, that seems to imply that even an atomic read has both |
| acquire and release semantics. |
| </p> |
| |
| <p> |
| Then, p1 says in the table: |
| </p> |
| |
| <blockquote> |
| <table border="1"> |
| <tbody><tr> |
| <th>Element</th><th>Meaning</th> |
| </tr> |
| <tr> |
| <td><tt>memory_order_seq_cst</tt></td> |
| <td>the operation has both acquire and release semantics, |
| and, in addition, has sequentially-consistent operation ordering</td> |
| </tr> |
| </tbody></table> |
| </blockquote> |
| |
| <p> |
| So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional |
| constraints. |
| </p> |
| |
| <p> |
| I'm then reading p2, where it says: |
| </p> |
| |
| <blockquote> |
| The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations |
| on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value |
| are release operations on the affected locations. |
| </blockquote> |
| |
| <p> |
| That seems to imply that atomic reads only have acquire semantics. If that |
| is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual |
| load/store operations as well? |
| </p> |
| |
| <p> |
| Also, the table in p1 contains phrases with "thus" that seem to indicate |
| consequences of normative wording in 1.10 [intro.multithread]. That shouldn't be in |
| normative text, for the fear of redundant or inconsistent specification with |
| the other normative text. |
| </p> |
| |
| <p> |
| Double-check 29.4 [atomics.types.operations] that each |
| operation clearly says whether it's a load or a store operation, or |
| both. (It could be clearer, IMO. Solution not in current proposed resolution.) |
| </p> |
| |
| <p> |
| 29.1 [atomics.order] p2: What's a "consistent execution"? It's not defined in |
| 1.10 [intro.multithread], it's just used in notes there. |
| </p> |
| |
| <p> |
| And why does 29.4 [atomics.types.operations] p9 for "load" say: |
| </p> |
| |
| |
| <blockquote> |
| <i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt> |
| nor <tt>memory_order_acq_rel</tt>. |
| </blockquote> |
| |
| <p> |
| (Since this is exactly the same restriction as for "store", it seems to be a typo.) |
| </p> |
| |
| <p> |
| And then: 29.4 [atomics.types.operations] p12: |
| </p> |
| |
| <blockquote> |
| These operations are read-modify-write operations in the sense of the |
| "synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the |
| evaluation that produced the input value synchronize with any evaluation |
| that reads the updated value. |
| </blockquote> |
| |
| <p> |
| This is redundant with 1.10 [intro.multithread], see above for the reasoning. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of |
| 1.7 [intro.memory]. |
| Rephrase the table in as follows (maybe don't use a table): |
| </p> |
| |
| <blockquote> |
| <p> |
| For <tt>memory_order_relaxed</tt>, no operation orders memory. |
| </p> |
| |
| <p> |
| For <tt>memory_order_release</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>, |
| a store operation performs a release operation on the affected memory location. |
| </p> |
| |
| <p> |
| For <tt>memory_order_acquire</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>, |
| a load operation performs an acquire operation on the affected memory location. |
| </p> |
| </blockquote> |
| |
| <p> |
| Rephrase 29.1 [atomics.order] p2: |
| </p> |
| |
| <blockquote> |
| <del>The <tt>memory_order_seq_cst</tt> operations that load a value are |
| acquire operations on the affected locations. The |
| <tt>memory_order_seq_cst</tt> operations that store a value are release |
| operations on the affected locations.</del> |
| <del>In addition, in a consistent |
| execution, t</del><ins>T</ins>here <del>must be</del> <ins>is</ins> a single |
| total order <tt>S</tt> on all |
| <tt>memory_order_seq_cst</tt> operations, consistent with the happens before |
| order and modification orders for all affected locations, such that each |
| <tt>memory_order_seq_cst</tt> operation observes either the last preceding |
| modification according to this order <tt>S</tt>, or the result of an operation |
| that is not <tt>memory_order_seq_cst</tt>. [<i>Note:</i> Although it is not explicitly |
| required that <tt>S</tt> include locks, it can always be extended to an order |
| that does include lock and unlock operations, since the ordering between |
| those is already included in the happens before ordering. <i>-- end note</i>] |
| </blockquote> |
| |
| <p> |
| Rephrase 29.4 [atomics.types.operations] p12 as: |
| </p> |
| |
| <blockquote> |
| <i>Effects:</i> Atomically replaces the value pointed to by object or by |
| this with desired. Memory is affected according to the value of order. |
| These operations are read-modify-write operations <del>in the sense of the |
| "synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the |
| evaluation that produced the input value synchronize with any evaluation |
| that reads the updated value</del>. |
| </blockquote> |
| |
| <p> |
| Same in p15, p20, p22. |
| </p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="819"></a>819. rethrow_if_nested</h3> |
| <p><b>Section:</b> 18.7.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-25</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I |
| got it quite right. |
| </p> |
| |
| <p> |
| The current wording says: |
| </p> |
| |
| <blockquote> |
| <pre>template <class E> void rethrow_if_nested(const E& e); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt> |
| is publicly derived from <tt>nested_exception</tt>. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly |
| derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be |
| required to be sure. Unfortunately, if <tt>e</tt> is dynamically but not statically |
| derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3> |
| <p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-03-26</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| As of N2521, the Working Paper appears to be silent about what |
| <tt>current_exception()</tt> should do if it tries to copy the currently handled |
| exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the |
| function needs to allocate memory and the attempt fails, it returns an |
| <tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but |
| doesn't say anything about what should happen if memory allocation |
| succeeds but the actual copying fails. |
| </p> |
| |
| <p> |
| I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers |
| to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt> |
| object that refers to an instance of the copy ctor's thrown exception |
| (but if that has a throwing copy ctor, an infinite loop can occur), or |
| (3) call <tt>terminate()</tt>. |
| </p> |
| |
| <p> |
| I believe that <tt>terminate()</tt> is the most reasonable course of action, but |
| before we go implement that, I wanted to raise this issue. |
| </p> |
| |
| <p><i>[ |
| Peter's summary: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| The current practice is to not have throwing copy constructors in |
| exception classes, because this can lead to <tt>terminate()</tt> as described in |
| 15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems |
| consistent and does not introduce any new problems. |
| </p> |
| |
| <p> |
| However, the resolution of core issue 475 may relax this requirement: |
| </p> |
| |
| <blockquote> |
| The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should |
| return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt> |
| should not be called if that constructor exits with an exception. |
| </blockquote> |
| |
| <p> |
| Since throwing copy constructors will no longer call <tt>terminate()</tt>, option |
| (3) doesn't seem reasonable as it is deemed too drastic a response in a |
| recoverable situation. |
| </p> |
| |
| <p> |
| Option (2) cannot be adopted by itself, because a potential infinite |
| recursion will need to be terminated by one of the other options. |
| </p> |
| |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add the following paragraph after 18.7.5 [propagation]/7: |
| </p> |
| |
| <blockquote> |
| <p> |
| <i>Returns (continued):</i> If the attempt to copy the current exception |
| object throws an exception, the function returns an <tt>exception_ptr</tt> that |
| refers to the thrown exception or, if this is not possible, to an |
| instance of <tt>bad_exception</tt>. |
| </p> |
| <p> |
| [<i>Note:</i> The copy constructor of the thrown exception may also fail, so |
| the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid |
| infinite recursion. <i>-- end note.</i>] |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3> |
| <p><b>Section:</b> 20.7.11.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-30</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> I noticed the following: |
| </p> |
| |
| <blockquote> |
| <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>); |
| </pre> |
| |
| <p> |
| -1- <i>Requires:</i> Does not accept pointer types which are convertible |
| to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic |
| required). [<i>Note:</i> One implementation technique is to create a private |
| templated overload. <i>-- end note</i>] |
| </p> |
| </blockquote> |
| |
| <p> |
| This could be cleaned up by mandating the overload as a public deleted |
| function. In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt> |
| to be a stronger match than the deleted overload. Words... |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add to class template definition in 20.7.11.3 [unique.ptr.runtime] |
| </p> |
| |
| <blockquote> |
| <pre>// modifiers |
| T* release(); |
| void reset(T* p = 0); |
| <ins>void reset( nullptr_t );</ins> |
| <ins>template< typename T > void reset( T ) = delete;</ins> |
| void swap(unique_ptr&& u); |
| </pre> |
| </blockquote> |
| |
| <p> |
| Update 20.7.11.3.3 [unique.ptr.runtime.modifiers] |
| </p> |
| |
| <blockquote> |
| <pre>void reset(pointer p = pointer()); |
| <ins>void reset(nullptr_t);</ins> |
| </pre> |
| |
| <p> |
| <del>-1- <i>Requires:</i> Does not accept pointer types which are convertible |
| to <tt>pointer</tt> (diagnostic |
| required). [<i>Note:</i> One implementation technique is to create a private |
| templated overload. <i>-- end note</i>]</del> |
| </p> |
| <p> |
| <i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. |
| </p> |
| <p>...</p> |
| </blockquote> |
| |
| <p><i>[ |
| Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (Ready). |
| ]</i></p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3> |
| <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#New">New</a> |
| <b>Submitter:</b> James Kanze <b>Date:</b> 2008-04-01</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| I just noticed that the following program is legal in C++03, but |
| is forbidden in the current draft: |
| </p> |
| |
| <blockquote><pre>#include <vector> |
| #include <iostream> |
| |
| class Toto |
| { |
| public: |
| Toto() {} |
| explicit Toto( Toto const& ) {} |
| } ; |
| |
| int |
| main() |
| { |
| std::vector< Toto > v( 10 ) ; |
| return 0 ; |
| } |
| </pre></blockquote> |
| |
| <p> |
| Is this change intentional? (And if so, what is the |
| justification? I wouldn't call such code good, but I don't see |
| any reason to break it unless we get something else in return.) |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]: |
| </p> |
| |
| <blockquote> |
| <table border="1"> |
| <tbody><tr> |
| <th>expression</th><th>post-condition</th> |
| </tr> |
| <tr> |
| <td><tt>T t<ins>(rv)</ins><del> = rv</del></tt></td><td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td> |
| </tr> |
| <tr> |
| <td colspan="2" align="center">...</td> |
| </tr> |
| </tbody></table> |
| </blockquote> |
| |
| <p> |
| In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]: |
| </p> |
| |
| <blockquote> |
| <table border="1"> |
| <tbody><tr> |
| <th>expression</th><th>post-condition</th> |
| </tr> |
| <tr> |
| <td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td> |
| </tr> |
| <tr> |
| <td colspan="2" align="center">...</td> |
| </tr> |
| </tbody></table> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="823"></a>823. <tt>identity<void></tt> seems broken</h3> |
| <p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> |
| <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| N2588 seems to have added an <tt>operator()</tt> member function to the |
| <tt>identity<></tt> helper in 20.2.2 [forward]. I believe this change makes it no |
| longer possible to instantiate <tt>identity<void></tt>, as it would require |
| forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type. |
| </p> |
| |
| <p> |
| Suggested resolution: Specialize <tt>identity<void></tt> so as not to require |
| the member function's presence. |
| </p> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>. |
| </p> |
| <p> |
| Alisdair: also consider cv-qualified <tt>void</tt>. |
| </p> |
| <p> |
| Alberto provided proposed wording. |
| </p> |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change definition of <tt>identity</tt> in 20.2.2 [forward], paragraph 2, to: |
| </p> |
| |
| <blockquote><pre>template <class T> struct identity { |
| typedef T type; |
| |
| <ins>requires ReferentType<T></ins> |
| const T& operator()(const T& x) const; |
| }; |
| </pre></blockquote> |
| <p>...</p> |
| <blockquote><pre> <ins>requires ReferentType<T></ins> |
| const T& operator()(const T& x) const; |
| </pre></blockquote> |
| |
| |
| <p><b>Rationale:</b></p> |
| <p> |
| The point here is to able to write <tt>T&</tt> given <tt>T</tt> and <tt>ReferentType</tt> is |
| precisely the concept that guarantees so, according to N2677 |
| (Foundational concepts). Because of this, it seems preferable than an |
| explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested |
| in Sophia. In particular, Daniel remarked that there may be types other |
| than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?). |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3> |
| <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#Ready">Ready</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In the current working paper, the <tt><string></tt> header synopsis at the end of |
| 21.2 [string.classes] lists a single <tt>operator<<</tt> overload |
| for <tt>basic_string</tt>. |
| </p> |
| |
| <blockquote><pre>template<class charT, class traits, class Allocator> |
| basic_ostream<charT, traits>& |
| operator<<(basic_ostream<charT, traits>&& os, |
| const basic_string<charT,traits,Allocator>& str); |
| </pre></blockquote> |
| |
| <p> |
| The definition in 21.3.8.9 [string.io] lists two: |
| </p> |
| |
| <blockquote><pre>template<class charT, class traits, class Allocator> |
| basic_ostream<charT, traits>& |
| operator<<(basic_ostream<charT, traits>& os, |
| const basic_string<charT,traits,Allocator>& str); |
| |
| template<class charT, class traits, class Allocator> |
| basic_ostream<charT, traits>& |
| operator<<(basic_ostream<charT, traits>&& os, |
| const basic_string<charT,traits,Allocator>& str); |
| </pre></blockquote> |
| |
| <p> |
| I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two |
| signatures in 21.3.8.9 [string.io] should be deleted. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Delete the first of the two signatures in 21.3.8.9 [string.io]: |
| </p> |
| |
| <blockquote><pre><del>template<class charT, class traits, class Allocator> |
| basic_ostream<charT, traits>& |
| operator<<(basic_ostream<charT, traits>& os, |
| const basic_string<charT,traits,Allocator>& str);</del> |
| |
| template<class charT, class traits, class Allocator> |
| basic_ostream<charT, traits>& |
| operator<<(basic_ostream<charT, traits>&& os, |
| const basic_string<charT,traits,Allocator>& str); |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3> |
| <p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.7.12.2.8 |
| [util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3 |
| [bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9 |
| [re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Should the following use rvalues references to stream in insert/extract |
| operators? |
| </p> |
| |
| <ul> |
| <li>19.4.2.1 [syserr.errcode.overview]</li> |
| <li>20.7.12.2.8 [util.smartptr.shared.io]</li> |
| <li>22.2.8 [facets.examples]</li> |
| <li>23.3.5.3 [bitset.operators]</li> |
| <li>26.3.6 [complex.ops]</li> |
| <li>Doubled signatures in 27.5 [stream.buffers] for character inserters |
| (ref 27.6.2.6.4 [ostream.inserters.character]) |
| + definition 27.6.2.6.4 [ostream.inserters.character]</li> |
| <li>28.9 [re.submatch]</li> |
| </ul> |
| |
| <p><i>[ |
| Sophia Antipolis |
| ]</i></p> |
| |
| |
| <blockquote> |
| Agree with the idea in the issue, Alisdair to provide wording. |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3> |
| <p><b>Section:</b> 20.7.12.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-11</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and |
| <tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable |
| static initialization for <tt>shared_ptr</tt> variables, eliminating another |
| unfair advantage of raw pointers. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3> |
| <p><b>Section:</b> 30.3.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> |
| <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-18</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| [Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.] |
| </p> |
| <p> |
| Currently <tt>std::mutex</tt> doesn't support static initialization. This is a |
| regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that |
| we should strive to eliminate such regressions in expressive power where |
| possible, both to ease migration and to not provide incentives to (or |
| force) people to forego the C++ primitives in favor of pthreads. |
| </p> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| We believe this is implementable on POSIX, because the initializer-list |
| feature and the constexpr feature make this work. Double-check core |
| language about static initialization for this case. Ask core for a core |
| issue about order of destruction of statically-initialized objects wrt. |
| dynamically-initialized objects (should come afterwards). Check |
| non-POSIX systems for implementability. |
| </p> |
| <p> |
| If ubiquitous implementability cannot be assured, plan B is to introduce |
| another constructor, make this constexpr, which is |
| conditionally-supported. To avod ambiguities, this new constructor needs |
| to have an additional parameter. |
| </p> |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 30.3.1.1 [thread.mutex.class]: |
| </p> |
| |
| <blockquote><pre>class mutex { |
| public: |
| <ins>constexpr</ins> mutex(); |
| ... |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="829"></a>829. current_exception wording unclear about exception type</h3> |
| <p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-04-20</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p>Consider this code:</p> |
| |
| <blockquote> |
| <pre>exception_ptr xp;</pre> |
| <pre>try {do_something(); } |
| |
| catch (const runtime_error& ) {xp = current_exception();} |
| |
| ... |
| |
| rethrow_exception(xp);</pre> |
| </blockquote> |
| |
| <p> |
| Say <code>do_something()</code> throws an exception object of type <code> |
| range_error</code>. What is the type of the exception object thrown by <code> |
| rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>; |
| if it were of type <code>runtime_error</code> it still isn't possible to |
| propagate an exception and the exception_ptr/current_exception/rethrow_exception |
| machinery serves no useful purpose. |
| </p> |
| |
| <p> |
| Unfortunately, the current wording does not explicitly say that. Different |
| people read the current wording and come to different conclusions. While it may |
| be possible to deduce the correct type from the current wording, it would be |
| much clearer to come right out and explicitly say what the type of the referred |
| to exception is. |
| </p> |
| |
| <p><i>[ |
| Peter adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| I don't like the proposed resolution of 829. The normative text is |
| unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled |
| exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the |
| exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7. |
| </p> |
| <p> |
| A better way to address this is to simply add the non-normative example |
| in question as a clarification. The term <i>currently handled exception</i> |
| should be italicized and cross-referenced. A [<i>Note:</i> the currently |
| handled exception is the exception that a throw expression without an |
| operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| After 18.7.5 [propagation] , paragraph 7, add the indicated text: |
| </p> |
| |
| <blockquote> |
| <pre>exception_ptr current_exception();</pre> |
| |
| <blockquote> |
| <p> |
| <i>Returns:</i> <code>exception_ptr</code> object that refers |
| to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled |
| exception, or a null <code>exception_ptr</code> object if no exception is being handled. If |
| the function needs to allocate memory and the attempt fails, it returns an |
| <code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>. |
| It is unspecified whether the return values of two successive calls to |
| <code>current_exception</code> refer to the same exception object. |
| [<i>Note:</i> that is, it |
| is unspecified whether <code>current_exception</code> |
| creates a new copy each time it is called. |
| <i>-- end note</i>] |
| </p> |
| |
| <p> |
| <i>Throws:</i> nothing. |
| </p> |
| |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3> |
| <p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Paragraph 4 of 21.1 [char.traits] mentions that this |
| section specifies two specializations (<code>char_traits<char></code> |
| and (<code>char_traits<wchar_t></code>). However, there are actually |
| four specializations provided, i.e. in addition to the two above also |
| <code>char_traits<char16_t></code> and <code>char_traits<char32_t></code>). |
| I guess this was just an oversight and there is nothing wrong with just |
| fixing this. |
| </p> |
| |
| <p><i>[ |
| Alisdair adds: |
| ]</i></p> |
| |
| <blockquote> |
| <tt>char_traits< char16/32_t ></tt> |
| should also be added to <tt><ios_fwd></tt> in 27.2 [iostream.forward], and all the specializations |
| taking a <tt>char_traits</tt> parameter in that header. |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Idea of the issue is ok. |
| </p> |
| <p> |
| Alisdair to provide wording, once that wording arrives, move to review. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Replace paragraph 4 of 21.1 [char.traits] by: |
| </p> |
| <blockquote> |
| <p> |
| This subclause specifies a struct template, <code>char_traits<charT></code>, |
| and four explicit specializations of it, <code>char_traits<char></code>, |
| <code>char_traits<char16_t></code>, <code>char_traits<char32_t></code>, and |
| <code>char_traits<wchar_t></code>, all of which appear in the header |
| <string> and satisfy the requirements below. |
| </p> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="832"></a>832. Applying constexpr to System error support</h3> |
| <p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Initialization of objects of class <tt>error_code</tt> |
| (19.4.2 [syserr.errcode]) and class |
| <tt>error_condition</tt> (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of |
| the new <tt>constexpr</tt> feature |
| [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>] |
| of C++0x. Less code will need to be |
| generated for both library implementations and user programs when |
| manipulating constant objects of these types. |
| </p> |
| |
| <p> |
| This was not proposed originally because the constant expressions |
| proposal was moving into the standard at about the same time as the |
| Diagnostics Enhancements proposal |
| [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>], |
| and it wasn't desirable to |
| make the later depend on the former. There were also technical concerns |
| as to how <tt>constexpr</tt> would apply to references. Those concerns are now |
| resolved; <tt>constexpr</tt> can't be used for references, and that fact is |
| reflected in the proposed resolution. |
| </p> |
| |
| <p> |
| Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements. |
| </p> |
| |
| <p> |
| LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> is related in that it raises the question of whether the |
| exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.4.2 [syserr.errcode]) and class |
| <tt>error_condition</tt> (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer. |
| While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> that is arguably an editorial question, |
| presenting it as a pointer becomes more or less required with this |
| proposal, given <tt>constexpr</tt> does not play well with references. The |
| proposed resolution thus changes the private member to a pointer, which |
| also brings it in sync with real implementations. |
| </p> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| On going question of extern pointer vs. inline functions for interface. |
| </blockquote> |
| |
| <p><i>[ |
| Pre-San Francisco: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Beman Dawes reports that this proposal is unimplementable, and thus NAD. |
| </p> |
| <p> |
| Implementation would require <tt>constexpr</tt> objects of classes derived |
| from class <tt>error_category</tt>, which has virtual functions, and that is |
| not allowed by the core language. This was determined when trying to |
| implement the proposal using a constexpr enabled compiler provided |
| by Gabriel Dos Reis, and subsequently verified in discussions with |
| Gabriel and Jens Maurer. |
| </p> |
| |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> proposed wording has been |
| applied to the WP, resulting in the former <tt>posix_category</tt> being renamed |
| <tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has not been applied, the names in this |
| proposal must be adjusted accordingly. |
| </p> |
| |
| <p> |
| Change 19.4.1.1 [syserr.errcat.overview] Class |
| <tt>error_category</tt> overview <tt>error_category</tt> synopsis as |
| indicated: |
| </p> |
| |
| <blockquote><pre><del>const error_category& get_generic_category();</del> |
| <del>const error_category& get_system_category();</del> |
| |
| <del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>; |
| <del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>; |
| </pre></blockquote> |
| |
| <p> |
| Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated: |
| </p> |
| |
| <blockquote> |
| <pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>; |
| </pre> |
| <p> |
| <del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins> |
| to <del>an</del> <ins>a statically initialized</ins> object of a type derived from |
| class <tt>error_category</tt>. |
| </p> |
| |
| <p> |
| <del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual |
| functions shall behave as specified for the class <tt>error_category</tt>. The |
| object's <tt>name</tt> virtual function shall return a pointer to the string |
| <tt>"GENERIC"</tt>. |
| </p> |
| |
| <pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>; |
| </pre> |
| |
| <p> |
| <del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins> |
| to <del>an</del> <ins>a statically |
| initialized</ins> object of a type derived from class <tt>error_category</tt>. |
| </p> |
| |
| <p> |
| <del><i>Remarks:</i></del> The object's <tt>equivalent</tt> virtual functions shall behave as |
| specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function |
| shall return a pointer to the string <tt>"system"</tt>. The object's |
| <tt>default_error_condition</tt> virtual function shall behave as follows: |
| </p> |
| |
| <p> |
| If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function |
| shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the |
| function shall return <tt>error_condition(ev, system_category)</tt>. What |
| constitutes correspondence for any given operating system is |
| unspecified. [<i>Note:</i> The number of potential system error codes is large |
| and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value. |
| Thus implementations are given latitude in determining correspondence. |
| <i>-- end note</i>] |
| </p> |
| </blockquote> |
| |
| <p> |
| Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated: |
| </p> |
| |
| <blockquote><pre>class error_code { |
| public: |
| ...; |
| <ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat); |
| ... |
| void assign(int val, const error_category<del>&</del><ins>*</ins> cat); |
| ... |
| const error_category<del>&</del><ins>*</ins> category() const; |
| ... |
| private: |
| int val_; // exposition only |
| const error_category<del>&</del><ins>*</ins> cat_; // exposition only |
| </pre></blockquote> |
| |
| <p> |
| Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated: |
| </p> |
| |
| <blockquote> |
| <pre><ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat); |
| </pre> |
| <p> |
| <i>Effects:</i> Constructs an object of type <tt>error_code</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| |
| <p> |
| Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat); |
| </pre> |
| <p> |
| <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| |
| <p> |
| Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>const error_category<del>&</del><ins>*</ins> category() const; |
| </pre> |
| |
| <p> |
| <i>Returns:</i> <tt>cat_</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| |
| <p> |
| Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>class error_condition { |
| public: |
| ...; |
| <ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat); |
| ... |
| void assign(int val, const error_category<del>&</del><ins>*</ins> cat); |
| ... |
| const error_category<del>&</del><ins>*</ins> category() const; |
| ... |
| private: |
| int val_; // exposition only |
| const error_category<del>&</del><ins>*</ins> cat_; // exposition only |
| </pre> |
| </blockquote> |
| |
| <p> |
| Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated: |
| </p> |
| |
| <blockquote> |
| <pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat); |
| </pre> |
| <p> |
| <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| |
| <p> |
| Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat); |
| </pre> |
| <p> |
| <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| |
| <p> |
| Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>const error_category<del>&</del><ins>*</ins> category() const; |
| </pre> |
| <p> |
| <i>Returns:</i> <tt>cat_</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| </blockquote> |
| |
| <p> |
| Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>" to "<tt>category()-></tt>". |
| Appears approximately six times. |
| </p> |
| |
| <p> |
| <i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators, |
| paragraphs 2 and 4, change "<tt>category.equivalent(</tt>" to |
| "<tt>category()->equivalent(</tt>". |
| </p> |
| |
| <p> |
| Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated: |
| </p> |
| |
| <blockquote><pre>public: |
| system_error(error_code ec, const string& what_arg); |
| system_error(error_code ec); |
| system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat, |
| const string& what_arg); |
| system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat); |
| </pre></blockquote> |
| |
| <p> |
| Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated: |
| </p> |
| |
| <blockquote> |
| <pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat, const string& what_arg); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Effects:</i> Constructs an object of class <tt>system_error</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and |
| <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>. |
| </p> |
| </blockquote> |
| |
| <pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Effects:</i> Constructs an object of class <tt>system_error</tt>. |
| </p> |
| <p> |
| <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and |
| <tt>strcmp(runtime_error::what(), "") == 0</tt>. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3> |
| <p><b>Section:</b> 17.4.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Once the C++0x standard library is feature complete, the LWG needs to |
| review 17.4.1.3 [compliance] Freestanding implementations header list to |
| ensure it reflects LWG consensus. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3> |
| <p><b>Section:</b> 20.7.11.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-05-14</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>) proposes a useful |
| extension point for <tt>unique_ptr</tt> by granting support for an optional |
| <tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt> |
| (In the following: <tt>pointer</tt>). |
| </p> |
| <p> |
| Unfortunately no requirements are specified for the type <tt>pointer</tt> which has |
| impact on at least two key features of <tt>unique_ptr</tt>: |
| </p> |
| |
| <ol> |
| <li>Operational fail-safety.</li> |
| <li>(Well-)Definedness of expressions.</li> |
| </ol> |
| |
| <p> |
| <tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all* |
| operations cannot throw and therefore adds proper wording to the affected |
| operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types |
| ("smart pointers") will be allowed, either *all* throw-nothing clauses have to |
| be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws |
| an exception"-clauses or it has to be said explicitly that all used |
| operations of |
| <tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt> |
| to be as near as possible to the advantages of native pointers which cannot |
| fail and thus strongly favor the second choice. Also, the alternative position |
| would make it much harder to write safe and simple template code for |
| <tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given |
| that all of the expressions of <tt>pointer</tt> used to define semantics are required to |
| be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>). |
| </p> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the |
| arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector<T>::iterator</tt>. |
| </p> |
| <p> |
| Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add the following sentence just at the end of the newly proposed |
| 20.7.11.2 [unique.ptr.single]/p. 3: |
| </p> |
| |
| <blockquote> |
| <tt>unique_ptr<T, D>::pointer</tt>'s operations shall be well-formed, shall have well |
| defined behavior, and shall not throw exceptions. |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3> |
| <p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| The fix for |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, |
| now integrated into the working paper, overlooks a couple of minor |
| problems. |
| |
| </p> |
| <p> |
| |
| First, being an unformatted function once again, <code>flush()</code> |
| is required to create a sentry object whose constructor must, among |
| other things, flush the tied stream. When two streams are tied |
| together, either directly or through another intermediate stream |
| object, flushing one will also cause a call to <code>flush()</code> on |
| the other tied stream(s) and vice versa, ad infinitum. The program |
| below demonstrates the problem. |
| |
| </p> |
| <p> |
| |
| Second, as Bo Persson notes in his |
| comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>, |
| for streams with the <code>unitbuf</code> flag set such |
| as <code>std::stderr</code>, the destructor of the sentry object will |
| again call <code>flush()</code>. This seems to create an infinite |
| recursion for <code>std::cerr << std::flush;</code> |
| |
| </p> |
| <blockquote> |
| <pre>#include <iostream> |
| |
| int main () |
| { |
| std::cout.tie (&std::cerr); |
| std::cerr.tie (&std::cout); |
| std::cout << "cout\n"; |
| std::cerr << "cerr\n"; |
| } |
| </pre> |
| </blockquote> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| I think an easy way to plug the first hole is to add a requires clause |
| to <code>ostream::tie(ostream *tiestr)</code> requiring the this |
| pointer not be equal to any pointer on the list starting |
| with <code>tiestr->tie()</code> |
| through <code>tiestr()->tie()->tie()</code> and so on. I am not |
| proposing that we require implementations to traverse this list, |
| although I think we could since the list is unlikely to be very long. |
| |
| </p> |
| <p> |
| |
| Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following |
| text: |
| |
| </p> |
| <blockquote> |
| |
| <i>Requires:</i> If <code>(tiestr != 0)</code> is |
| true, <code>tiestr</code> must not be reachable by traversing the |
| linked list of tied stream objects starting |
| from <code>tiestr->tie()</code>. |
| |
| </blockquote> |
| <p> |
| |
| In addition, to prevent the infinite recursion that Bo writes about in |
| his comp.lang.c++.moderated post, I propose to change |
| 27.6.2.4 [ostream::sentry], p2 like so: |
| |
| </p> |
| <blockquote> |
| |
| If <code>((os.flags() & ios_base::unitbuf) && |
| !uncaught_exception())</code> is true, |
| calls <del>os.flush()</del> <ins><code>os.rdbuf()->pubsync()</code></ins>. |
| |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="836"></a>836. |
| effects of <code>money_base::space</code> and |
| <code>money_base::none</code> on <code>money_get</code> |
| </h3> |
| <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a></p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following: |
| |
| </p> |
| <blockquote> |
| |
| Where <code>space</code> or <code>none</code> appears in the format |
| pattern, except at the end, optional white space (as recognized |
| by <code>ct.is</code>) is consumed after any required space. |
| |
| </blockquote> |
| <p> |
| |
| This requirement can be (and has been) interpreted two mutually |
| exclusive ways by different readers. One possible interpretation |
| is that: |
| |
| </p> |
| <blockquote> |
| <ol> |
| <li> |
| |
| where <code>money_base::space</code> appears in the format, at least |
| one space is required, and |
| |
| </li> |
| <li> |
| |
| where <code>money_base::none</code> appears in the format, space is |
| allowed but not required. |
| |
| </li> |
| </ol> |
| </blockquote> |
| <p> |
| |
| The other is that: |
| |
| </p> |
| <blockquote> |
| |
| where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional. |
| |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| I propose to change the text to make it clear that the first |
| interpretation is intended, that is, to make following change to |
| 22.2.6.1.2 [locale.money.get.virtuals], p2: |
| |
| </p> |
| |
| <blockquote> |
| |
| When <code><ins>money_base::</ins>space</code> |
| or <code><ins>money_base::</ins>none</code> appears <ins>as the last |
| element </ins>in the format pattern, <del>except at the end, optional |
| white space (as recognized by <code>ct.is</code>) is consumed after |
| any required space.</del> <ins>no white space is consumed. Otherwise, |
| where <code>money_base::space</code> appears in any of the initial |
| elements of the format pattern, at least one white space character is |
| required. Where <code>money_base::none</code> appears in any of the |
| initial elements of the format pattern, white space is allowed but not |
| required. In either case, any required followed by all optional white |
| space (as recognized by <code>ct.is()</code>) is consumed.</ins> |
| If <code>(str.flags() & str.showbase)</code> is <code>false</code>, ... |
| |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="837"></a>837. |
| <code>basic_ios::copyfmt()</code> overly loosely specified |
| </h3> |
| <p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects: |
| |
| </p> |
| <blockquote> |
| |
| <i>Effects</i>: If <code>(this == &rhs)</code> does |
| nothing. Otherwise assigns to the member objects of <code>*this</code> |
| the corresponding member objects of <code>rhs</code>, except that |
| |
| <ul> |
| <li> |
| |
| <code>rdstate()</code> and <code>rdbuf()</code> are left unchanged; |
| |
| </li> |
| <li> |
| |
| <code>exceptions()</code> is altered last by |
| calling <code>exceptions(rhs.except)</code> |
| |
| </li> |
| <li> |
| |
| the contents of arrays pointed at by <code>pword</code> |
| and <code>iword</code> are copied not the pointers themselves |
| |
| </li> |
| </ul> |
| </blockquote> |
| <p> |
| |
| Since the rest of the text doesn't specify what the member objects |
| of <code>basic_ios</code> are this seems a little too loose. |
| |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| I propose to tighten things up by adding a <i>Postcondition</i> clause |
| to the function like so: |
| |
| </p> |
| <blockquote> |
| <i>Postconditions:</i> |
| |
| <table border="1"> |
| <thead> |
| <tr> |
| <th colspan="2"><code>copyfmt()</code> postconditions</th> |
| </tr> |
| <tr> |
| <th>Element</th> |
| <th>Value</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td><code>rdbuf()</code></td> |
| <td><i>unchanged</i></td> |
| </tr> |
| <tr> |
| <td><code>tie()</code></td> |
| <td><code>rhs.tie()</code></td> |
| </tr> |
| <tr> |
| <td><code>rdstate()</code></td> |
| <td><i>unchanged</i></td> |
| </tr> |
| <tr> |
| <td><code>exceptions()</code></td> |
| <td><code>rhs.exceptions()</code></td> |
| </tr> |
| <tr> |
| <td><code>flags()</code></td> |
| <td><code>rhs.flags()</code></td> |
| </tr> |
| <tr> |
| <td><code>width()</code></td> |
| <td><code>rhs.width()</code></td> |
| </tr> |
| <tr> |
| <td><code>precision()</code></td> |
| <td><code>rhs.precision()</code></td> |
| </tr> |
| <tr> |
| <td><code>fill()</code></td> |
| <td><code>rhs.fill()</code></td> |
| </tr> |
| <tr> |
| <td><code>getloc()</code></td> |
| <td><code>rhs.getloc()</code></td> |
| </tr> |
| </tbody> |
| </table> |
| </blockquote> |
| <p> |
| |
| The format of the table follows Table 117 (as |
| of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code> |
| effects. |
| |
| </p> |
| <p> |
| |
| The intent of the new table is not to impose any new requirements or |
| change existing ones, just to be more explicit about what I believe is |
| already there. |
| |
| </p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="838"></a>838. |
| can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one? |
| </h3> |
| <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#New">New</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| From message c++std-lib-20003... |
| |
| </p> |
| <p> |
| |
| The description of <code>istream_iterator</code> in |
| 24.5.1 [istream.iterator], p1 specifies that objects of the |
| class become the <i>end-of-stream</i> (EOS) iterators under the |
| following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a> another problem |
| with this paragraph): |
| |
| </p> |
| <blockquote> |
| |
| If the end of stream is reached (<code>operator void*()</code> on the |
| stream returns <code>false</code>), the iterator becomes equal to |
| the <i>end-of-stream</i> iterator value. |
| |
| </blockquote> |
| <p> |
| |
| One possible implementation approach that has been used in practice is |
| for the iterator to set its <code>in_stream</code> pointer to 0 when |
| it reaches the end of the stream, just like the default ctor does on |
| initialization. The problem with this approach is that |
| the <i>Effects</i> clause for <code>operator++()</code> says the |
| iterator unconditionally extracts the next value from the stream by |
| evaluating <code>*in_stream >> value</code>, without checking |
| for <code>(in_stream == 0)</code>. |
| |
| </p> |
| <p> |
| |
| Conformance to the requirement outlined in the <i>Effects</i> clause |
| can easily be verified in programs by setting <code>eofbit</code> |
| or <code>failbit</code> in <code>exceptions()</code> of the associated |
| stream and attempting to iterate past the end of the stream: each |
| past-the-end access should trigger an exception. This suggests that |
| some other, more elaborate technique might be intended. |
| |
| </p> |
| <p> |
| |
| Another approach, one that allows <code>operator++()</code> to attempt |
| to extract the value even for EOS iterators (just as long |
| as <code>in_stream</code> is non-0) is for the iterator to maintain a |
| flag indicating whether it has reached the end of the stream. This |
| technique would satisfy the presumed requirement implied by |
| the <i>Effects</i> clause mentioned above, but it isn't supported by |
| the exposition-only members of the class (no such flag is shown). This |
| approach is also found in existing practice. |
| |
| </p> |
| <p> |
| |
| The inconsistency between existing implementations raises the question |
| of whether the intent of the specification is that a non-EOS iterator |
| that has reached the EOS become a non-EOS one again after the |
| stream's <code>eofbit</code> flag has been cleared? That is, are the |
| assertions in the program below expected to pass? |
| |
| </p> |
| <blockquote> |
| <pre> sstream strm ("1 "); |
| istream_iterator eos; |
| istream_iterator it (strm); |
| int i; |
| i = *it++ |
| assert (it == eos); |
| strm.clear (); |
| strm << "2 3 "; |
| assert (it != eos); |
| i = *++it; |
| assert (3 == i); |
| </pre> |
| </blockquote> |
| <p> |
| |
| Or is it intended that once an iterator becomes EOS it stays EOS until |
| the end of its lifetime? |
| |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| The discussion of this issue on the reflector suggests that the intent |
| of the standard is for an <code>istreambuf_iterator</code> that has |
| reached the EOS to remain in the EOS state until the end of its |
| lifetime. Implementations that permit EOS iterators to return to a |
| non-EOS state may only do so as an extension, and only as a result of |
| calling <code>istream_iterator</code> member functions on EOS |
| iterators whose behavior is in this case undefined. |
| |
| </p> |
| <p> |
| |
| To this end we propose to change 24.5.1 [istream.iterator], p1, |
| as follows: |
| |
| </p> |
| <blockquote> |
| |
| The result of operator-> on an end<ins>-</ins>of<ins>-</ins>stream |
| is not defined. For any other iterator value a <code>const T*</code> |
| is returned.<ins> Invoking <code>operator++()</code> on |
| an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible |
| to store things into istream iterators... |
| |
| </blockquote> |
| <p> |
| |
| Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so: |
| |
| </p> |
| <blockquote> |
| |
| <pre>istream_iterator();</pre> |
| |
| <i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br> |
| <ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins> |
| |
| <pre>istream_iterator(istream_type &s);</pre> |
| |
| <i>Effects</i>: Initializes <code>in_stream</code> with &s. value |
| may be initialized during construction or the first time it is |
| referenced.<br> |
| <ins><i>Postcondition</i>: <code>in_stream == &s</code>.</ins> |
| |
| <pre>istream_iterator(const istream_iterator &x);</pre> |
| |
| <i>Effects</i>: Constructs a copy of <code>x</code>.<br> |
| <ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins> |
| |
| <pre>istream_iterator& operator++();</pre> |
| |
| <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br> |
| <i>Effects</i>: <code>*in_stream >> value</code>. |
| |
| <pre>istream_iterator& operator++(int);</pre> |
| |
| <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br> |
| <i>Effects</i>: |
| <blockquote><pre>istream_iterator tmp (*this); |
| *in_stream >> value; |
| return tmp; |
| </pre> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="839"></a>839. Maps and sets missing splice operation</h3> |
| <p><b>Section:</b> 23.3 [associative], 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> |
| <b>Submitter:</b> Alan Talbot <b>Date:</b> 2008-05-18</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Splice is a very useful feature of <tt>list</tt>. This functionality is also very |
| useful for any other node based container, and I frequently wish it were |
| available for maps and sets. It seems like an omission that these |
| containers lack this capability. Although the complexity for a splice is |
| the same as for an insert, the actual time can be much less since the |
| objects need not be reallocated and copied. When the element objects are |
| heavy and the compare operations are fast (say a <tt>map<int, huge_thingy></tt>) |
| this can be a big win. |
| </p> |
| |
| <p> |
| <b>Suggested resolution:</b> |
| </p> |
| |
| <p> |
| Add the following signatures to map, set, multimap, multiset, and the unordered associative containers: |
| </p> |
| <blockquote><pre> |
| void splice(list<T,Allocator>&& x); |
| void splice(list<T,Allocator>&& x, const_iterator i); |
| void splice(list<T,Allocator>&& x, const_iterator first, const_iterator last); |
| </pre></blockquote> |
| |
| <p> |
| Hint versions of these are also useful to the extent hint is useful. |
| (I'm looking for guidance about whether hints are in fact useful.) |
| </p> |
| |
| <blockquote><pre> |
| void splice(const_iterator position, list<T,Allocator>&& x); |
| void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i); |
| void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last); |
| </pre></blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type. |
| </p> |
| <p> |
| <tt>forward_list</tt> already has <tt>splice_after</tt>. |
| </p> |
| <p> |
| Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>? |
| </p> |
| <p> |
| Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s. |
| </p> |
| <p> |
| Howard: <tt>adopt</tt>? |
| </p> |
| <p> |
| Jens: <tt>absorb</tt>? |
| </p> |
| <p> |
| Alan: <tt>subsume</tt>? |
| </p> |
| <p> |
| Robert: <tt>recycle</tt>? |
| </p> |
| <p> |
| Howard: <tt>transfer</tt>? (but no direction) |
| </p> |
| <p> |
| Jens: <tt>transfer_from</tt>. No. |
| </p> |
| <p> |
| Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes. |
| </p> |
| <p> |
| Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow. |
| </p> |
| </blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3> |
| <p><b>Section:</b> 18.3.1 [cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| In specifying the names of macros and types defined in |
| header <code><stdint.h></code>, C99 makes use of the |
| symbol <code><i>N</i></code> to accommodate unusual platforms with |
| word sizes that aren't powers of two. C99 |
| permits <code><i>N</i></code> to take on any positive integer value |
| (including, for example, 24). |
| |
| </p> |
| <p> |
| |
| In cstdint.syn Header <code><cstdint></code> |
| synopsis, C++ on the other hand, fixes the value |
| of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only |
| types with these exact widths. |
| |
| </p> |
| <p> |
| </p> |
| |
| In addition, paragraph 1 of the same section makes use of a rather |
| informal shorthand notation to specify sets of macros. When |
| interpreted strictly, the notation specifies macros such |
| as <code>INT_8_MIN</code> that are not intended to be specified. |
| |
| <p> |
| |
| Finally, the section is missing the usual table of symbols defined |
| in that header, making it inconsistent with the rest of the |
| specification. |
| |
| </p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| I propose to use the same approach in the C++ spec as C99 uses, that |
| is, to specify the header synopsis in terms of "exposition only" types |
| that make use of the symbol <code><i>N</i></code> to denote one or |
| more of a theoretically unbounded set of widths. |
| |
| </p> |
| <p> |
| |
| Further, I propose to add a new table to section listing the symbols |
| defined in the header using a more formal notation that avoids |
| introducing inconsistencies. |
| |
| </p> |
| <p> |
| |
| To this effect, in cstdint.syn |
| Header <code><cstdint></code> synopsis, replace both the |
| synopsis and paragraph 1 with the following text: |
| |
| </p> |
| <blockquote> |
| <p> |
| </p><ol> |
| <li> |
| |
| In the names defined in the <code><cstdint></code> header, the |
| symbol <code><i>N</i></code> represents a positive decimal integer |
| with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the |
| exception of exact-width types, macros and types for values |
| of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are |
| required. Exact-width types, and any macros and types for values |
| of <code><i>N</i></code> other than 8, 16, 32, and 64 are |
| optional. However, if an implementation provides integer types with |
| widths of 8, 16, 32, or 64 bits, the corresponding exact-width types |
| and macros are required. |
| |
| </li> |
| </ol> |
| |
| <pre>namespace std { |
| |
| // required types |
| |
| // Fastest minimum-width integer types |
| typedef <i>signed integer type</i> int_fast8_t; |
| typedef <i>signed integer type</i> int_fast16_t; |
| typedef <i>signed integer type</i> int_fast32_t; |
| typedef <i>signed integer type</i> int_fast64_t; |
| |
| typedef <i>unsigned integer type</i> uint_fast8_t; |
| typedef <i>unsigned integer type</i> uint_fast16_t; |
| typedef <i>unsigned integer type</i> uint_fast32_t; |
| typedef <i>unsigned integer type</i> uint_fast64_t; |
| |
| // Minimum-width integer types |
| typedef <i>signed integer type</i> int_least8_t; |
| typedef <i>signed integer type</i> int_least16_t; |
| typedef <i>signed integer type</i> int_least32_t; |
| typedef <i>signed integer type</i> int_least64_t; |
| |
| typedef <i>unsigned integer type</i> uint_least8_t; |
| typedef <i>unsigned integer type</i> uint_least16_t; |
| typedef <i>unsigned integer type</i> uint_least32_t; |
| typedef <i>unsigned integer type</i> uint_least64_t; |
| |
| // Greatest-width integer types |
| typedef <i>signed integer type</i> intmax_t; |
| typedef <i>unsigned integer type</i> uintmax_t; |
| |
| // optionally defined types |
| |
| // Exact-width integer types |
| typedef <i>signed integer type</i> int<i>N</i>_t; |
| typedef <i>unsigned integer type</i> uint<i>N</i>_t; |
| |
| // Fastest minimum-width integer types for values |
| // of <i>N</i> other than 8, 16, 32, and 64 |
| typedef <i>signed integer type</i> uint_fast<i>N</i>_t; |
| typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t; |
| |
| // Minimum-width integer types for values |
| // of <i>N</i> other than 8, 16, 32, and 64 |
| typedef <i>signed integer type</i> uint_least<i>N</i>_t; |
| typedef <i>unsigned integer type</i> uint_least<i>N</i>_t; |
| |
| // Integer types capable of holding object pointers |
| typedef <i>signed integer type</i> intptr_t; |
| typedef <i>signed integer type</i> intptr_t; |
| |
| }</pre> |
| </blockquote> |
| <p> |
| |
| [Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.] |
| |
| </p> |
| <blockquote> |
| Table ??: Header <code><cstdint></code> synopsis |
| <table border="1"> |
| <thead> |
| <tr> |
| <th>Type</th> |
| <th colspan="3">Name(s)</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td rowspan="11"><b>Macros:</b></td> |
| <td><tt>INT<i>N</i>_MIN</tt></td> |
| <td><tt>INT<i>N</i>_MAX</tt></td> |
| <td><tt>UINT<i>N</i>_MAX</tt></td> |
| </tr> |
| <tr> |
| <td><tt>INT_FAST<i>N</i>_MIN</tt></td> |
| <td><tt>INT_FAST<i>N</i>_MAX</tt></td> |
| <td><tt>UINT_FAST<i>N</i>_MAX</tt></td> |
| </tr> |
| <tr> |
| <td><tt>INT_LEAST<i>N</i>_MIN</tt></td> |
| <td><tt>INT_LEAST<i>N</i>_MAX</tt></td> |
| <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td> |
| </tr> |
| <tr> |
| <td><tt>INTPTR_MIN</tt></td> |
| <td><tt>INTPTR_MAX</tt></td> |
| <td><tt>UINTPTR_MAX</tt></td> |
| </tr> |
| <tr> |
| <td><tt>INTMAX_MIN</tt></td> |
| <td><tt>INTMAX_MAX</tt></td> |
| <td><tt>UINTMAX_MAX</tt></td> |
| </tr> |
| <tr> |
| <td><tt>PTRDIFF_MIN</tt></td> |
| <td><tt>PTRDIFF_MAX</tt></td> |
| <td><tt>PTRDIFF_MAX</tt></td> |
| </tr> |
| <tr> |
| <td><tt>SIG_ATOMIC_MIN</tt></td> |
| <td><tt>SIG_ATOMIC_MAX</tt></td> |
| <td><tt>SIZE_MAX</tt></td> |
| </tr> |
| <tr> |
| <td><tt>WCHAR_MIN</tt></td> |
| <td><tt>WCHAR_MAX</tt></td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><tt>WINT_MIN</tt></td> |
| <td><tt>WINT_MAX</tt></td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><tt>INT<i>N</i>_C()</tt></td> |
| <td><tt>UINT<i>N</i>_C()</tt></td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><tt>INTMAX_C()</tt></td> |
| <td><tt>UINTMAX_C()</tt></td> |
| <td></td> |
| </tr> |
| <tr> |
| <td rowspan="5"><b>Types:</b></td> |
| <td><tt>int<i>N</i>_t</tt></td> |
| <td><tt>uint<i>N</i>_t</tt></td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><tt>int_fast<i>N</i>_t</tt></td> |
| <td><tt>uint_fast<i>N</i>_t</tt></td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><tt>int_least<i>N</i>_t</tt></td> |
| <td><tt>uint_least<i>N</i>_t</tt></td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><tt>intptr_t</tt></td> |
| <td><tt>uintptr_t</tt></td> |
| <td></td> |
| </tr> |
| <tr> |
| <td><tt>intmax_t</tt></td> |
| <td><tt>uintmax_t</tt></td> |
| <td></td> |
| </tr> |
| </tbody> |
| </table> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3> |
| <p><b>Section:</b> 23.1 [container.requirements], 23.2.7 [vector.bool], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| 23.1 [container.requirements]/p3 says: |
| </p> |
| |
| <blockquote> |
| Objects stored in these components shall be constructed using |
| <tt>construct_element</tt> (20.6.9). For each operation that inserts an |
| element of type <tt>T</tt> into a container (<tt>insert</tt>, |
| <tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with |
| arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>, |
| as described in table 88. [<i>Note:</i> If the component is instantiated |
| with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which |
| <tt>is_scoped_allocator<A>::value</tt> is <tt>true</tt>), then |
| <tt>construct_element</tt> may pass an inner allocator argument to |
| <tt>T</tt>'s constructor. <i>-- end note</i>] |
| </blockquote> |
| |
| <p> |
| However <tt>vector<bool, A></tt> (23.2.7 [vector.bool]) and <tt>bitset<N></tt> |
| (23.3.5 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset<N></tt> |
| does not even have an allocator. But these containers are governed by this clause. Clearly this |
| is not implementable. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 23.1 [container.requirements]/p3: |
| </p> |
| |
| <blockquote> |
| Objects stored in these components shall be constructed using |
| <tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>. |
| For each operation that inserts an |
| element of type <tt>T</tt> into a container (<tt>insert</tt>, |
| <tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with |
| arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>, |
| as described in table 88. [<i>Note:</i> If the component is instantiated |
| with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which |
| <tt>is_scoped_allocator<A>::value</tt> is <tt>true</tt>), then |
| <tt>construct_element</tt> may pass an inner allocator argument to |
| <tt>T</tt>'s constructor. <i>-- end note</i>] |
| </blockquote> |
| |
| <p> |
| Change 23.2.7 [vector.bool]/p2: |
| </p> |
| |
| <blockquote> |
| Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template, |
| except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>, |
| and <tt>construct_element</tt> (23.1 [container.requirements]) is not used to construct these values</ins>. |
| </blockquote> |
| |
| <p> |
| Move 23.3.5 [template.bitset] to clause 20. |
| </p> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="843"></a>843. Reference Closure</h3> |
| <p><b>Section:</b> 20.6.17.1 [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-02</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The <tt>std::reference_closure</tt> type has a deleted copy assignment operator |
| under the theory that references cannot be assigned, and hence the |
| assignment of its reference member must necessarily be ill-formed. |
| </p> |
| <p> |
| However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt> |
| provide for the "copying of references", and thus the current definition |
| of <tt>std::reference_closure</tt> seems unnecessarily restrictive. In particular, |
| it should be possible to write generic functions using both <tt>std::function</tt> |
| and <tt>std::reference_closure</tt>, but this generality is much harder when |
| one such type does not support assignment. |
| </p> |
| <p> |
| The definition of <tt>reference_closure</tt> does not necessarily imply direct |
| implementation via reference types. Indeed, the <tt>reference_closure</tt> is |
| best implemented via a frame pointer, for which there is no standard |
| type. |
| </p> |
| <p> |
| The semantics of assignment are effectively obtained by use of the |
| default destructor and default copy assignment operator via |
| </p> |
| |
| <blockquote><pre>x.~reference_closure(); new (x) reference_closure(y); |
| </pre></blockquote> |
| |
| <p> |
| So the copy assignment operator generates no significant real burden |
| to the implementation. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 20.6.17 [func.referenceclosure] Class template reference_closure, |
| replace the <tt>=delete</tt> in the copy assignment operator in the synopsis |
| with <tt>=default</tt>. |
| </p> |
| |
| <blockquote><pre>template<class R , class... ArgTypes > |
| class reference_closure<R (ArgTypes...)> { |
| public: |
| ... |
| reference_closure& operator=(const reference_closure&) = <del>delete</del> <ins>default</ins>; |
| ... |
| </pre></blockquote> |
| |
| <p> |
| In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy, |
| add the member function description |
| </p> |
| |
| <blockquote> |
| <pre>reference_closure& operator=(const reference_closure& f) |
| </pre> |
| <blockquote> |
| <p> |
| <i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>. |
| </p> |
| <p> |
| <i>Returns:</i> <tt>*this</tt>. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3> |
| <p><b>Section:</b> 26.3.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The current working draft is in an inconsistent state. |
| </p> |
| |
| <p> |
| 26.3.8 [complex.transcendentals] says that: |
| </p> |
| |
| <blockquote> |
| <tt>pow(complex<float>(), int())</tt> returns a <tt>complex<float></tt>. |
| </blockquote> |
| |
| <p> |
| 26.3.9 [cmplx.over] says that: |
| </p> |
| |
| <blockquote> |
| <tt>pow(complex<float>(), int())</tt> returns a <tt>complex<double></tt>. |
| </blockquote> |
| |
| <p><i>[ |
| Sophia Antipolis: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based |
| overload for <tt>pow</tt>, the C99 result is <tt>complex<double></tt>, see also C99 |
| 7.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>. |
| </p> |
| <p> |
| Special note: ask P.J. Plauger. |
| </p> |
| <blockquote> |
| Looks fine. |
| </blockquote> |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Strike this <tt>pow</tt> overload in 26.3.1 [complex.synopsis] and in 26.3.8 [complex.transcendentals]: |
| </p> |
| |
| <blockquote><pre><del>template<class T> complex<T> pow(const complex<T>& x, int y);</del> |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3> |
| <p><b>Section:</b> 29.3 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The atomic classes (and class templates) are required to support aggregate |
| initialization (29.3.1 [atomics.types.integral]p2 / 29.3.2 [atomics.types.address]p1) |
| yet also have user declared constructors, so cannot be aggregates. |
| </p> |
| <p> |
| This problem might be solved with the introduction of the proposed |
| initialization syntax at Antipolis, but the wording above should be altered. |
| Either strike the sentence as redundant with new syntax, or refer to 'brace |
| initialization'. |
| </p> |
| |
| <p><i>[ |
| Jens adds: |
| ]</i></p> |
| |
| |
| <blockquote> |
| <p> |
| Note that |
| </p> |
| <blockquote><pre>atomic_itype a1 = { 5 }; |
| </pre></blockquote> |
| <p> |
| would be aggregate-initialization syntax (now coming under the disguise |
| of brace initialization), but would be ill-formed, because the corresponding |
| constructor for atomic_itype is explicit. This works, though: |
| </p> |
| <blockquote><pre>atomic_itype a2 { 6 }; |
| </pre></blockquote> |
| |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2: |
| </p> |
| |
| <blockquote> |
| The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexpr |
| explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor. |
| <del>They shall each support aggregate initialization syntax.</del> |
| </blockquote> |
| |
| <p><i>[ |
| 2008-08-18, Lawrence adds: |
| ]</i></p> |
| |
| <blockquote> |
| The syntactic compatibility of initialization with C is important. |
| I suggest a different resolution; remove the explicit from the |
| constructor. For the same reasons we can have implicit conversions, |
| we can also have implicit constructors. |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="846"></a>846. No definition for constructor</h3> |
| <p><b>Section:</b> 29.3 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The atomic classes and class templates (29.3.1 [atomics.types.integral] / |
| 29.3.2 [atomics.types.address]) have a constexpr |
| constructor taking a value of the appropriate type for that atomic. |
| However, neither clause provides semantics or a definition for this |
| constructor. I'm not sure if the initialization is implied by use of |
| constexpr keyword (which restricts the form of a constructor) but even if |
| that is the case, I think it is worth spelling out explicitly as the |
| inference would be far too subtle in that case. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="847"></a>847. string exception safety guarantees</h3> |
| <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#New">New</a> |
| <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-05</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In March, on comp.lang.c++.moderated, I asked what were the |
| string exception safety guarantees are, because I cannot see |
| *any* in the working paper, and any implementation I know offers |
| the strong exception safety guarantee (string unchanged if a |
| member throws exception). The closest the current draft comes to |
| offering any guarantees is 21.3 [basic.string], para 3: |
| </p> |
| |
| <blockquote> |
| The class template <tt>basic_string</tt> conforms to the requirements |
| for a Sequence Container (23.1.1), for a Reversible Container (23.1), |
| and for an Allocator-aware container (91). The iterators supported by |
| <tt>basic_string</tt> are random access iterators (24.1.5). |
| </blockquote> |
| |
| <p> |
| However, the chapter 23 only says, on the topic of exceptions: 23.1 [container.requirements], |
| para 10: |
| </p> |
| |
| <blockquote> |
| <p> |
| Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following |
| additional requirements: |
| </p> |
| |
| <ul> |
| <li>if an exception is thrown by...</li> |
| </ul> |
| </blockquote> |
| |
| <p> |
| I take it as saying that this paragraph has *no* implication on |
| <tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and |
| this paragraph does not define a *requirement* of Sequence |
| nor Reversible Container, just of the models defined in Clause 23. |
| In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a> proposes to remove 23.1 [container.requirements], para 3. |
| </p> |
| |
| <p> |
| Finally, the fact that no operation on Traits should throw |
| exceptions has no bearing, except to suggest (since the only |
| other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>) |
| that the strong exception guarantee can be achieved. |
| </p> |
| |
| <p> |
| The reaction in that group by Niels Dekker, Martin Sebor, and |
| Bo Persson, was all that this would be worth an LWG issue. |
| </p> |
| |
| <p> |
| A related issue is that <tt>erase()</tt> does not throw. This should be |
| stated somewhere (and again, I don't think that the 23.1 [container.requirements], para 1 |
| applies here). |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add a blanket statement in 21.3.1 [string.require]: |
| </p> |
| |
| <blockquote> |
| <p> |
| - if any member function or operator of <tt>basic_string<charT, traits, Allocator></tt> |
| throws, that function or operator has no effect. |
| </p> |
| <p> |
| - no <tt>erase()</tt> or <tt>pop_back()</tt> function throws. |
| </p> |
| </blockquote> |
| |
| <p> |
| As far as I can tell, this is achieved by any implementation. If I made a |
| mistake and it is not possible to offer this guarantee, then |
| either state all the functions for which this is possible |
| (certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>), |
| or add paragraphs to Effects clauses wherever appropriate. |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector<bool></tt></h3> |
| <p><b>Section:</b> 20.6.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In the current working draft, <tt>std::hash<T></tt> is specialized for builtin |
| types and a few other types. Bitsets seems like one that is missing from |
| the list, not because it cannot not be done by the user, but because it |
| is hard or impossible to write an efficient implementation that works on |
| 32bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much |
| encapsulated in this respect. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add the following to the synopsis in 20.6 [function.objects]/2: |
| </p> |
| |
| <blockquote><pre>template<class Allocator> struct hash<std::vector<bool,Allocator>>; |
| template<size_t N> struct hash<std::bitset<N>>; |
| </pre></blockquote> |
| |
| <p> |
| Modify the last sentence of 20.6.16 [unord.hash]/1 to end with: |
| </p> |
| |
| <blockquote> |
| ... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>, |
| <tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector<bool></tt>. |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3> |
| <p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The type traits library contains various traits to dealt with |
| polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt> |
| and <tt>std::is_base_of</tt>. However, there is no way to compute the unique |
| public base class of a type if such one exists. Such a trait could be |
| very useful if one needs to instantiate a specialization made for the |
| root class whenever a derived class is passed as parameter. For example, |
| imagine that you wanted to specialize <tt>std::hash</tt> for a class |
| hierarchy---instead of specializing each class, you could specialize the |
| <tt>std::hash<root_class></tt> and provide a partial specialization that worked |
| for all derived classes. |
| </p> |
| |
| <p> |
| This ability---to specify operations in terms of their equivalent in the |
| root class---can be done with e.g. normal functions, but there is, |
| AFAIK, no way to do it for class templates. Being able to access |
| compile-time information about the type-hierachy can be very powerful, |
| and I therefore also suggest traits that computes the directly derived |
| class whenever that is possible. |
| </p> |
| |
| <p> |
| If the computation can not be done, the traits should fall back on an |
| identity transformation. I expect this gives the best overall usability. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations": |
| </p> |
| |
| <blockquote><pre>template< class T > struct direct_base_class; |
| template< class T > struct direct_derived_class; |
| template< class T > struct root_base_class; |
| </pre></blockquote> |
| |
| <p> |
| Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content |
| </p> |
| |
| <blockquote> |
| <table border="1"> |
| <tbody><tr> |
| <th>Template</th><th>Condition</th><th>Comments</th> |
| </tr> |
| <tr> |
| <td><tt>template< class T > struct direct_base_class;</tt></td> |
| <td><tt>T</tt> shall be a complete type.</td> |
| <td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>. |
| If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td> |
| </tr> |
| <tr> |
| <td><tt>template< class T > struct direct_derived_class;</tt></td> |
| <td><tt>T</tt> shall be a complete type.</td> |
| <td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt> |
| as an accessible unambiguous direct base class. If no such type exists, the member typedef |
| <tt>type</tt> shall equal <tt>T</tt>.</td> |
| </tr> |
| <tr> |
| <td><tt>template< class T > struct root_base_class;</tt></td> |
| <td><tt>T</tt> shall be a complete type.</td> |
| <td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of |
| <tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td> |
| </tr> |
| </tbody></table> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3> |
| <p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-06-05</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a> added a <tt>shrink_to_fit</tt> function to <tt>std::vector</tt> and <tt>std::string</tt>. |
| It did not yet deal with <tt>std::deque</tt>, because of the fundamental |
| difference between <tt>std::deque</tt> and the other two container types. The |
| need for <tt>std::deque</tt> may seem less evident, because one might think that |
| for this container, the overhead is a small map, and some number of |
| blocks that's bounded by a small constant. |
| </p> |
| <p> |
| The container overhead can in fact be arbitrarily large (i.e. is not |
| necessarily O(N) where N is the number of elements currently held by the |
| <tt>deque</tt>). As Bill Plauger noted in a reflector message, unless the map of |
| block pointers is shrunk, it must hold at least maxN/B pointers where |
| maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its |
| creation. This is independent of how the map is implemented |
| (<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N, |
| the number of elements it currently holds. |
| </p> |
| <p> |
| Hervé Brönnimann reports a situation where a <tt>deque</tt> of requests grew very |
| large due to some temporary backup (the front request hanging), and the |
| map of the <tt>deque</tt> grew quite large before getting back to normal. Just |
| to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in |
| steady regime, that held, at some point in its lifetime, maxN=10M |
| pointers, with one block holding 128 elements, the spine must be at |
| least (maxN / 128), in that case 100K. In that case, shrink-to-fit |
| would allow to reuse about 100K which would otherwise never be reclaimed |
| in the lifetime of the <tt>deque</tt>. |
| </p> |
| <p> |
| An added bonus would be that it *allows* implementations to hang on to |
| empty blocks at the end (but does not care if they do or not). A |
| <tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at |
| most O(B) space is used in addition to the storage to hold the N |
| elements and the N/B block pointers. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| To Class template deque 23.2.2 [deque] synopsis, add: |
| </p> |
| <blockquote><pre>void shrink_to_fit(); |
| </pre></blockquote> |
| |
| <p> |
| To deque capacity 23.2.2.2 [deque.capacity], add: |
| </p> |
| <blockquote><pre>void shrink_to_fit(); |
| </pre> |
| |
| <blockquote> |
| <i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory |
| use. [<i>Note:</i> The request is non-binding to allow latitude for |
| implementation-specific optimizations. -- <i>end note</i>] |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="851"></a>851. simplified array construction</h3> |
| <p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> |
| <b>Submitter:</b> Benjamin Kosnik <b>Date:</b> 2008-06-05</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| This is an issue that came up on the libstdc++ list, where a |
| discrepency between "C" arrays and C++0x's <tt>std::array</tt> was pointed |
| out. |
| </p> |
| |
| <p> |
| In "C," this array usage is possible: |
| </p> |
| |
| <blockquote><pre>int ar[] = {1, 4, 6}; |
| </pre></blockquote> |
| |
| <p> |
| But for C++, |
| </p> |
| |
| <blockquote><pre>std::array<int> a = { 1, 4, 6 }; // error |
| </pre></blockquote> |
| |
| <p> |
| Instead, the second parameter of the <tt>array</tt> template must be |
| explicit, like so: |
| </p> |
| |
| <blockquote><pre>std::array<int, 3> a = { 1, 4, 6 }; |
| </pre></blockquote> |
| |
| <p> |
| Doug Gregor proposes the following solution, that assumes |
| generalized initializer lists. |
| </p> |
| |
| <blockquote><pre>template<typename T, typename... Args> |
| inline array<T, sizeof...(Args)> |
| make_array(Args&&... args) |
| { return { std::forward<Args>(args)... }; } |
| </pre></blockquote> |
| |
| <p> |
| Then, the way to build an <tt>array</tt> from a list of unknown size is: |
| </p> |
| |
| <blockquote><pre>auto a = make_array<T>(1, 4, 6); |
| </pre></blockquote> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add to the <tt>array</tt> synopis in 23.2 [sequences]: |
| </p> |
| |
| <blockquote><pre>template<typename T, typename... Args> |
| requires Convertible<Args, T>... |
| array<T, sizeof...(Args)> |
| make_array(Args&&... args); |
| </pre></blockquote> |
| |
| <p> |
| Append after 23.2.1.6 [array.tuple] Tuple interface to class template <tt>array</tt> the |
| following new section. |
| </p> |
| |
| <blockquote> |
| <p> |
| 23.2.1.7 Convenience interface to class template <tt>array</tt> [array.tuple] |
| </p> |
| |
| <pre>template<typename T, typename... Args> |
| requires Convertible<Args, T>... |
| array<T, sizeof...(Args)> |
| make_array(Args&&... args); |
| </pre> |
| |
| <blockquote> |
| <p> |
| <i>Returns:</i> <tt>{std::forward<Args>(args)...}</tt> |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3> |
| <p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> |
| <b>Submitter:</b> Robert Klarer <b>Date:</b> 2008-06-12</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>: |
| </p> |
| |
| <blockquote><pre>local_iterator begin(size_type n) const; |
| </pre></blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]: |
| </p> |
| |
| <blockquote><pre>local_iterator begin(size_type n)<del> const</del>; |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3> |
| <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#New">New</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a> adds defaulted arguments to the <tt>to_string</tt> member, but neglects to update |
| the three newer <tt>to_string</tt> overloads. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to: |
| </p> |
| |
| <blockquote><pre>template <class charT, class traits> |
| basic_string<charT, traits, allocator<charT> > to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const; |
| template <class charT> |
| basic_string<charT, char_traits<charT>, allocator<charT> > to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const; |
| basic_string<char, char_traits<char>, allocator<char> > to_string(<ins>char zero = '0', char one = '1'</ins>) const; |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3> |
| <p><b>Section:</b> 20.7.11.1.1 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template. |
| </p> |
| <p> |
| Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor<T></tt>; |
| the latter should also become a concept. |
| </p> |
| <p> |
| Rules out cross-casting. |
| </p> |
| <p> |
| The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 20.7.11.1.1 [unique.ptr.dltr.dflt]: |
| </p> |
| |
| <blockquote><pre>namespace std { |
| template <class T> struct default_delete { |
| default_delete(); |
| template <class U> |
| <ins>requires Convertible<U*, T*> && HasVirtualDestructor<T></ins> |
| default_delete(const default_delete<U>&); |
| void operator()(T*) const; |
| }; |
| } |
| </pre></blockquote> |
| |
| <p> |
| ... |
| </p> |
| |
| <blockquote><pre>template <class U> |
| <ins>requires Convertible<U*, T*> && HasVirtualDestructor<T></ins> |
| default_delete(const default_delete<U>& other); |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="855"></a>855. capacity() and reserve() for deque?</h3> |
| <p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-11</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The main point is that <tt>capacity</tt> can be viewed as a mechanism to |
| guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt> |
| operations are used. For <tt>vector</tt>, this goes with reallocation. For |
| <tt>deque</tt>, this is a bit more subtle: <tt>capacity()</tt> of a <tt>deque</tt> may shrink, |
| whereas that of <tt>vector</tt> doesn't. In a circular buffer impl. of the |
| map, as Howard did, there is very similar notion of capacity: as long |
| as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is |
| guaranteed that no <tt>iterator</tt> is invalidated after any number of |
| <tt>push_front/back</tt> and <tt>pop_front/back</tt> operations. But this does not |
| hold for other implementations. |
| </p> |
| <p> |
| Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt> how many |
| <tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before |
| terators are invalidated. In a classical impl., <tt>capacity() = size() |
| + </tt> the min distance to either "physical" end of the deque (i.e., |
| counting the empty space in the last block plus all the blocks until |
| the end of the map of block pointers). In Howard's circular buffer |
| impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with |
| this definition, even though the guarantee could be made stronger. |
| </p> |
| <p> |
| A simple picture of a deque: |
| </p> |
| <blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z |
| </pre></blockquote> |
| <p> |
| (A,Z mark the beginning/end, | the block boundaries, F=front, B=back, |
| and - are uninitialized, + are initialized) |
| In that picture: <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min |
| (dist(A,B),dist(F,Z))</tt>. |
| </p> |
| <p> |
| <tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of |
| empty blocks to it, in order to guarantee that the next <tt>n-size() |
| push_back/push_front</tt> operations will not invalidate iterators, and |
| also will not allocate (i.e. cannot throw). The second guarantee is |
| not essential and can be left as a QoI. I know well enough existing |
| implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and |
| dinkumware) to know that either can be implemented with no change to |
| the existing class layout and code, and only a few modifications if |
| blocks are pre-allocated (instead of always allocating a new block, |
| check if the next entry in the map of block pointers is not zero). |
| </p> |
| <p> |
| Due to the difference with <tt>vector</tt>, wording is crucial. Here's a |
| proposed wording to make things concrete; I tried to be reasonably |
| careful but please double-check me: |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| Add new signatures to synopsis in 23.2.2 [deque]: |
| </p> |
| |
| <blockquote><pre>size_type capacity() const; |
| bool reserve(size_type n); |
| </pre></blockquote> |
| |
| <p> |
| Add new signatures to 23.2.2.2 [deque.capacity]: |
| </p> |
| |
| <blockquote> |
| <pre>size_type capacity() const; |
| </pre> |
| <blockquote> |
| <p> |
| 1 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt> such |
| that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b |
| push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order, |
| starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not |
| invalidate any of its iterators except to the erased elements. |
| </p> |
| <p> |
| 2 <i>Remarks:</i> Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can |
| decrease after a sequence of insertions at both ends, even if none of |
| the operations caused the <tt>deque</tt> to invalidate any of its iterators |
| except to the erased elements. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <blockquote> |
| <pre>bool reserve(size_type n); |
| </pre> |
| <blockquote> |
| <p> |
| 2 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of |
| <tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it |
| can manage iterator invalidation accordingly. After <tt>reserve()</tt>, |
| <tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this |
| operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt> |
| otherwise. If an exception is thrown, there are no effects. |
| </p> |
| <p> |
| 3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this |
| operation, and false otherwise. |
| </p> |
| <p> |
| 4 <i>Complexity:</i> It does not change the size of the sequence and takes |
| at most linear time in <tt>n</tt>. |
| </p> |
| <p> |
| 5 <i>Throws:</i> <tt>length_error</tt> if <tt>n > max_size()</tt>. |
| </p> |
| <p> |
| 6 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a |
| sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens |
| after a call to <tt>reserve()</tt> except to the erased elements, until the |
| time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than |
| <tt>capacity()</tt>, where <tt>n_f</tt> is the number of <tt>push_front</tt>, <tt>m_f</tt> of <tt>pop_front</tt>, |
| <tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to |
| <tt>reserve()</tt>. |
| </p> |
| <p> |
| 7 An implementation is free to pre-allocate buffers so as to |
| offer the additional guarantee that no exception will be thrown |
| during such a sequence other than by the element constructors. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| And 23.2.2.3 [deque.modifiers] para 1, can be enhanced: |
| </p> |
| |
| <blockquote> |
| 1 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the |
| deque. An insertion at either end of the deque invalidates all the iterators to the deque, |
| <ins>unless provisions have been made with reserve,</ins> |
| but has no effect on the validity of references to elements of the deque. |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3> |
| <p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-06-12</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| With the arrival of extended unions |
| (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>), |
| there is no |
| known use of <tt>aligned_union</tt> that couldn't be handled by |
| the "extended unions" core-language facility. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Remove the following signature from 20.5.2 [meta.type.synop]: |
| </p> |
| <blockquote><pre>template <std::size_t Len, class... Types> struct aligned_union; |
| </pre></blockquote> |
| |
| <p> |
| Remove the second row from table 51 in 20.5.7 [meta.trans.other], |
| starting with: |
| </p> |
| |
| <blockquote><pre>template <std::size_t Len, |
| class... Types> |
| struct aligned_union; |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3> |
| <p><b>Section:</b> 30.4.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-06-13</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so |
| obscure that even the class' designer can't deduce it correctly. Several |
| people have independently stumbled on this issue. |
| </p> |
| <p> |
| It might be simpler to change the return type to a scoped enum: |
| </p> |
| <blockquote><pre>enum class timeout { not_reached, reached }; |
| </pre></blockquote> |
| |
| <p> |
| That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be: |
| </p> |
| |
| <blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached ) |
| throw time_out(); |
| </pre></blockquote> |
| |
| <p><i>[ |
| Beman to supply exact wording. |
| ]</i></p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3> |
| <p><b>Section:</b> X [garbage.collection] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-21</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems |
| to be missing some words. I can't parse |
| </p> |
| <blockquote> |
| ... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable... |
| </blockquote> |
| <p> |
| I take it the intent is that <tt>undeclare_reachable</tt> should be called only |
| when there has been a corresponding call to <tt>declare_reachable</tt>. In |
| particular, although the wording seems to allow it, I assume that code |
| shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt> |
| twice. |
| </p> |
| <p> |
| I don't know what "shall be live" in the Requires clause means. |
| </p> |
| <p> |
| In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be |
| deallocated" mean? Is this different from "will not be able to collect"? |
| </p> |
| |
| <p> |
| For the wording on nesting of <tt>declare_reachable</tt> and |
| <tt>undeclare_reachable</tt>, the words for locking and unlocking recursive |
| mutexes probably are a good model. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3> |
| <p><b>Section:</b> X [datetime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-23</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a> |
| says that there is a class named <tt>monotonic_clock</tt>. It also says that this |
| name may be a synonym for <tt>system_clock</tt>, and that it's conditionally |
| supported. So the actual requirement is that it can be monotonic or not, |
| and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at |
| all (since it's conditionally supported). Okay, maybe too much |
| flexibility, but so be it. |
| </p> |
| <p> |
| A problem comes up in the threading specification, where several |
| variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the |
| meaning of an effects clause that says |
| </p> |
| |
| <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time) |
| </pre></blockquote> |
| |
| <p> |
| when <tt>monotonic_clock</tt> is not required to exist? |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="860"></a>860. Floating-Point State</h3> |
| <p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-23</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| There are a number of functions that affect the floating point state. |
| These function need to be thread-safe, but I'm unsure of the right |
| approach in the standard, as we inherit them from C. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3> |
| <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#New">New</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-06-24</p> |
| <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> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container |
| member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>: |
| </p> |
| |
| <blockquote> |
| <tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() && |
| equal(a.begin(), a.end(), b.begin()</tt> |
| </blockquote> |
| |
| <p> |
| The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function |
| by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic. |
| </p> |
| <p> |
| Other parts of the (sequence) container requirements do also depend on |
| <tt>size()</tt>, e.g. <tt>empty()</tt> |
| or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing |
| <tt>EqualityComparable</tt> specification, |
| because of the special design choices of <tt>forward_list</tt>. |
| </p> |
| <p> |
| I propose to apply one of the following resolutions, which are described as: |
| </p> |
| |
| <ol type="A"> |
| <li> |
| Provide a definition, which is optimal for this special container without |
| previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt> |
| with the corresponding container ranges and instead uses a special |
| <tt>equals</tt> implementation which takes two container ranges instead of 1 1/2. |
| </li> |
| <li> |
| The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced |
| by <tt>distance</tt> with corresponding performance disadvantages. |
| </li> |
| </ol> |
| <p> |
| Both proposal choices are discussed, the preferred choice of the author is |
| to apply (A). |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Common part: |
| </p> |
| <ul> |
| <li> |
| <p> |
| Just betwen 23.2.3.5 [forwardlist.ops] and 23.2.3.6 [forwardlist.spec] |
| add a new |
| section "forwardlist comparison operators" [forwardlist.compare] (and |
| also add the |
| new section number to 23.2.3 [forwardlist]/2 in front of "Comparison operators"): |
| </p> |
| <blockquote> |
| forwardlist comparison operators [forwardlist.compare] |
| </blockquote> |
| </li> |
| </ul> |
| |
| <p> |
| Option (A): |
| </p> |
| <blockquote> |
| <ul> |
| <li> |
| <p> |
| Add to the new section [forwardlist.compare] the following paragraphs: |
| </p> |
| |
| <blockquote> |
| <pre>template <class T, class Allocator> |
| bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]). |
| </p> |
| <p> |
| <i>Returns:</i> <tt>true</tt> if |
| </p> |
| <ul> |
| <li> |
| <p> |
| for every iterator <tt>i</tt> in the range <tt>[x.begin(), E)</tt>, where <tt>E == |
| x.begin() + M</tt> and <tt>M == |
| min(distance(x.begin(), x.end()), distance(y.begin(), y.end()))</tt>, |
| the following condition holds: |
| </p> |
| <blockquote><pre>*i == *(y.begin() + (i - x.begin())). |
| </pre></blockquote> |
| </li> |
| <li> |
| if <tt>i == E</tt> then <tt>i == x.end() && (y.begin() + (i - x.begin())) == y.end()</tt>. |
| </li> |
| <li> |
| Otherwise, returns <tt>false</tt>. |
| </li> |
| </ul> |
| <p> |
| <i>Throws:</i> Nothing unless an exception is thrown by the equality comparison. |
| </p> |
| <p> |
| <i>Complexity:</i> At most <tt>M</tt> comparisons. |
| </p> |
| </blockquote> |
| <pre>template <class T, class Allocator> |
| bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); |
| </pre> |
| <blockquote> |
| <i>Returns:</i> <tt>!(x == y)</tt>. |
| </blockquote> |
| </blockquote> |
| </li> |
| </ul> |
| </blockquote> |
| |
| <p> |
| Option (B): |
| </p> |
| <blockquote> |
| <ul> |
| <li> |
| <p> |
| Add to the new section [forwardlist.compare] the following paragraphs: |
| </p> |
| <blockquote> |
| <pre>template <class T, class Allocator> |
| bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); |
| </pre> |
| <blockquote> |
| <p> |
| <i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]). |
| </p> |
| <p> |
| <i>Returns:</i> <tt>distance(x.begin(), x.end()) == distance(y.begin(), y.end()) |
| && equal(x.begin(), x.end(), y.begin())</tt>. |
| </p> |
| </blockquote> |
| <pre>template <class T, class Allocator> |
| bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); |
| </pre> |
| <blockquote> |
| <i>Returns:</i> <tt>!(x == y)</tt>. |
| </blockquote> |
| </blockquote> |
| </li> |
| </ul> |
| </blockquote> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="862"></a>862. Impossible complexity for 'includes'</h3> |
| <p><b>Section:</b> 25.3.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-07-02</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In 25.3.5.1 [includes] the complexity is "at most -1 comparisons" if passed |
| two empty ranges. I don't know how to perform a negative number of |
| comparisions! |
| </p> |
| |
| <p> |
| This same issue also applies to: |
| </p> |
| |
| <ul> |
| <li><tt>set_union</tt></li> |
| <li><tt>set_intersection</tt></li> |
| <li><tt>set_difference</tt></li> |
| <li><tt>set_symmetric_difference</tt></li> |
| <li><tt>merge</tt></li> |
| </ul> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3> |
| <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#New">New</a> |
| <b>Submitter:</b> Steve Clamage <b>Date:</b> 2008-07-08</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>. |
| The <tt>overflow()</tt> function is called to flush the buffer (if it exists). |
| Then the file is unconditionally closed, as if by calling <tt>flcose</tt>. |
| </p> |
| <p> |
| If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly |
| the <tt>stream</tt> should be in a failed or bad state. |
| </p> |
| <p> |
| Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not |
| fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but |
| what is the state of the <tt>stream</tt>? |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="864"></a>864. Defect in atomic wording</h3> |
| <p><b>Section:</b> 29.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Anthony Williams <b>Date:</b> 2008-07-10</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| There's an error in 29.4 [atomics.types.operations]/p9: |
| </p> |
| |
| <blockquote> |
| <pre>C atomic_load(const volatile A * object); |
| C atomic_load_explicit(const volatile A * object, memory_order); |
| C A ::load(memory_order order = memory_order_seq_cst) const volatile; |
| </pre> |
| <blockquote> |
| <p> |
| <i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor |
| <tt>memory_order_acq_rel</tt>. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| I believe that this should state |
| </p> |
| <blockquote> |
| shall not be <tt>memory_order_release</tt>. |
| </blockquote> |
| |
| <p> |
| There's also an error in 29.4 [atomics.types.operations]/p17: |
| </p> |
| |
| <blockquote> |
| ... When only one <tt>memory_order</tt> argument is supplied, the value of success |
| is <tt>order</tt>, and |
| the value of failure is <tt>order</tt> except that a value of |
| <tt>memory_order_acq_rel</tt> shall be replaced by the value |
| <tt>memory_order_require</tt> ... |
| </blockquote> |
| <p> |
| I believe this should state |
| </p> |
| <blockquote> |
| shall be replaced by the value <tt>memory_order_acquire</tt> ... |
| </blockquote> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 29.4 [atomics.types.operations]/p9: |
| </p> |
| |
| <blockquote> |
| <pre>C atomic_load(const volatile A * object); |
| C atomic_load_explicit(const volatile A * object, memory_order); |
| C A ::load(memory_order order = memory_order_seq_cst) const volatile; |
| </pre> |
| <blockquote> |
| <p> |
| <i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del> |
| <ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>. |
| </p> |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Change 29.4 [atomics.types.operations]/p17: |
| </p> |
| |
| <blockquote> |
| ... When only one <tt>memory_order</tt> argument is supplied, the value of success |
| is <tt>order</tt>, and |
| the value of failure is <tt>order</tt> except that a value of |
| <tt>memory_order_acq_rel</tt> shall be replaced by the value |
| <del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ... |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="865"></a>865. More algorithms that throw away information</h3> |
| <p><b>Section:</b> 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-07-13</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which |
| unnecessarily throw away information. These are typically algorithms, |
| which sequentially write into an <tt>OutputIterator</tt>, but do not return the |
| final value of this output iterator. These cases are: |
| </p> |
| |
| <ol> |
| <li> |
| <pre>template<class OutputIterator, class Size, class T> |
| void fill_n(OutputIterator first, Size n, const T& value);</pre></li> |
| |
| <li> |
| <pre>template<class OutputIterator, class Size, class Generator> |
| void generate_n(OutputIterator first, Size n, Generator gen);</pre></li> |
| </ol> |
| <p> |
| In both cases the minimum requirements on the iterator are |
| <tt>OutputIterator</tt>, which means according to the requirements of |
| 24.1.2 [output.iterators]/2 that only single-pass iterations are guaranteed. |
| So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt> |
| available, they have no chance to continue pushing further values |
| into it, which seems to be a severe limitation to me. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <ol> |
| <li> |
| <p> |
| Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header |
| <tt><algorithm></tt> synopsis and in 25.2.6 [alg.fill] by |
| </p> |
| |
| <blockquote><pre>template<class OutputIterator, class Size, class T> |
| <del>void</del> <ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T& value); |
| </pre></blockquote> |
| <p> |
| Just after the effects clause p.2 add a new returns clause saying: |
| </p> |
| <blockquote> |
| <i>Returns:</i> <tt>first + n</tt> for <tt>fill_n</tt>. |
| </blockquote> |
| </li> |
| <li> |
| <p> |
| Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2, header |
| <tt><algorithm></tt> synopsis and in 25.2.7 [alg.generate] by |
| </p> |
| <blockquote><pre>template<class OutputIterator, class Size, class Generator> |
| <del>void</del> <ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen); |
| </pre></blockquote> |
| <p> |
| Just after the effects clause p.1 add a new returns clause saying: |
| </p> |
| <blockquote> |
| <i>Returns:</i> <tt>first + n</tt> for <tt>generate_n</tt>. |
| </blockquote> |
| </li> |
| </ol> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="866"></a>866. Qualification of placement new-expressions</h3> |
| <p><b>Section:</b> 20.7.10 [specialized.algorithms], 20.7.12.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-14</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> replaced "<tt>new</tt>" with "<tt>::new</tt>" in the placement |
| new-expression in 20.7.5.1 [allocator.members]. I believe the rationale |
| given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> applies also to the following other contexts: |
| </p> |
| <ul> |
| <li> |
| <p> |
| in 20.7.10 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>, |
| <tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use |
| the unqualified placement new-expression in some variation of the form: |
| </p> |
| <blockquote><pre>new (static_cast<void*>(&*result)) typename iterator_traits<ForwardIterator>::value_type(*first); |
| </pre></blockquote> |
| </li> |
| <li> |
| <p> |
| in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression: |
| </p> |
| <blockquote><pre>new (pv) T(std::forward<Args>(args)...), |
| </pre></blockquote> |
| </li> |
| </ul> |
| <p> |
| I suggest to add qualification in all those places. As far as I know, |
| these are all the remaining places in the whole library that explicitly |
| use a placement new-expression. Should other uses come out, they should |
| be qualified as well. |
| </p> |
| <p> |
| As an aside, a qualified placement new-expression does not need |
| additional requirements to be compiled in a constrained context. By |
| adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a> |
| would no longer be needed by library and |
| should therefore be removed. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Replace "<tt>new</tt>" with "<tt>::new</tt>" in: |
| </p> |
| <ul> |
| <li> |
| 20.7.10.1 [uninitialized.copy], paragraphs 1 and 3 |
| </li> |
| <li> |
| 20.7.10.2 [uninitialized.fill] paragraph 1 |
| </li> |
| <li> |
| 20.7.10.3 [uninitialized.fill.n] paragraph 1 |
| </li> |
| <li> |
| 20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2. |
| </li> |
| </ul> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="867"></a>867. Valarray and value-initialization</h3> |
| <p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-20</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| From 26.5.2.1 [valarray.cons], paragraph 2: |
| </p> |
| |
| <blockquote><pre>explicit valarray(size_t); |
| </pre> |
| <blockquote> |
| The array created by this constructor has a length equal to the value of the argument. The elements |
| of the array are constructed using the default constructor for the instantiating type <tt>T</tt>. |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt> |
| and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize |
| the elements, so I suggest replacing: |
| </p> |
| |
| <blockquote> |
| The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>. |
| </blockquote> |
| <p> |
| with |
| </p> |
| <blockquote> |
| The elements of the array are value-initialized. |
| </blockquote> |
| |
| <p> |
| There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9. |
| That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt> |
| and so it doesn't need changes). |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 26.5.2.1 [valarray.cons], paragraph 2: |
| </p> |
| |
| <blockquote> |
| <pre>explicit valarray(size_t); |
| </pre> |
| <blockquote> |
| The array created by this constructor has a length equal to the value of the argument. The elements |
| of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del> |
| <ins>value-initialized (8.5 [dcl.init])</ins>. |
| </blockquote> |
| </blockquote> |
| |
| <p> |
| Change 26.5.2.7 [valarray.members], paragraph 9: |
| </p> |
| |
| <blockquote> |
| [<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the |
| default constructor</del> |
| <ins>value-initialized (8.5 [dcl.init])</ins>; |
| the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>] |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="868"></a>868. default construction and value-initialization</h3> |
| <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-22</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| The term "default constructed" is often used in wording that predates |
| the introduction of the concept of value-initialization. In a few such |
| places the concept of value-initialization is more correct than the |
| current wording (for example when the type involved can be a built-in) |
| so a replacement is in order. Two of such places are already covered by |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>. This issue deliberately addresses the hopefully |
| non-controversial changes in the attempt of being approved more quickly. |
| A few other occurrences (for example in <tt>std::tuple</tt>, |
| <tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate |
| issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>. This issue is |
| related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 20.1.1 [utility.arg.requirements], paragraph 2: |
| </p> |
| |
| <blockquote> |
| In general, a default constructor is not required. Certain container class member function signatures specify |
| <del>the default constructor</del> |
| <ins><tt>T()</tt></ins> |
| as a default argument. <tt>T()</tt> shall be a well-defined expression (8.5 [dcl.init]) if one of |
| those signatures is called using the default argument (8.3.6 [dcl.fct.default]). |
| </blockquote> |
| |
| <p> |
| In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized |
| (8.5 [dcl.init])": |
| </p> |
| |
| <ul> |
| <li>23.2.2.1 [deque.cons] para 2</li> |
| <li>23.2.2.2 [deque.capacity] para 1</li> |
| <li>23.2.3.1 [forwardlist.cons] para 3</li> |
| <li>23.2.3.4 [forwardlist.modifiers] para 21</li> |
| <li>23.2.4.1 [list.cons] para 3</li> |
| <li>23.2.4.2 [list.capacity] para 1</li> |
| <li>23.2.6.1 [vector.cons] para 3</li> |
| <li>23.2.6.2 [vector.capacity] para 10</li> |
| </ul> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3> |
| <p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Sohail Somani <b>Date:</b> 2008-07-22</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Is there any language in the current draft specifying the behaviour of the following snippet? |
| </p> |
| |
| <blockquote><pre>unordered_set<int> s; |
| unordered_set<int>::local_iterator it = s.end(0); |
| |
| // Iterate past end - the unspecified part |
| it++; |
| </pre></blockquote> |
| |
| <p> |
| I don't think there is anything about <tt>s.end(n)</tt> being considered an |
| iterator for the past-the-end value though (I think) it should be. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]: |
| </p> |
| |
| <blockquote> |
| <table border="1"> |
| <caption>Table 97: Unordered associative container requirements</caption> |
| <tbody><tr> |
| <th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th> |
| </tr> |
| <tr> |
| <td><tt>b.begin(n)</tt></td> |
| <td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td> |
| <td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a |
| valid range containing all of the elements in the n<sup>th</sup> bucket.</del> |
| <ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket. |
| If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td> |
| <td>Constant</td> |
| </tr> |
| <tr> |
| <td><tt>b.end(n)</tt></td> |
| <td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td> |
| <td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>. |
| <ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td> |
| <td>Constant</td> |
| </tr> |
| </tbody></table> |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3> |
| <p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-17</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Good ol' associative containers allow both function pointers and |
| function objects as feasible |
| comparators, as described in 23.1.4 [associative.reqmts]/2: |
| </p> |
| |
| <blockquote> |
| Each associative container is parameterized on <tt>Key</tt> and an ordering |
| relation <tt>Compare</tt> that |
| induces a strict weak ordering (25.3) on elements of Key. [..]. The |
| object of type <tt>Compare</tt> is |
| called the comparison object of a container. This comparison object |
| may be a pointer to |
| function or an object of a type with an appropriate function call operator.[..] |
| </blockquote> |
| |
| <p> |
| The corresponding wording for unordered containers is not so clear, |
| but I read it to disallow |
| function pointers for the hasher and I miss a clear statement for the |
| equality predicate, see |
| 23.1.5 [unord.req]/3+4+5: |
| </p> |
| |
| <blockquote> |
| <p> |
| Each unordered associative container is parameterized by <tt>Key</tt>, by a |
| function object <tt>Hash</tt> that |
| acts as a hash function for values of type <tt>Key</tt>, and by a binary |
| predicate <tt>Pred</tt> that induces an |
| equivalence relation on values of type <tt>Key</tt>.[..] |
| </p> |
| <p> |
| A hash function is a function object that takes a single argument of |
| type <tt>Key</tt> and returns a |
| value of type <tt>std::size_t</tt>. |
| </p> |
| <p> |
| Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the |
| container's equality function object |
| returns <tt>true</tt> when passed those values.[..] |
| </p> |
| </blockquote> |
| |
| <p> |
| and table 97 says in the column "assertion...post-condition" for the |
| expression X::hasher: |
| </p> |
| |
| <blockquote> |
| <tt>Hash</tt> shall be a unary function object type such that the expression |
| <tt>hf(k)</tt> has type <tt>std::size_t</tt>. |
| </blockquote> |
| |
| <p> |
| Note that 20.6 [function.objects]/1 defines as "Function objects are |
| objects with an <tt>operator()</tt> defined.[..]" |
| </p> |
| <p> |
| Does this restriction exist by design or is it an oversight? If an |
| oversight, I suggest that to apply |
| the following |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 23.1.5 [unord.req]/3, just after the second sentence which is written as |
| </p> |
| |
| <blockquote> |
| Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an |
| arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>. |
| </blockquote> |
| |
| <p> |
| add one further sentence: |
| </p> |
| |
| <blockquote> |
| Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type |
| with an appropriate function call operator. |
| </blockquote> |
| |
| <p> |
| [Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in |
| p.4 and p.5, it an alternative resolution |
| would be to insert a new paragraph just after p.5, which contains the |
| above proposed sentence] |
| </p> |
| <p> |
| [Note2: I do not propose a change of above quoted element in table 97, |
| because the mis-usage of the |
| notion of "function object" seems already present in the standard at |
| several places, even if it includes |
| function pointers, see e.g. 25 [algorithms]/7. The important point is |
| that in those places a statement is |
| given that the actually used symbol, like "Predicate" applies for |
| function pointers as well] |
| </p> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="871"></a>871. Iota's requirements on T are too strong</h3> |
| <p><b>Section:</b> 26.6.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-20</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| According to the recent WP |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>, |
| 26.6.5 [numeric.iota]/1, the requires clause |
| of <tt>std::iota</tt> says: |
| </p> |
| |
| <blockquote> |
| <tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and |
| shall be convertible to <tt>ForwardIterator</tt>'s value type.[..] |
| </blockquote> |
| |
| <p> |
| Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt> |
| seems to be the correct choice. I guess the current wording resulted as an |
| artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>. |
| </p> |
| |
| <p> |
| Note: If this function will be conceptualized, the here proposed |
| <tt>MoveConstructible</tt> |
| requirement can be removed, because this is an implied requirement of |
| function arguments, see |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| |
| <p> |
| Change the first sentence of 26.6.5 [numeric.iota]/1: |
| </p> |
| |
| <blockquote> |
| <i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of |
| <tt>CopyConstructible</tt> and <tt>Assignable</tt> types,</del> |
| <ins> |
| be <tt>MoveConstructible</tt> (Table 34) |
| </ins> |
| and shall be |
| convertible to <tt>ForwardIterator</tt>'s value type. [..] |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3> |
| <p><b>Section:</b> 24.4.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-08-21</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| <tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as: |
| </p> |
| |
| <blockquote><pre>reference operator[](difference_type n) const; |
| </pre></blockquote> |
| |
| <p> |
| This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to |
| have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the |
| implicit conversion to <tt>value_type&&</tt> could end up referencing a temporary |
| that has already been destroyed. This is essentially the same issue that |
| we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of |
| <tt>move_iterator</tt>'s <tt>operator[]</tt> to: |
| </p> |
| |
| <blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const; |
| </pre></blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3> |
| <p><b>Section:</b> 3.9.1 [basic.fundamental] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Travis Vitek <b>Date:</b> 2008-06-30</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| Neither the term "signed integral type" nor the term "unsigned |
| integral type" is defined in the core language section of the |
| standard, therefore the library section should avoid its use. The |
| terms <i>signed integer type</i> and <i>unsigned integer type</i> are |
| indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be |
| replaced accordingly. |
| </p> |
| |
| <p> |
| Note that the key issue here is that "signed" + "integral type" != |
| "signed integral type". |
| |
| The types <code>bool</code>, <code>char</code>, <code>char16_t</code>, |
| <code>char32_t</code> and <code>wchar_t</code> are all listed as |
| integral types, but are neither of <i>signed integer type</i> or |
| <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for |
| integral type is <i>integer type</i>. |
| |
| Given this, one may choose to assume that an <i>integral type</i> that |
| can represent values less than zero is a <i>signed integral type</i>. |
| Unfortunately this can cause ambiguities. |
| |
| As an example, if <code>T</code> is <code>unsigned char</code>, the |
| expression <code>make_signed<T>::type</code>, is supposed to |
| name a signed integral type. There are potentially two types that |
| satisfy this requirement, namely <code>signed char</code> and |
| <code>char</code> (assuming <code>CHAR_MIN < 0</code>). |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| I propose to use the terms "signed integer type" and "unsigned integer |
| type" in place of "signed integral type" and "unsigned integral type" |
| to eliminate such ambiguities. |
| </p> |
| |
| <p> |
| The proposed change makes it absolutely clear that the difference |
| between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>, |
| but could be any of the signed integer types. |
| 5.7 [expr.add] paragraph 6... |
| </p> |
| <blockquote> |
| <p> |
| </p><ol> |
| <li> |
| When two pointers to elements of the same array object are |
| subtracted, the result is the difference of the subscripts of |
| the two array elements. The type of the result is an |
| implementation-defined <del>signed integral |
| type</del><ins>signed integer type</ins>; this type shall be the |
| same type that is defined as <code>std::ptrdiff_t</code> in the |
| <code><cstdint></code> header (18.1)... |
| </li> |
| </ol> |
| |
| </blockquote> |
| |
| <p> |
| The proposed change makes it clear that <tt>X::size_type</tt> and |
| <tt>X::difference_type</tt> cannot be <tt>char</tt> or |
| <tt>wchar_t</tt>, but could be one of the signed or unsigned integer |
| types as appropriate. |
| 20.1.2 [allocator.requirements] table 40... |
| </p> |
| <blockquote> |
| Table 40: Allocator requirements |
| <table border="1"> |
| <thead> |
| <tr> |
| <th>expression</th> |
| <th>return type</th> |
| <th>assertion/note/pre/post-condition</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td><tt>X::size_type</tt></td> |
| <td> |
| <del>unsigned integral type</del> |
| <ins>unsigned integer type</ins> |
| </td> |
| <td>a type that can represent the size of the largest object in |
| the allocation model.</td> |
| </tr> |
| <tr> |
| <td><tt>X::difference_type</tt></td> |
| <td> |
| <del>signed integral type</del> |
| <ins>signed integer type</ins> |
| </td> |
| <td>a type that can represent the difference between any two |
| pointers in the allocation model.</td> |
| </tr> |
| </tbody> |
| </table> |
| </blockquote> |
| |
| <p> |
| The proposed change makes it clear that <tt>make_signed<T>::type</tt> |
| must be one of the signed integer types as defined in 3.9.1. Ditto for |
| <tt>make_unsigned<T>type</tt> and unsigned integer types. |
| 20.5.6.3 [meta.trans.sign] table 48... |
| </p> |
| <blockquote> |
| Table 48: Sign modifications |
| <table border="1"> |
| <thead> |
| <tr> |
| <th>Template</th> |
| <th>Comments</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td> |
| <tt>template <class T> struct make_signed;</tt> |
| </td> |
| <td> |
| If <code>T</code> names a (possibly cv-qualified) <del>signed |
| integral type</del><ins>signed integer type</ins> (3.9.1) then |
| the member typedef <code>type</code> shall name the type |
| <code>T</code>; otherwise, if <code>T</code> names a (possibly |
| cv-qualified) <del>unsigned integral type</del><ins>unsigned |
| integer type</ins> then <code>type</code> shall name the |
| corresponding <del>signed integral type</del><ins>signed |
| integer type</ins>, with the same cv-qualifiers as |
| <code>T</code>; otherwise, <code>type</code> shall name the |
| <del>signed integral type</del><ins>signed integer type</ins> |
| with the smallest rank (4.13) for which <code>sizeof(T) == |
| sizeof(type)</code>, with the same cv-qualifiers as |
| <code>T</code>. |
| |
| <i>Requires:</i> <code>T</code> shall be a (possibly |
| cv-qualified) integral type or enumeration but not a |
| <code>bool</code> type. |
| </td> |
| </tr> |
| <tr> |
| <td> |
| <tt>template <class T> struct make_unsigned;</tt> |
| </td> |
| <td> |
| If <code>T</code> names a (possibly cv-qualified) |
| <del>unsigned integral type</del><ins>unsigned integer |
| type</ins> (3.9.1) then the member typedef <code>type</code> |
| shall name the type <code>T</code>; otherwise, if |
| <code>T</code> names a (possibly cv-qualified) <del>signed |
| integral type</del><ins>signed integer type</ins> then |
| <code>type</code> shall name the corresponding <del>unsigned |
| integral type</del><ins>unsigned integer type</ins>, with the |
| same cv-qualifiers as <code>T</code>; otherwise, |
| <code>type</code> shall name the <del>unsigned integral |
| type</del><ins>unsigned integer type</ins> with the smallest |
| rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>, |
| with the same cv-qualifiers as <code>T</code>. |
| |
| <i>Requires:</i> <code>T</code> shall be a (possibly |
| cv-qualified) integral type or enumeration but not a |
| <code>bool</code> type. |
| </td> |
| </tr> |
| </tbody> |
| </table> |
| </blockquote> |
| |
| |
| <p> |
| Note: I believe that the basefield values should probably be |
| prefixed with <tt>ios_base::</tt> as they are in 22.2.2.2.2 [facet.num.put.virtuals] |
| |
| The listed virtuals are all overloaded on signed and unsigned integer |
| types, the new wording just maintains consistency. |
| |
| 22.2.2.1.2 [facet.num.get.virtuals] table 78... |
| </p> |
| <blockquote> |
| Table 78: Integer Conversions |
| <table border="1"> |
| <thead> |
| <tr> |
| <th>State</th> |
| <th><tt>stdio</tt> equivalent</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td><tt>basefield == oct</tt></td> |
| <td><tt>%o</tt></td> |
| </tr> |
| <tr> |
| <td><tt>basefield == hex</tt></td> |
| <td><tt>%X</tt></td> |
| </tr> |
| <tr> |
| <td><tt>basefield == 0</tt></td> |
| <td><tt>%i</tt></td> |
| </tr> |
| <tr> |
| <td><del>signed integral type</del><ins>signed integer |
| type</ins></td> |
| <td><tt>%d</tt></td> |
| </tr> |
| <tr> |
| <td><del>unsigned integral type</del><ins>unsigned integer |
| type</ins></td> |
| <td><tt>%u</tt></td> |
| </tr> |
| </tbody> |
| </table> |
| </blockquote> |
| |
| |
| |
| <p> |
| Rationale is same as above. |
| 22.2.2.2.2 [facet.num.put.virtuals] table 80... |
| </p> |
| <blockquote> |
| Table 80: Integer Conversions |
| <table border="1"> |
| <thead> |
| <tr> |
| <th>State</th> |
| <th><tt>stdio</tt> equivalent</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td><tt>basefield == ios_base::oct</tt></td> |
| <td><tt>%o</tt></td> |
| </tr> |
| <tr> |
| <td><tt>(basefield == ios_base::hex) && |
| !uppercase</tt></td> |
| <td><tt>%x</tt></td> |
| </tr> |
| <tr> |
| <td><tt>(basefield == ios_base::hex)</tt></td> |
| <td><tt>%X</tt></td> |
| </tr> |
| <tr> |
| <td><tt>basefield == 0</tt></td> |
| <td><tt>%i</tt></td> |
| </tr> |
| <tr> |
| <td>for a <del>signed integral type</del><ins>signed integer |
| type</ins></td> |
| <td><tt>%d</tt></td> |
| </tr> |
| <tr> |
| <td>for a <del>unsigned integral type</del><ins>unsigned integer |
| type</ins></td> |
| <td><tt>%u</tt></td> |
| </tr> |
| </tbody> |
| </table> |
| </blockquote> |
| |
| |
| <p> |
| 23.1 [container.requirements] table 80... |
| </p> |
| <blockquote> |
| Table 89: Container requirements |
| <table border="1"> |
| <thead> |
| <tr> |
| <th>expression</th> |
| <th>return type</th> |
| <th>operational semantics</th> |
| <th>assertion/note/pre/post-condition</th> |
| <th>complexity</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td><tt>X::difference_type</tt></td> |
| <td><del>signed integral type</del><ins>signed integer type</ins></td> |
| <td> </td> |
| <td>is identical to the difference type of <tt>X::iterator</tt> |
| and <tt>X::const_iterator</tt></td> |
| <td>compile time</td> |
| </tr> |
| <tr> |
| <td><tt>X::size_type</tt></td> |
| <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td> |
| <td> </td> |
| <td><tt>size_type</tt> can represent any non-negative value of |
| <tt>difference_type</tt></td> |
| <td>compile time</td> |
| </tr> |
| </tbody> |
| </table> |
| </blockquote> |
| |
| <p> |
| 24.1 [iterator.requirements] paragraph 1... |
| </p> |
| <blockquote> |
| Iterators are a generalization of pointers that allow a C++ program to |
| work with different data structures (containers) in a uniform manner. |
| To be able to construct template algorithms that work correctly and |
| efficiently on different types of data structures, the library |
| formalizes not just the interfaces but also the semantics and |
| complexity assumptions of iterators. All input iterators |
| <code>i</code> support the expression <code>*i</code>, resulting in a |
| value of some class, enumeration, or built-in type <code>T</code>, |
| called the <i>value type</i> of the iterator. All output iterators |
| support the expression <code>*i = o</code> where <code>o</code> is a |
| value of some type that is in the set of types that are |
| <i>writable</i> to the particular iterator type of <code>i</code>. All |
| iterators <code>i</code> for which the expression <code>(*i).m</code> |
| is well-defined, support the expression <code>i->m</code> with the |
| same semantics as <code>(*i).m</code>. For every iterator type |
| <code>X</code> for which equality is defined, there is a corresponding |
| <del>signed integral type</del> <ins>signed integer type</ins> called |
| the <i>difference type</i> of the iterator. |
| </blockquote> |
| |
| <p> |
| I'm a little unsure of this change. Previously this paragraph would |
| allow instantiations of <tt>linear_congruential_engine</tt> on |
| <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The |
| new wording prohibits this. |
| 26.4.3.1 [rand.eng.lcong] paragraph 2... |
| </p> |
| <blockquote> |
| The template parameter <code>UIntType</code> shall denote an |
| <del>unsigned integral type</del><ins>unsigned integer type</ins> |
| large enough to store values as large as <code>m - 1</code>. If the |
| template parameter <code>m</code> is 0, the modulus <code>m</code> |
| used throughout this section 26.4.3.1 is |
| <code>numeric_limits<result_type>::max()</code> plus 1. [Note: |
| The result need not be representable as a value of type |
| <code>result_type</code>. --end note] Otherwise, the following |
| relations shall hold: <code>a < m</code> and <code>c < |
| m</code>. |
| </blockquote> |
| |
| <p> |
| Same rationale as the previous change. |
| 26.4.4.4 [rand.adapt.xor] paragraph 6... |
| </p> |
| <blockquote> |
| Both <code>Engine1::result_type</code> and |
| <code>Engine2::result_type</code> shall denote (possibly different) |
| <del>unsigned integral types</del><ins>unsigned integer types</ins>. |
| The member <i>result_type</i> shall denote either the type |
| <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>, |
| whichever provides the most storage according to clause 3.9.1. |
| </blockquote> |
| |
| <p> |
| 26.4.7.1 [rand.util.seedseq] paragraph 7... |
| </p> |
| <blockquote> |
| <i>Requires:</i><code>RandomAccessIterator</code> shall meet the |
| requirements of a random access iterator (24.1.5) such that |
| <code>iterator_traits<RandomAccessIterator>::value_type</code> |
| shall denote an <del>unsigned integral type</del><ins>unsigned integer |
| type</ins> capable of accomodating 32-bit quantities. |
| </blockquote> |
| |
| <p> |
| By making this change, integral types that happen to have a signed |
| representation, but are not signed integer types, would no longer be |
| required to use a two's complement representation. This may go against |
| the original intent, and should be reviewed. |
| 29.4 [atomics.types.operations] paragraph 24... |
| </p> |
| <blockquote> |
| <i>Remark:</i> For <del>signed integral types</del><ins>signed integer |
| types</ins>, arithmetic is defined using two's complement |
| representation. There are no undefined results. For address types, the |
| result may be an undefined address, but the operations otherwise have |
| no undefined behavior. |
| </blockquote> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3> |
| <p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| During the Sophia Antipolis meeting it was decided to separate from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a> a |
| subrequest that adds initializer list support to |
| <tt>discrete_distribution</tt>, specifically, |
| the issue proposed to add a c'tor taking a <tt>initializer_list<double></tt>. |
| </p> |
| |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <ol> |
| <li> |
| <p> |
| In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, |
| just <em>before</em> the member declaration |
| </p> |
| |
| <blockquote><pre>explicit discrete_distribution(const param_type& parm); |
| </pre></blockquote> |
| |
| <p> |
| insert |
| </p> |
| |
| <blockquote><pre>discrete_distribution(initializer_list<double> wl); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p> |
| Between p.4 and p.5 of the same section insert a new |
| paragraph as part of the new member description: |
| </p> |
| |
| <blockquote><pre>discrete_distribution(initializer_list<double> wl); |
| </pre> |
| |
| <blockquote> |
| <i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>. |
| </blockquote> |
| </blockquote> |
| </li> |
| </ol> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3> |
| <p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p> |
| <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| During the Sophia Antipolis meeting it was decided to separate from |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a> a subrequest that adds initializer list support to |
| <tt>piecewise_constant_distribution</tt>, specifically, the issue proposed |
| to add a c'tor taking a <tt>initializer_list<double></tt> and a <tt>Callable</tt> to evaluate |
| weight values. For consistency with the remainder of this class and |
| the remainder of the <tt>initializer_list</tt>-aware library the author decided to |
| change the list argument type to the template parameter <tt>RealType</tt> |
| instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&&</tt> as c'tor |
| function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <ol> |
| <li> |
| <p> |
| In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>, |
| just <em>before</em> the member declaration |
| </p> |
| |
| <blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm); |
| </pre></blockquote> |
| |
| <p> |
| insert |
| </p> |
| |
| <blockquote><pre>template<typename Func> |
| piecewise_constant_distribution(initializer_list<RealType> bl, Func fw); |
| </pre></blockquote> |
| </li> |
| |
| <li> |
| <p> |
| Between p.4 and p.5 of the same section insert a series of |
| new paragraphs nominated below as [p5_1], [p5_2], and [p5_3] |
| as part of the new member description: |
| </p> |
| |
| <blockquote><pre>template<typename Func> |
| piecewise_constant_distribution(initializer_list<RealType> bl, Func fw); |
| </pre> |
| |
| <blockquote> |
| |
| <p> |
| [p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>. |
| </p> |
| |
| <p> |
| [p5_2] <i>Requires:</i> |
| </p> |
| |
| <ol type="a"> |
| <li> |
| <tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall |
| return values of a type convertible to <tt>double</tt>; |
| </li> |
| <li> |
| The relation <tt>0 < S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold. |
| For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight |
| value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity; |
| </li> |
| <li> |
| If <tt>nf > 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the |
| following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> < b<sub><i>k+1</i></sub></tt>. |
| </li> |
| </ol> |
| |
| <p> |
| [p5_3] <i>Effects:</i> |
| </p> |
| |
| <ol type="a"> |
| <li> |
| <p>If <tt>nf == 0</tt>,</p> |
| <ol type="a"> |
| <li> |
| lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single |
| value <tt>w<sub>0</sub> = 1</tt>, and |
| </li> |
| <li> |
| lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>. |
| </li> |
| </ol> |
| </li> |
| |
| <li> |
| <p>Otherwise,</p> |
| <ol type="a"> |
| <li> |
| sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of |
| length <tt>n+1</tt>, and |
| </li> |
| <li> |
| <p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>, |
| calculates:</p> |
| <blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>) |
| w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>) |
| </pre></blockquote> |
| </li> |
| </ol> |
| </li> |
| |
| <li> |
| <p> |
| Constructs a <tt>piecewise_constant_distribution</tt> object with |
| the above computed sequence <tt>b</tt> as the interval boundaries |
| and with the probability densities: |
| </p> |
| <blockquote><pre>ρ<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1. |
| </pre></blockquote> |
| |
| </li> |
| </ol> |
| |
| </blockquote> |
| </blockquote> |
| </li> |
| </ol> |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3> |
| <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#New">New</a> |
| <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p> |
| <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| During the Sophia Antipolis meeting it was decided to split-off some |
| parts of the |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a> |
| ("Concurrency modifications for <tt>basic_string</tt>") |
| proposal into a separate issue, because these weren't actually |
| concurrency-related. The here proposed changes refer to the recent |
| update document |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a> |
| and attempt to take advantage of the |
| stricter structural requirements. |
| </p> |
| <p> |
| Indeed there exists some leeway for more guarantees that would be |
| very useful for programmers, especially if interaction with transactionary |
| or exception-unaware C API code is important. This would also allow |
| compilers to take advantage of more performance optimizations, because |
| more functions can have throw() specifications. This proposal uses the |
| form of "Throws: Nothing" clauses to reach the same effect, because |
| there already exists a different issue in progress to clean-up the current |
| existing "schizophrenia" of the standard in this regard. |
| </p> |
| <p> |
| Due to earlier support for copy-on-write, we find the following |
| unnecessary limitations for C++0x: |
| </p> |
| |
| <ol> |
| <li> |
| Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return |
| a pointer to their guts, which is a non-failure operation. This should |
| be spelled out. It is also noteworthy to mention that the same |
| guarantees should also be given by the size query functions, |
| because the combination of pointer to content and the length is |
| typically needed during interaction with low-level API. |
| </li> |
| <li> |
| Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return |
| a pointer to their guts, which is guaranteed O(1). This should be |
| spelled out. |
| </li> |
| <li> |
| Missing reading access to the terminating character: Only the |
| const overload of <tt>operator[]</tt> allows reading access to the terminator |
| char. For more intuitive usage of strings, reading access to this |
| position should be extended to the non-const case. In contrast |
| to C++03 this reading access should now be homogeneously |
| an lvalue access. |
| </li> |
| </ol> |
| |
| <p> |
| The proposed resolution is split into a main part (A) and a |
| secondary part (B) (earlier called "Adjunct Adjunct Proposal"). |
| (B) extends (A) by also making access to index position |
| size() of the at() overloads a no-throw operation. This was |
| separated, because this part is theoretically observable in |
| specifically designed test programs. |
| </p> |
| |
| |
| <p><b>Proposed resolution:</b></p> |
| <ol type="A"> |
| <li> |
| <ol> |
| <li> |
| <p>In 21.3.4 [string.capacity], just after p. 1 add a new paragraph: |
| </p> |
| <blockquote> |
| <i>Throws:</i> Nothing. |
| </blockquote> |
| |
| </li> |
| <li> |
| <p> |
| In 21.3.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs: |
| </p> |
| |
| <blockquote> |
| <p> |
| <i>Requires:</i> <tt>pos ≤ size()</tt>. |
| </p> |
| <p> |
| <i>Returns:</i> If <tt>pos < size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns |
| a reference to a <tt>charT()</tt> that shall not be modified. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| <p> |
| <i>Complexity:</i> Constant time. |
| </p> |
| </blockquote> |
| |
| </li> |
| <li> |
| <p> |
| In 21.3.7.1 [string.accessors] replace the now <em>common</em> returns |
| clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs: |
| </p> |
| <blockquote> |
| <p> |
| <i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &operator[](i)</tt> for each <tt>i</tt> |
| in <tt>[0, size()]</tt>. |
| </p> |
| <p> |
| <i>Throws:</i> Nothing. |
| </p> |
| <p> |
| <i>Complexity:</i> Constant time. |
| </p> |
| </blockquote> |
| </li> |
| </ol> |
| </li> |
| <li> |
| <ol start="4"> |
| <li> |
| <p> |
| In 21.3.5 [string.access] <em>replace</em> p.2 and p.3 by: |
| </p> |
| <blockquote> |
| <p> |
| <i>Requires:</i> <tt>pos ≤ size()</tt> |
| </p> |
| <p> |
| <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>. |
| </p> |
| </blockquote> |
| </li> |
| </ol> |
| </li> |
| </ol> |
| |
| |
| |
| |
| |
| |
| <hr> |
| <h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3> |
| <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p> |
| <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> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| Recent changes to |
| the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working |
| draft</a> have introduced a gratuitous inconsistency with the C++ 2003 |
| version of the specification with respect to exception guarantees |
| provided by standard functions. While the C++ 2003 standard |
| consistenly uses the empty exception specification, <tt>throw()</tt>, |
| to declare functions that are guaranteed not to throw exceptions, the |
| current working draft contains a number of "<i>Throws:</i> Nothing." |
| clause to specify essentially the same requirement. The difference |
| between the two approaches is that the former specifies the behavior |
| of programs that violate the requirement (<tt>std::unexpected()</tt> |
| is called) while the latter leaves the behavior undefined. |
| |
| </p> |
| <p> |
| |
| A survey of the working draft reveals that there are a total of 209 |
| occurrences of <tt>throw()</tt> in the library portion of the spec, |
| the majority in clause 18, a couple (literally) in 19, a handful in |
| 20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9. |
| |
| </p> |
| <p> |
| |
| There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered |
| throughout the spec. |
| |
| </p> |
| <p> |
| |
| While sometimes there are good reasons to use the "<i>Throws:</i> |
| Nothing." approach rather than making use of <tt>throw()</tt>, these |
| reasons do not apply in most of the cases where this new clause has |
| been introduced and the empty exception specification would be a |
| better approach. |
| |
| </p> |
| <p> |
| |
| First, functions declared with the empty exception specification |
| permit compilers to generate better code for calls to such |
| functions. In some cases, the compiler might even be able to eliminate |
| whole chunks of user-written code when instantiating a generic |
| template on a type whose operations invoked from the template |
| specialization are known not to throw. The prototypical example are |
| the <tt>std::uninitialized_copy()</tt> |
| and <tt>std::uninitialized_fill()</tt> algorithms where the |
| entire <tt>catch(...)</tt> block can be optimized away. |
| |
| </p> |
| <p> |
| |
| For example, given the following definition of |
| the <tt>std::uninitialized_copy</tt> function template and a |
| user-defined type <tt>SomeType</tt>: |
| |
| </p> |
| <blockquote> |
| <pre>template <class InputIterator, class ForwardIterator> |
| ForwardIterator |
| uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res) |
| { |
| typedef iterator_traits<ForwardIterator>::value_type ValueType; |
| |
| ForwardIterator start = res; |
| |
| try { |
| for (; first != last; ++first, ++res) |
| ::new (&*res) ValueType (*first); |
| } |
| catch (...) { |
| for (; start != res; --start) |
| (&*start)->~ValueType (); |
| throw; |
| } |
| return res; |
| } |
| |
| struct SomeType { |
| SomeType (const SomeType&) <ins>throw ()</ins>; |
| }</pre> |
| </blockquote> |
| <p> |
| |
| compilers are able to emit the following efficient specialization |
| of <tt>std::uninitialized_copy<const SomeType*, SomeType*></tt> |
| (note that the <tt>catch</tt> block has been optimized away): |
| |
| </p> |
| <blockquote> |
| <pre>template <> SomeType* |
| uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res) |
| { |
| for (; first != last; ++first, ++res) |
| ::new (res) SomeType (*first); |
| |
| return res; |
| }</pre> |
| </blockquote> |
| <p> |
| |
| Another general example is default constructors which, when decorated |
| with <tt>throw()</tt>, allow the compiler to eliminate the |
| implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must |
| emit around each the invocation of the constructor |
| in <i>new-expressions</i>. |
| |
| </p> |
| <p> |
| |
| For example, given the following definitions of |
| class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two |
| statements below: |
| |
| </p> |
| <blockquote> |
| <pre>struct MayThrow { |
| MayThrow (); |
| }; |
| |
| struct WontThrow { |
| WontThrow () <ins>throw ()</ins>; |
| }; |
| |
| MayThrow *a = new MayThrow [N]; |
| WontThrow *b = new WontThrow [N];</pre> |
| |
| </blockquote> |
| <p> |
| |
| the compiler generates the following code for the first statement: |
| |
| </p> |
| <blockquote> |
| <pre>MayThrow *a; |
| { |
| MayThrow *first = operator new[] (N * sizeof (*a)); |
| MayThrow *last = first + N; |
| MayThrow *next = first; |
| try { |
| for ( ; next != last; ++next) |
| new (next) MayThrow; |
| } |
| catch (...) { |
| for ( ; first != first; --next) |
| next->~MayThrow (); |
| operator delete[] (first); |
| throw; |
| } |
| a = first; |
| }</pre> |
| </blockquote> |
| <p> |
| |
| but it is can generate much more compact code for the second statement: |
| |
| </p> |
| <blockquote> |
| <pre>WontThrow *b = operator new[] (N * sizeof (*b)); |
| WontThrow *last = b + N; |
| for (WontThrow *next = b; next != last; ++next) |
| new (next) WontThrow; |
| </pre> |
| </blockquote> |
| <p> |
| |
| Second, in order for users to get the maximum benefit out of the new |
| <tt>std::has_nothrow_xxx</tt> traits when using standard library types |
| it will be important for implementations to decorate all non throwing |
| copy constructors and assignment operators with <tt>throw()</tt>. Note |
| that while an optimizer may be able to tell whether a function without |
| an explicit exception specification can throw or not based on its |
| definition, it can only do so when it can see the source code of the |
| definition. When it can't it must assume that the function may |
| throw. To prevent violating the One Definition Rule, |
| the <tt>std::has_nothrow_xxx</tt> trait must return the most |
| pessimistic guess across all translation units in the program, meaning |
| that <tt>std::has_nothrow_xxx<T>::value</tt> must evaluate to |
| <tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt> |
| (where <tt>xxx</tt> is default or copy ctor, or assignment operator) |
| is defined out-of-line. |
| |
| </p> |
| <p> |
| |
| <b>Counterarguments:</b> |
| |
| </p> |
| <p> |
| |
| During the discussion of this issue |
| on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a> |
| (starting with post <tt>c++std-lib-21950</tt>) the following arguments |
| in favor of the "<i>Throws:</i> Nothing." style have been made. |
| |
| </p> |
| <p> |
| </p><ol> |
| <li> |
| |
| Decorating functions that cannot throw with the empty exception |
| specification can cause the compiler to generate suboptimal code for |
| the implementation of the function when it calls other functions that |
| aren't known to the compiler not to throw (i.e., that aren't decorated |
| with <tt>throw()</tt> even if they don't actually throw). This is a |
| common situation when the called function is a C or POSIX function. |
| |
| </li> |
| <li> |
| |
| Alternate, proprietary mechanisms exist (such as |
| GCC <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-2160"><tt>__attribute__((nothrow))</tt></a> |
| or Visual |
| C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04%28VS.80%29.aspx"><tt>__declspec(nothrow)</tt></a>) |
| that let implementers mark up non-throwing functions, often without |
| the penalty mentioned in (1) above. The C++ standard shouldn't |
| preclude the use of these potentially more efficient mechanisms. |
| |
| </li> |
| <li> |
| |
| There are functions, especially function templates, that invoke |
| user-defined functions that may or may not be |
| declared <tt>throw()</tt>. Declaring such functions with the empty |
| exception specification will cause compilers to generate suboptimal |
| code when the user-defined function isn't also declared not to throw. |
| |
| </li> |
| </ol> |
| |
| <p> |
| |
| The answer to point (1) above is that implementers can (and some have) |
| declare functions with <tt>throw()</tt> to indicate to the compiler |
| that calls to the function can safely be assumed not to throw in order |
| to allow it to generate efficient code at the call site without also |
| having to define the functions the same way and causing the compiler |
| to generate suboptimal code for the function definition. That is, the |
| function is declared with <tt>throw()</tt> in a header but it's |
| defined without it in the source file. The <tt>throw()</tt> |
| declaration is suppressed when compiling the definition to avoid |
| compiler errors. This technique, while strictly speaking no permitted |
| by the language, is safe and has been employed in practice. For |
| example, the GNU C library takes this approach. Microsoft Visual C++ |
| takes a similar approach by simply assuming that no function with C |
| language linkage can throw an exception unless it's explicitly |
| declared to do so using the language extension <tt>throw(...)</tt>. |
| |
| </p> |
| <p> |
| |
| Our answer to point (2) above is that there is no existing practice |
| where C++ Standard Library implementers have opted to make use of the |
| proprietary mechanisms to declare functions that don't throw. The |
| language provides a mechanism specifically designed for this |
| purpose. Avoiding its use in the specification itself in favor of |
| proprietary mechanisms defeats the purpose of the feature. In |
| addition, making use of the empty exception specification |
| inconsistently, in some areas of the standard, while conspicuously |
| avoiding it and making use of the "<i>Throws:</i> Nothing." form in |
| others is confusing to users. |
| |
| </p> |
| <p> |
| |
| The answer to point (3) is simply to exercise caution when declaring |
| functions and especially function templates with the empty exception |
| specification. Functions that required not to throw but that may call |
| back into user code are poor candidates for the empty exception |
| specification and should instead be specified using "<i>Throws:</i> |
| Nothing." clause. |
| |
| </p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| We propose two possible solutions. Our recommendation is to adopt |
| Option 1 below. |
| |
| </p> |
| <p> |
| |
| <b>Option 1:</b> |
| |
| </p> |
| <p> |
| |
| Except for functions or function templates that make calls back to |
| user-defined functions that may not be declared <tt>throw()</tt> |
| replace all occurrences of the "<i>Throws:</i> Nothing." clause with |
| the empty exception specification. Functions that are required not to |
| throw but that make calls back to user code should be specified to |
| "<i>Throw:</i> Nothing." |
| |
| </p> |
| <p> |
| |
| <b>Option 2:</b> |
| |
| </p> |
| <p> |
| |
| For consistency, replace all occurrences of the empty exception |
| specification with a "<i>Throws:</i> Nothing." clause. |
| |
| </p> |
| |
| |
| |
| |
| <hr> |
| <h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3> |
| <p><b>Section:</b> 23.2.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> |
| <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p> |
| <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> |
| <p><b>Discussion:</b></p> |
| <p> |
| |
| <tt>forward_list</tt> member functions that take |
| a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the |
| function signatures) argument have the following precondition: |
| |
| </p> |
| <blockquote> |
| |
| <i>Requires:</i> <tt>position</tt> is dereferenceable or equal |
| to <tt>before_begin()</tt>. |
| |
| </blockquote> |
| <p> |
| |
| I believe what's actually intended is this: |
| |
| </p> |
| <blockquote> |
| |
| <i>Requires:</i> <tt>position</tt> is in the range |
| [<tt>before_begin()</tt>, <tt>end()</tt>). |
| |
| </blockquote> |
| <p> |
| |
| That is, when it's dereferenceable, <tt>position</tt> must point |
| into <tt>*this</tt>, not just any <tt>forward_list</tt> object. |
| |
| </p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| Change the <i>Requires</i> clause as follows: |
| |
| </p> |
| <blockquote> |
| |
| <i>Requires:</i> <tt>position</tt> is <ins>in the range |
| [<tt>before_begin()</tt>, <tt>end()</tt>)</ins> <del>dereferenceable |
| or equal to <tt>before_begin()</tt></del>. |
| |
| </blockquote> |
| |
| |
| |
| |
| </body></html> |