diff options
Diffstat (limited to 'gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html')
-rw-r--r-- | gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html | 19718 |
1 files changed, 0 insertions, 19718 deletions
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html deleted file mode 100644 index 94b57c0a6..000000000 --- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html +++ /dev/null @@ -1,19718 +0,0 @@ -<!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>
\ No newline at end of file |