diff options
Diffstat (limited to 'gcc-4.4.3/libstdc++-v3/doc/html/ext')
300 files changed, 93869 insertions, 0 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 new file mode 100644 index 000000000..94b57c0a6 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html @@ -0,0 +1,19718 @@ +<!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 diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html new file mode 100644 index 000000000..a056c3ee2 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html @@ -0,0 +1,14016 @@ +<!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 Closed 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">N2729=08-0239</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 Closed 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-active.html">Library Active Issues List</a></li> + <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li> + </ul> + + <p>This document contains only library issues which have been closed + by the Library Working Group as duplicates or not defects. That is, + issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> or + <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> active issues and more + information. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered + defects. The introductory material in that document also applies to + this document.</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>Closed Issues</h2> +<hr> +<h3><a name="2"></a>2. Auto_ptr conversions effects incorrect</h3> +<p><b>Section:</b> D.9.1.3 [auto.ptr.conv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1997-12-04</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Paragraph 1 in "Effects", says "Calls +p->release()" where it clearly must be "Calls +p.release()". (As it is, it seems to require using +auto_ptr<>::operator-> to refer to X::release, assuming that +exists.)</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from +"Calls p->release()" to "Calls p.release()".</p> + + +<p><b>Rationale:</b></p> +<p>Not a defect: the proposed change is already found in the standard. +[Originally classified as a defect, later reclassified.]</p> + + + + + +<hr> +<h3><a name="4"></a>4. Basic_string size_type and difference_type should be implementation defined</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#NAD">NAD</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>In Morristown we changed the size_type and difference_type typedefs +for all the other containers to implementation defined with a +reference to 23.1 [container.requirements]. This should probably also have been +done for strings. </p> + + +<p><b>Rationale:</b></p> +<p>Not a defect. [Originally classified as a defect, later +reclassified.] basic_string, unlike the other standard library +template containers, is severely constrained by its use of +char_traits. Those types are dictated by the traits class, and are far +from implementation defined.</p> + + + + + +<hr> +<h3><a name="6"></a>6. File position not an offset unimplementable</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#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Table 88, in I/O, is too strict; it's unimplementable on systems +where a file position isn't just an offset. It also never says just +what fpos<> is really supposed to be. [Here's my summary, which +Jerry agrees is more or less accurate. "I think I now know what +the class really is, at this point: it's a magic cookie that +encapsulates an mbstate_t and a file position (possibly represented as +an fpos_t), it has syntactic support for pointer-like arithmetic, and +implementors are required to have real, not just syntactic, support +for arithmetic." This isn't standardese, of course.] </p> + + +<p><b>Rationale:</b></p> +<p>Not a defect. The LWG believes that the Standard is already clear, +and that the above summary is what the Standard in effect says.</p> + + + + + +<hr> +<h3><a name="10"></a>10. Codecvt<>::do unclear</h3> +<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a></p> +<p><b>Discussion:</b></p> +<p>Section 22.2.1.5.2 says that codecvt<>::do_in and do_out +should return the value noconv if "no conversion was +needed". However, I don't see anything anywhere that defines what +it means for a conversion to be needed or not needed. I can think of +several circumstances where one might plausibly think that a +conversion is not "needed", but I don't know which one is +intended here. </p> + + +<p><b>Rationale:</b></p> + + + + + + +<hr> +<h3><a name="12"></a>12. Way objects hold allocators unclear</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#NAD">NAD</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-02-23</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>I couldn't find a statement in the standard saying whether the allocator object held by +a container is held as a copy of the constructor argument or whether a pointer of +reference is maintained internal. There is an according statement for compare objects and +how they are maintained by the associative containers, but I couldn't find anything +regarding allocators. </p> + +<p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left +unspecified? </p> + + +<p><b>Rationale:</b></p> +<p>Not a defect. The LWG believes that the Standard is already +clear. See 23.1 [container.requirements], paragraph 8.</p> + + + + + +<hr> +<h3><a name="43"></a>43. Locale table correction</h3> +<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a></p> +<p><b>Discussion:</b></p> + + +<p><b>Rationale:</b></p> + + + + + + +<hr> +<h3><a name="45"></a>45. Stringstreams read/write pointers initial position unclear</h3> +<p><b>Section:</b> 27.7.3 [ostringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Matthias Mueller <b>Date:</b> 1998-05-27</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>In a comp.lang.c++.moderated Matthias Mueller wrote:</p> + +<p>"We are not sure how to interpret the CD2 (see 27.2 +[iostream.forward], 27.7.3.1 [ostringstream.cons], 27.7.1.1 +[stringbuf.cons]) +with respect to the question as to what the correct initial positions +of the write and read pointers of a stringstream should +be."</p> + +<p>"Is it the same to output two strings or to initialize the stringstream with the +first and to output the second?"</p> + +<p><i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and +Jerry Schwarz have all offered opinions; see reflector messages +lib-6518, 6519, 6520, 6521, 6523, 6524.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The LWG believes the Standard is correct as written. The behavior +of stringstreams is consistent with fstreams, and there is a +constructor which can be used to obtain the desired effect. This +behavior is known to be different from strstreams.</p> + + + + + +<hr> +<h3><a name="58"></a>58. Extracting a char from a wide-oriented stream</h3> +<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.6.1.2.3 has member functions for extraction of signed char and +unsigned char, both singly and as strings. However, it doesn't say +what it means to extract a <tt>char</tt> from a +<tt>basic_streambuf<charT, Traits></tt>. </p> + +<p>basic_streambuf, after all, has no members to extract a char, so +basic_istream must somehow convert from charT to signed char or +unsigned char. The standard doesn't say how it is to perform that +conversion. </p> + + +<p><b>Rationale:</b></p> +<p>The Standard is correct as written. There is no such extractor and +this is the intent of the LWG.</p> + + + + +<hr> +<h3><a name="65"></a>65. Underspecification of strstreambuf::seekoff</h3> +<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>The standard says how this member function affects the current +stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not +say how this member function affects the beginning and end of the +get/put area. </p> + +<p>This is an issue when seekoff is used to position the get pointer +beyond the end of the current read area. (Which is legal. This is +implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.) +</p> + + +<p><b>Rationale:</b></p> +<p>The LWG agrees that seekoff() is underspecified, but does not wish +to invest effort in this deprecated feature.</p> + + + + + +<hr> +<h3><a name="67"></a>67. Setw useless for strings</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#Dup">Dup</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-07-09</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#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a></p> +<p><b>Discussion:</b></p> +<p>In a comp.std.c++ posting Michel Michaud wrote: What +should be output by: </p> + +<pre> string text("Hello"); + cout << '[' << setw(10) << right << text << ']'; +</pre> + +<p>Shouldn't it be:</p> + +<pre> [ Hello]</pre> + +<p>Another person replied: Actually, according to the FDIS, the width +of the field should be the minimum of width and the length of the +string, so the output shouldn't have any padding. I think that this is +a typo, however, and that what is wanted is the maximum of the +two. (As written, setw is useless for strings. If that had been the +intent, one wouldn't expect them to have mentioned using its value.) +</p> + +<p>It's worth pointing out that this is a recent correction anyway; +IIRC, earlier versions of the draft forgot to mention formatting +parameters whatsoever.</p> + + +<p><b>Rationale:</b></p> + + + + + + +<hr> +<h3><a name="72"></a>72. Do_convert phantom member function</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#Dup">Dup</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-24</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#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a></p> +<p><b>Discussion:</b></p> +<p>In 22.2.1.4 [locale.codecvt] par 3, and in 22.2.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function +"do_convert" is mentioned. This member was replaced with +"do_in" and "do_out", the proper referents in the +contexts above.</p> + + +<p><b>Rationale:</b></p> + + + + + +<hr> +<h3><a name="73"></a>73. <tt>is_open</tt> should be const</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#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-27</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and +<tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It +should be a <tt>const</tt> member function, since it does nothing but +call one of <tt>basic_filebuf</tt>'s const member functions. </p> + + +<p><b>Rationale:</b></p> +<p>Not a defect. This is a deliberate feature; const streams would be +meaningless.</p> + + + + +<hr> +<h3><a name="77"></a>77. Valarray operator[] const returning value</h3> +<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Levente Farkas <b>Date:</b> 1998-09-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a></p> +<p><b>Discussion:</b></p> +<p>valarray:<br> +<br> + <tt>T operator[] (size_t) const;</tt><br> +<br> +why not <br> +<br> + <tt>const T& operator[] (size_t) const;</tt><br> +<br> +as in vector ???<br> +<br> +One can't copy even from a const valarray eg:<br> +<br> + <tt>memcpy(ptr, &v[0], v.size() * sizeof(double));<br> +</tt><br> +[I] find this bug in valarray is very difficult.</p> + + +<p><b>Rationale:</b></p> +<p>The LWG believes that the interface was deliberately designed that +way. That is what valarray was designed to do; that's where the +"value array" name comes from. LWG members further comment +that "we don't want valarray to be a full STL container." +26.5.2.3 [valarray.access] specifies properties that indicate "an +absence of aliasing" for non-constant arrays; this allows +optimizations, including special hardware optimizations, that are not +otherwise possible. </p> + + + + + +<hr> +<h3><a name="81"></a>81. Wrong declaration of slice operations</h3> +<p><b>Section:</b> 26.5.5 [template.slice.array], 26.5.7 [template.gslice.array], 26.5.8 [template.mask.array], 26.5.9 [template.indirect.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Isn't the definition of copy constructor and assignment operators wrong? + Instead of</p> + +<pre> slice_array(const slice_array&); + slice_array& operator=(const slice_array&);</pre> + +<p>IMHO they have to be</p> + +<pre> slice_array(const slice_array<T>&); + slice_array& operator=(const slice_array<T>&);</pre> + +<p>Same for gslice_array. </p> + + +<p><b>Rationale:</b></p> +<p>Not a defect. The Standard is correct as written. </p> + + + + +<hr> +<h3><a name="82"></a>82. Missing constant for set elements</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Paragraph 5 specifies:</p> + +<blockquote><p> +For set and multiset the value type is the same as the key type. For +map and multimap it is equal to pair<const Key, T>. +</p></blockquote> + +<p>Strictly speaking, this is not correct because for set and multiset +the value type is the same as the <b>constant</b> key type.</p> + + +<p><b>Rationale:</b></p> +<p>Not a defect. The Standard is correct as written; it uses a +different mechanism (const &) for <tt>set</tt> and +<tt>multiset</tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for a related +issue.</p> + + + + +<hr> +<h3><a name="84"></a>84. Ambiguity with string::insert()</h3> +<p><b>Section:</b> 21.3.5 [string.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>If I try</p> +<pre> s.insert(0,1,' ');</pre> + +<p> I get an nasty ambiguity. It might be</p> +<pre> s.insert((size_type)0,(size_type)1,(charT)' ');</pre> + +<p>which inserts 1 space character at position 0, or</p> +<pre> s.insert((char*)0,(size_type)1,(charT)' ')</pre> + +<p>which inserts 1 space character at iterator/address 0 (bingo!), or</p> +<pre> s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre> + +<p>which normally inserts characters from iterator 1 to iterator ' +'. But according to 23.1.1.9 (the "do the right thing" fix) +it is equivalent to the second. However, it is still ambiguous, +because of course I mean the first!</p> + + +<p><b>Rationale:</b></p> +<p>Not a defect. The LWG believes this is a "genetic +misfortune" inherent in the design of string and thus not a +defect in the Standard as such .</p> + + + + +<hr> +<h3><a name="85"></a>85. String char types</h3> +<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>The standard seems not to require that charT is equivalent to +traits::char_type. So, what happens if charT is not equivalent to +traits::char_type?</p> + + +<p><b>Rationale:</b></p> +<p>There is already wording in 21.1 [char.traits] paragraph 3 that +requires them to be the same.</p> + + + + +<hr> +<h3><a name="87"></a>87. Error in description of string::compare()</h3> +<p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a></p> +<p><b>Discussion:</b></p> +<p>The following compare() description is obviously a bug:</p> + +<pre>int compare(size_type pos, size_type n1, + charT *s, size_type n2 = npos) const; +</pre> + +<p>because without passing n2 it should compare up to the end of the +string instead of comparing npos characters (which throws an +exception) </p> + + +<p><b>Rationale:</b></p> + + + + + +<hr> +<h3><a name="88"></a>88. Inconsistency between string::insert() and string::append()</h3> +<p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.2 [string::append] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Why does </p> +<pre> template<class InputIterator> + basic_string& append(InputIterator first, InputIterator last);</pre> + +<p>return a string, while</p> +<pre> template<class InputIterator> + void insert(iterator p, InputIterator first, InputIterator last);</pre> + +<p>returns nothing ?</p> + + +<p><b>Rationale:</b></p> +<p>The LWG believes this stylistic inconsistency is not sufficiently +serious to constitute a defect.</p> + + + + +<hr> +<h3><a name="89"></a>89. Missing throw specification for string::insert() and string::replace()</h3> +<p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a></p> +<p><b>Discussion:</b></p> +<p>All insert() and replace() members for strings with an iterator as +first argument lack a throw specification. The throw +specification should probably be: length_error if size exceeds +maximum. </p> + + +<p><b>Rationale:</b></p> +<p>Considered a duplicate because it will be solved by the resolution +of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p> + + + + + +<hr> +<h3><a name="93"></a>93. Incomplete Valarray Subset Definitions</h3> +<p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>You can easily create subsets, but you can't easily combine them +with other subsets. Unfortunately, you almost always needs an +explicit type conversion to valarray. This is because the standard +does not specify that valarray subsets provide the same operations as +valarrays. </p> + +<p>For example, to multiply two subsets and assign the result to a third subset, you can't +write the following:</p> + +<pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre> + +<p>Instead, you have to code as follows:</p> + +<pre>va[slice(0,4,3)] = static_cast<valarray<double> >(va[slice(1,4,3)]) * + static_cast<valarray<double> >(va[slice(2,4,3)]);</pre> + +<p>This is tedious and error-prone. Even worse, it costs performance because each cast +creates a temporary objects, which could be avoided without the cast. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Extend all valarray subset types so that they offer all valarray operations.</p> + + +<p><b>Rationale:</b></p> +<p>This is not a defect in the Standard; it is a request for an extension.</p> + + + + +<hr> +<h3><a name="94"></a>94. May library implementors add template parameters to Standard Library classes?</h3> +<p><b>Section:</b> 17.4.4 [conforming] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Is it a permitted extension for library implementors to add template parameters to +standard library classes, provided that those extra parameters have defaults? For example, +instead of defining <tt>template <class T, class Alloc = allocator<T> > class +vector;</tt> defining it as <tt>template <class T, class Alloc = allocator<T>, +int N = 1> class vector;</tt> </p> + +<p>The standard may well already allow this (I can't think of any way that this extension +could break a conforming program, considering that users are not permitted to +forward-declare standard library components), but it ought to be explicitly permitted or +forbidden. </p> + +<p>comment from Steve Cleary via comp.std.c++:</p> +<blockquote> +<p>I disagree [with the proposed resolution] for the following reason: +consider user library code with template template parameters. For +example, a user library object may be templated on the type of +underlying sequence storage to use (deque/list/vector), since these +classes all take the same number and type of template parameters; this +would allow the user to determine the performance tradeoffs of the +user library object. A similar example is a user library object +templated on the type of underlying set storage (set/multiset) or map +storage (map/multimap), which would allow users to change (within +reason) the semantic meanings of operations on that object.</p> +<p>I think that additional template parameters should be forbidden in +the Standard classes. Library writers don't lose any expressive power, +and can still offer extensions because additional template parameters +may be provided by a non-Standard implementation class:</p> +<pre> + template <class T, class Allocator = allocator<T>, int N = 1> + class __vector + { ... }; + template <class T, class Allocator = allocator<T> > + class vector: public __vector<T, Allocator> + { ... }; +</pre> + +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.9 [res.on.exception.handling]:</p> + +<blockquote> + <p>17.4.4.9 Template Parameters</p> <p>A specialization of a + template class described in the C++ Standard Library behaves the + same as if the implementation declares no additional template + parameters.</p> <p>Footnote: Additional template parameters with + default values are thus permitted.</p> +</blockquote> + +<p>Add "template parameters" to the list of subclauses at +the end of 17.4.4 [conforming] paragraph 1.</p> + +<p><i>[Kona: The LWG agreed the standard needs clarification. After +discussion with John Spicer, it seems added template parameters can be +detected by a program using template-template parameters. A straw vote +- "should implementors be allowed to add template +parameters?" found no consensus ; 5 - yes, 7 - no.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p> +There is no ambiguity; the standard is clear as written. Library +implementors are not permitted to add template parameters to standard +library classes. This does not fall under the "as if" rule, +so it would be permitted only if the standard gave explicit license +for implementors to do this. This would require a change in the +standard. +</p> + +<p> +The LWG decided against making this change, because it would break +user code involving template template parameters or specializations +of standard library class templates. +</p> + + + + + +<hr> +<h3><a name="95"></a>95. Members added by the implementation</h3> +<p><b>Section:</b> 17.4.4.4 [member.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual +members a base class and break user derived classes.</p> + +<p>Example: </p> + +<blockquote> + <pre>// implementation code: +struct _Base { // _Base is in the implementer namespace + virtual void foo (); +}; +class vector : _Base // deriving from a class is allowed +{ ... }; + +// user code: +class vector_checking : public vector +{ + void foo (); // don't want to override _Base::foo () as the + // user doesn't know about _Base::foo () +};</pre> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>Clarify the wording to make the example illegal.</p> + + +<p><b>Rationale:</b></p> +<p>This is not a defect in the Standard. The example is already +illegal. See 17.4.4.4 [member.functions] paragraph 2.</p> + + + + +<hr> +<h3><a name="97"></a>97. Insert inconsistent definition</h3> +<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p><tt>insert(iterator, const value_type&)</tt> is defined both on +sequences and on set, with unrelated semantics: insert here (in +sequences), and insert with hint (in associative containers). They +should have different names (B.S. says: do not abuse overloading).</p> + + +<p><b>Rationale:</b></p> +<p>This is not a defect in the Standard. It is a genetic misfortune of +the design, for better or for worse.</p> + + + + +<hr> +<h3><a name="99"></a>99. Reverse_iterator comparisons completely wrong</h3> +<p><b>Section:</b> 24.4.1.3.13 [reverse.iter.op==] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>The <, >, <=, >= comparison operator are wrong: they +return the opposite of what they should.</p> + +<p>Note: same problem in CD2, these were not even defined in CD1. SGI +STL code is correct; this problem is known since the Morristown +meeting but there it was too late</p> + + +<p><b>Rationale:</b></p> +<p>This is not a defect in the Standard. A careful reading shows the Standard is correct +as written. A review of several implementations show that they implement +exactly what the Standard says.</p> + + + + +<hr> +<h3><a name="100"></a>100. Insert iterators/ostream_iterators overconstrained</h3> +<p><b>Section:</b> 24.4.2 [insert.iterators], 24.5.4 [ostreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Overspecified For an insert iterator it, the expression *it is +required to return a reference to it. This is a simple possible +implementation, but as the SGI STL documentation says, not the only +one, and the user should not assume that this is the case.</p> + + +<p><b>Rationale:</b></p> +<p>The LWG believes this causes no harm and is not a defect in the +standard. The only example anyone could come up with caused some +incorrect code to work, rather than the other way around.</p> + + + + + +<hr> +<h3><a name="101"></a>101. No way to free storage for vector and deque</h3> +<p><b>Section:</b> 23.2.6 [vector], 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Reserve can not free storage, unlike string::reserve</p> + + +<p><b>Rationale:</b></p> +<p>This is not a defect in the Standard. The LWG has considered this +issue in the past and sees no need to change the Standard. Deque has +no reserve() member function. For vector, shrink-to-fit can be +expressed in a single line of code (where <tt>v</tt> is +<tt>vector<T></tt>): +</p> + +<blockquote> + <p><tt>vector<T>(v).swap(v); // shrink-to-fit v</tt></p> +</blockquote> + + + + + +<hr> +<h3><a name="102"></a>102. Bug in insert range in associative containers</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</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#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a></p> +<p><b>Discussion:</b></p> +<p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems +impossible to implement, as it means that if [i, j) = [x], insert in an associative +container is O(1)!</p> + + +<p><b>Proposed resolution:</b></p> +<p>N+log (size()) if [i,j) is sorted according to value_comp()</p> + + +<p><b>Rationale:</b></p> +<p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>.</p> + + + + + +<hr> +<h3><a name="104"></a>104. Description of basic_string::operator[] is unclear</h3> +<p><b>Section:</b> 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <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#string.capacity">issues</a> in [string.capacity].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>It is not clear that undefined behavior applies when pos == size () +for the non const version.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Rewrite as: Otherwise, if pos > size () or pos == size () and +the non-const version is used, then the behavior is undefined.</p> + + +<p><b>Rationale:</b></p> +<p>The Standard is correct. The proposed resolution already appears in +the Standard.</p> + + + + +<hr> +<h3><a name="105"></a>105. fstream ctors argument types desired</h3> +<p><b>Section:</b> 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a></p> +<p><b>Discussion:</b></p> + + +<p>fstream ctors take a const char* instead of string.<br> +fstream ctors can't take wchar_t</p> + +<p>An extension to add a const wchar_t* to fstream would make the +implementation non conforming.</p> + + +<p><b>Rationale:</b></p> +<p>This is not a defect in the Standard. It might be an +interesting extension for the next Standard. </p> + + + + +<hr> +<h3><a name="107"></a>107. Valarray constructor is strange</h3> +<p><b>Section:</b> 26.5.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <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#template.valarray">issues</a> in [template.valarray].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>The order of the arguments is (elem, size) instead of the normal +(size, elem) in the rest of the library. Since elem often has an +integral or floating point type, both types are convertible to each +other and reversing them leads to a well formed program.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Inverting the arguments could silently break programs. Introduce +the two signatures (const T&, size_t) and (size_t, const T&), +but make the one we do not want private so errors result in a +diagnosed access violation. This technique can also be applied to STL +containers.</p> + + +<p><b>Rationale:</b></p> +<p>The LWG believes that while the order of arguments is unfortunate, +it does not constitute a defect in the standard. The LWG believes that +the proposed solution will not work for valarray<size_t> and +perhaps other cases.</p> + + + + +<hr> +<h3><a name="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3> +<p><b>Section:</b> 24.5.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-10-15</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> +<p><b>Discussion:</b></p> +<p>The member istreambuf_iterator<>::equal is specified to be +unnecessarily inefficient. While this does not affect the efficiency +of conforming implementations of iostreams, because they can +"reach into" the iterators and bypass this function, it does +affect users who use istreambuf_iterators. </p> + +<p>The inefficiency results from a too-scrupulous definition, which +requires a "true" result if neither iterator is at eof. In +practice these iterators can only usefully be compared with the +"eof" value, so the extra test implied provides no benefit, +but slows down users' code. </p> + +<p>The solution is to weaken the requirement on the function to return +true only if both iterators are at eof. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace 24.5.3.5 [istreambuf.iterator::equal], +paragraph 1, </p> + +<blockquote> + <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at + end-of-stream, regardless of what streambuf object they use. </p> +</blockquote> + +<p>with</p> + +<blockquote> + <p>-1- Returns: true if and only if both iterators are at + end-of-stream, regardless of what streambuf object they use. </p> +</blockquote> + + + +<p><b>Rationale:</b></p> +<p>It is not clear that this is a genuine defect. Additionally, the +LWG was reluctant to make a change that would result in +operator== not being a equivalence relation. One consequence of +this change is that an algorithm that's passed the range [i, i) +would no longer treat it as an empty range.</p> + + + + + +<hr> +<h3><a name="113"></a>113. Missing/extra iostream sync semantics</h3> +<p><b>Section:</b> 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-13</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3, +paragraph 36. </p> + +<p>Following the chain of definitions, I find that the various sync functions have defined +semantics for output streams, but no semantics for input streams. On the other hand, +basic_ostream has no sync function. </p> + +<p>The sync function should at minimum be added to basic_ostream, for internal +consistency. </p> + +<p>A larger question is whether sync should have assigned semantics for input streams. </p> + +<p>Classic iostreams said streambuf::sync flushes pending output and attempts to return +unread input characters to the source. It is a protected member function. The filebuf +version (which is public) has that behavior (it backs up the read pointer). Class +strstreambuf does not override streambuf::sync, and so sync can't be called on a +strstream. </p> + +<p>If we can add corresponding semantics to the various sync functions, we should. If not, +we should remove sync from basic_istream.</p> + + +<p><b>Rationale:</b></p> +<p>A sync function is not needed in basic_ostream because the flush function provides the +desired functionality.</p> + +<p>As for the other points, the LWG finds the standard correct as written.</p> + + + + + +<hr> +<h3><a name="116"></a>116. bitset cannot be constructed with a const char*</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#Dup">Dup</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-11-06</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#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a></p> +<p><b>Discussion:</b></p> + + + +<p>The following code does not compile with the EDG compiler:</p> + +<blockquote> + <pre>#include <bitset> +using namespace std; +bitset<32> b("111111111");</pre> +</blockquote> + +<p>If you cast the ctor argument to a string, i.e.:</p> + +<blockquote> + <pre>bitset<32> b(string("111111111"));</pre> +</blockquote> + +<p>then it will compile. The reason is that bitset has the following templatized +constructor:</p> + +<blockquote> + <pre>template <class charT, class traits, class Allocator> +explicit bitset (const basic_string<charT, traits, Allocator>& str, ...);</pre> +</blockquote> + +<p>According to the compiler vendor, Steve Adamcyk at EDG, the user +cannot pass this template constructor a <tt>const char*</tt> and +expect a conversion to <tt>basic_string</tt>. The reason is +"When you have a template constructor, it can get used in +contexts where type deduction can be done. Type deduction basically +comes up with exact matches, not ones involving conversions." +</p> + +<p>I don't think the intention when this constructor became +templatized was for construction from a <tt>const char*</tt> to no +longer work.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add to 23.3.5 [template.bitset] a bitset constructor declaration</p> + +<blockquote> + <pre>explicit bitset(const char*);</pre> +</blockquote> + +<p>and in Section 23.3.5.1 [bitset.cons] add:</p> + +<blockquote> + <pre>explicit bitset(const char* str);</pre> + <p>Effects: <br> + Calls <tt>bitset((string) str, 0, string::npos);</tt></p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>Although the problem is real, the standard is designed that way so +it is not a defect. Education is the immediate workaround. A future +standard may wish to consider the Proposed Resolution as an +extension.</p> + + + + + +<hr> +<h3><a name="121"></a>121. Detailed definition for ctype<wchar_t> specialization</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#NAD">NAD</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> , +ctype<wchar_t>. </p> + +<p>Also Section 22.2.1.1 [locale.ctype] says: </p> + +<blockquote> + <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and + ctype<wchar_t> , implement character classing appropriate to the implementation's + native character set. </p> +</blockquote> + +<p>However, Section 22.2.1.3 [facet.ctype.special] +only has a detailed description of the ctype<char> specialization, not the +ctype<wchar_t> specialization. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Add the ctype<wchar_t> detailed class description to Section +22.2.1.3 [facet.ctype.special]. </p> + + +<p><b>Rationale:</b></p> +<p>Specialization for wchar_t is not needed since the default is acceptable.</p> + + + + + +<hr> +<h3><a name="131"></a>131. list::splice throws nothing</h3> +<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>What happens if a splice operation causes the size() of a list to grow +beyond max_size()?</p> + + +<p><b>Rationale:</b></p> +<p>Size() cannot grow beyond max_size(). </p> + + + + + +<hr> +<h3><a name="135"></a>135. basic_iostream doubly initialized</h3> +<p><b>Section:</b> 27.6.1.5.1 [iostream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>-1- Effects Constructs an object of class basic_iostream, assigning +initial values to the base classes by calling +basic_istream<charT,traits>(sb) (lib.istream) and +basic_ostream<charT,traits>(sb) (lib.ostream)</p> + +<p>The called for basic_istream and basic_ostream constructors call +init(sb). This means that the basic_iostream's virtual base class is +initialized twice.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 27.6.1.5.1, paragraph 1 to:</p> + +<p>-1- Effects Constructs an object of class basic_iostream, assigning +initial values to the base classes by calling +basic_istream<charT,traits>(sb) (lib.istream).</p> + + +<p><b>Rationale:</b></p> +<p>The LWG agreed that the <tt> init()</tt> function is called +twice, but said that this is harmless and so not a defect in the +standard.</p> + + + + +<hr> +<h3><a name="138"></a>138. Class ctype_byname<char> redundant and misleading</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#NAD%20Future">NAD Future</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-18</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#NAD%20Future">NAD Future</a> status.</p> +<p><b>Discussion:</b></p> +<p>Section 22.2.1.4 [locale.codecvt] specifies that +ctype_byname<char> must be a specialization of the ctype_byname +template.</p> + +<p>It is common practice in the standard that specializations of class templates are only +mentioned where the interface of the specialization deviates from the interface of the +template that it is a specialization of. Otherwise, the fact whether or not a required +instantiation is an actual instantiation or a specialization is left open as an +implementation detail. </p> + +<p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The +fact, that ctype_byname<char> is specified as a specialization suggests that there +must be something "special" about it, but it has the exact same interface as the +ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best +redundant, at worst misleading - unless I am missing anything. </p> + +<p>Naturally, an implementation will most likely implement ctype_byname<char> as a +specialization, because the base class ctype<char> is a specialization with an +interface different from the ctype template, but that's an implementation detail and need +not be mentioned in the standard. </p> + + +<p><b>Rationale:</b></p> +<p> The standard as written is mildly misleading, but the correct fix +is to deal with the underlying problem in the ctype_byname base class, +not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p> + + + + +<hr> +<h3><a name="140"></a>140. map<Key, T>::value_type does not satisfy the assignable requirement</h3> +<p><b>Section:</b> 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Mark Mitchell <b>Date:</b> 1999-04-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<blockquote> + <p>23.1 [container.requirements]<br> + <br> + expression return type + pre/post-condition<br> + ------------- ----------- + -------------------<br> + X::value_type T + + T is assignable<br> + <br> + 23.3.1 [map]<br> + <br> + A map satisfies all the requirements of a container.<br> + <br> + For a map<Key, T> ... the value_type is pair<const Key, T>.</p> +</blockquote> + +<p>There's a contradiction here. In particular, `pair<const Key, +T>' is not assignable; the `const Key' cannot be assigned +to. So, map<Key, T>::value_type does not satisfy the +assignable requirement imposed by a container.</p> + +<p><i>[See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for the slightly related issue of +modification of set keys.]</i></p> + + + +<p><b>Rationale:</b></p> +<p>The LWG believes that the standard is inconsistent, but that this +is a design problem rather than a strict defect. May wish to +reconsider for the next standard.</p> + + + + +<hr> +<h3><a name="143"></a>143. C .h header wording unclear</h3> +<p><b>Section:</b> D.5 [depr.c.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Christophe de Dinechin <b>Date:</b> 1999-05-04</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>[depr.c.headers] paragraph 2 reads:</p> + +<blockquote> + +<p>Each C header, whose name has the form name.h, behaves as if each +name placed in the Standard library namespace by the corresponding +cname header is also placed within the namespace scope of the +namespace std and is followed by an explicit using-declaration +(_namespace.udecl_)</p> + +</blockquote> + +<p>I think it should mention the global name space somewhere... +Currently, it indicates that name placed in std is also placed in +std...</p> + +<p>I don't know what is the correct wording. For instance, if struct +tm is defined in time.h, ctime declares std::tm. However, the current +wording seems ambiguous regarding which of the following would occur +for use of both ctime and time.h:</p> + +<blockquote> + <pre>// version 1: +namespace std { + struct tm { ... }; +} +using std::tm; + +// version 2: +struct tm { ... }; +namespace std { + using ::tm; +} + +// version 3: +struct tm { ... }; +namespace std { + struct tm { ... }; +}</pre> +</blockquote> + +<p>I think version 1 is intended.</p> + +<p><i>[Kona: The LWG agreed that the wording is not clear. It also +agreed that version 1 is intended, version 2 is not equivalent to +version 1, and version 3 is clearly not intended. The example below +was constructed by Nathan Myers to illustrate why version 2 is not +equivalent to version 1.</i></p> + +<p><i>Although not equivalent, the LWG is unsure if (2) is enough of +a problem to be prohibited. Points discussed in favor of allowing +(2):</i></p> + +<blockquote> + <ul> + <li><i>It may be a convenience to implementors.</i></li> + <li><i>The only cases that fail are structs, of which the C library + contains only a few.</i></li> + </ul> +</blockquote> + +<p><i>]</i></p> + +<p><b>Example:</b></p> + +<blockquote> + +<pre>#include <time.h> +#include <utility> + +int main() { + std::tm * t; + make_pair( t, t ); // okay with version 1 due to Koenig lookup + // fails with version 2; make_pair not found + return 0; +}</pre> + +</blockquote> + + +<p><b>Proposed resolution:</b></p> + +<p>Replace D.5 [depr.c.headers] paragraph 2 with:</p> + +<blockquote> + +<p> Each C header, whose name has the form name.h, behaves as if each +name placed in the Standard library namespace by the corresponding +cname header is also placed within the namespace scope of the +namespace std by name.h and is followed by an explicit +using-declaration (_namespace.udecl_) in global scope.</p> + +</blockquote> + + + +<p><b>Rationale:</b></p> +<p> The current wording in the standard is the result of a difficult +compromise that averted delay of the standard. Based on discussions +in Tokyo it is clear that there is no still no consensus on stricter +wording, so the issue has been closed. It is suggested that users not +write code that depends on Koenig lookup of C library functions.</p> + + + + +<hr> +<h3><a name="145"></a>145. adjustfield lacks default value</h3> +<p><b>Section:</b> 27.4.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>There is no initial value for the adjustfield defined, although +many people believe that the default adjustment were right. This is a +common misunderstanding. The standard only defines that, if no +adjustment is specified, all the predefined inserters must add fill +characters before the actual value, which is "as if" the +right flag were set. The flag itself need not be set.</p> + +<p>When you implement a user-defined inserter you cannot rely on right +being the default setting for the adjustfield. Instead, you must be +prepared to find none of the flags set and must keep in mind that in +this case you should make your inserter behave "as if" the +right flag were set. This is surprising to many people and complicates +matters more than necessary.</p> + +<p>Unless there is a good reason why the adjustfield should not be +initialized I would suggest to give it the default value that +everybody expects anyway.</p> + + + +<p><b>Rationale:</b></p> +<p>This is not a defect. It is deliberate that the default is no bits +set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</p> + + + + +<hr> +<h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-06-28</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> +<p><b>Discussion:</b></p> +<p>Suppose that c and c1 are sequential containers and i is an +iterator that refers to an element of c. Then I can insert a copy of +c1's elements into c ahead of element i by executing </p> + +<blockquote> + +<pre>c.insert(i, c1.begin(), c1.end());</pre> + +</blockquote> + +<p>If c is a vector, it is fairly easy for me to find out where the +newly inserted elements are, even though i is now invalid: </p> + +<blockquote> + +<pre>size_t i_loc = i - c.begin(); +c.insert(i, c1.begin(), c1.end());</pre> + +</blockquote> + +<p>and now the first inserted element is at c.begin()+i_loc and one +past the last is at c.begin()+i_loc+c1.size().<br> +<br> +But what if c is a list? I can still find the location of one past the +last inserted element, because i is still valid. To find the location +of the first inserted element, though, I must execute something like </p> + +<blockquote> + +<pre>for (size_t n = c1.size(); n; --n) + --i;</pre> + +</blockquote> + +<p>because i is now no longer a random-access iterator.<br> +<br> +Alternatively, I might write something like </p> + +<blockquote> + +<pre>bool first = i == c.begin(); +list<T>::iterator j = i; +if (!first) --j; +c.insert(i, c1.begin(), c1.end()); +if (first) + j = c.begin(); +else + ++j;</pre> + +</blockquote> + +<p>which, although wretched, requires less overhead.<br> +<br> +But I think the right solution is to change the definition of insert +so that instead of returning void, it returns an iterator that refers +to the first element inserted, if any, and otherwise is a copy of its +first argument. </p> + + +<p><b>Rationale:</b></p> +<p>The LWG believes this was an intentional design decision and so is +not a defect. It may be worth revisiting for the next standard.</p> + + + + +<hr> +<h3><a name="157"></a>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt></h3> +<p><b>Section:</b> 27.4.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a></p> +<p><b>Discussion:</b></p> +<p>According to paragraphs 2 and 4 of 27.4.2.5 [ios.base.storage], the +functions <tt>iword()</tt> and <tt>pword()</tt> "set the +<tt>badbit</tt> (which might throw an exception)" on +failure. ... but what does it mean for <tt>ios_base</tt> to set the +<tt>badbit</tt>? The state facilities of the IOStream library are +defined in <tt>basic_ios</tt>, a derived class! It would be possible +to attempt a down cast but then it would be necessary to know the +character type used...</p> + + +<p><b>Rationale:</b></p> + + + + + +<hr> +<h3><a name="162"></a>162. Really "formatted input functions"?</h3> +<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p> +<p><b>Discussion:</b></p> +<p>It appears to be somewhat nonsensical to consider the functions +defined in the paragraphs 1 to 5 to be "Formatted input +function" but since these functions are defined in a section +labeled "Formatted input functions" it is unclear to me +whether these operators are considered formatted input functions which +have to conform to the "common requirements" from 27.6.1.2.1 +[istream.formatted.reqmts]: If this is the case, all manipulators, not +just +<tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set +(... but setting <tt>noskipws</tt> using the manipulator syntax would +also skip whitespace :-)</p> + +<p>See also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a> for the same problem in formatted +output</p> + + +<p><b>Rationale:</b></p> + + + + + +<hr> +<h3><a name="163"></a>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt></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#Dup">Dup</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</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#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p> +<p><b>Discussion:</b></p> +<p>It is not clear which functions are to be considered unformatted +input functions. As written, it seems that all functions in 27.6.1.3 +[istream.unformatted] are unformatted input functions. However, it does +not +really make much sense to construct a sentry object for +<tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what +happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>, +<tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called: +These functions don't extract characters, some of them even +"unextract" a character. Should this still be reflected in +<tt>gcount()</tt>? Of course, it could be read as if after a call to +<tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last +unformatted input function, <tt>gcount()</tt>, didn't extract any +character) and after a call to <tt>putback()</tt> <tt>gcount()</tt> +returns <tt>-1</tt> (the last unformatted input function +<tt>putback()</tt> did "extract" back into the +stream). Correspondingly for <tt>unget()</tt>. Is this what is +intended? If so, this should be clarified. Otherwise, a corresponding +clarification should be used.</p> + + +<p><b>Rationale:</b></p> + + + + + +<hr> +<h3><a name="166"></a>166. Really "formatted output functions"?</h3> +<p><b>Section:</b> 27.6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p> +<p><b>Discussion:</b></p> +<p>From 27.6.2.6.1 [ostream.formatted.reqmts] it appears that all the functions +defined in 27.6.2.6.3 [ostream.inserters] have to construct a +<tt>sentry</tt> object. Is this really intended?</p> + +<p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but +for output instead of input.</p> + + +<p><b>Rationale:</b></p> + + + + + +<hr> +<h3><a name="177"></a>177. Complex operators cannot be explicitly instantiated</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#NAD">NAD</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>A user who tries to explicitly instantiate a complex non-member operator will +get compilation errors. Below is a simplified example of the reason why. The +problem is that iterator_traits cannot be instantiated on a non-pointer type +like float, yet when the compiler is trying to decide which operator+ needs to +be instantiated it must instantiate the declaration to figure out the first +argument type of a reverse_iterator operator.</p> +<pre>namespace std { +template <class Iterator> +struct iterator_traits +{ + typedef typename Iterator::value_type value_type; +}; + +template <class T> class reverse_iterator; + +// reverse_iterator operator+ +template <class T> +reverse_iterator<T> operator+ +(typename iterator_traits<T>::difference_type, const reverse_iterator<T>&); + +template <class T> struct complex {}; + +// complex operator + +template <class T> +complex<T> operator+ (const T& lhs, const complex<T>& rhs) +{ return complex<T>();} +} + +// request for explicit instantiation +template std::complex<float> std::operator+<float>(const float&, + const std::complex<float>&);</pre> +<p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p> + + +<p><b>Rationale:</b></p> +<p>Implementors can make minor changes and the example will +work. Users are not affected in any case.</p> <p>According to John +Spicer, It is possible to explicitly instantiate these operators using +different syntax: change "std::operator+<float>" to +"std::operator+".</p> + +<p>The proposed resolution of issue 120 is that users will not be able +to explicitly instantiate standard library templates. If that +resolution is accepted then library implementors will be the only ones +that will be affected by this problem, and they must use the indicated +syntax.</p> + + + + +<hr> +<h3><a name="178"></a>178. Should clog and cerr initially be tied to cout?</h3> +<p><b>Section:</b> 27.3.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 27.3.1 says "After the object cerr is initialized, +cerr.flags() & unitbuf is nonzero. Its state is otherwise the same as +required for ios_base::init (lib.basic.ios.cons). It doesn't say +anything about the the state of clog. So this means that calling +cerr.tie() and clog.tie() should return 0 (see Table 89 for +ios_base::init effects). +</p> +<p> +Neither of the popular standard library implementations +that I tried does this, they both tie cerr and clog +to &cout. I would think that would be what users expect. +</p> + + +<p><b>Rationale:</b></p> +<p>The standard is clear as written.</p> +<p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags() +& unitbuf is nonzero. Its state is otherwise the same as required for +ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the +postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct +ios_base::init to basic_ios::init().)</p> + + + + +<hr> +<h3><a name="188"></a>188. valarray helpers missing augmented assignment operators</h3> +<p><b>Section:</b> 26.5.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-08-15</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>26.5.2.6 defines augmented assignment operators +valarray<T>::op=(const T&), but fails to provide +corresponding versions for the helper classes. Thus making the +following illegal:</p> +<blockquote> +<pre>#include <valarray> + +int main() +{ +std::valarray<double> v(3.14, 1999); + +v[99] *= 2.0; // Ok + +std::slice s(0, 50, 2); + +v[s] *= 2.0; // ERROR +}</pre> +</blockquote> +<p>I can't understand the intent of that omission. It makes the +valarray library less intuitive and less useful.</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 add the missing +operators.</p> + + + + +<hr> +<h3><a name="191"></a>191. Unclear complexity for algorithms such as binary search</h3> +<p><b>Section:</b> 25.3.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1999-10-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>The complexity of binary_search() is stated as "At most +log(last-first) + 2 comparisons", which seems to say that the +algorithm has logarithmic complexity. However, this algorithms is +defined for forward iterators. And for forward iterators, the need to +step element-by-element results into linear complexity. But such a +statement is missing in the standard. The same applies to +lower_bound(), upper_bound(), and equal_range(). <br> +<br> +However, strictly speaking the standard contains no bug here. So this +might considered to be a clarification or improvement. +</p> + + +<p><b>Rationale:</b></p> +<p>The complexity is expressed in terms of comparisons, and that +complexity can be met even if the number of iterators accessed is +linear. Paragraph 1 already says exactly what happens to +iterators.</p> + + + + +<hr> +<h3><a name="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p> +<p><b>Discussion:</b></p> +<p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from +several problems:</p> +<table border="1" cellpadding="5"> + <tbody><tr> + <td><b>expression</b></td> + <td><b>return type</b></td> + <td><b>pre/post-condition</b></td> + <td><b>complexity</b></td> + </tr> + <tr> + <td><tt>a.insert(p,t)</tt></td> + <td><tt>iterator</tt></td> + <td>inserts t if and only if there is no element with key equivalent to the key of + t in containers with unique keys; always inserts t in containers with equivalent + keys. always returns the iterator pointing to the element with key equivalent to + the key of t . iterator p is a hint pointing to where the insert should start to search.</td> + <td>logarithmic in general, but amortized constant if t is inserted right after p .</td> + </tr> +</tbody></table> +<p>1. For a container with unique keys, only logarithmic complexity is +guaranteed if no element is inserted, even though constant complexity is always +possible if p points to an element equivalent to t.</p> +<p>2. For a container with equivalent keys, the amortized constant complexity +guarantee is only useful if no key equivalent to t exists in the container. +Otherwise, the insertion could occur in one of multiple locations, at least one +of which would not be right after p.</p> +<p>3. By guaranteeing amortized constant complexity only when t is inserted +after p, it is impossible to guarantee constant complexity if t is inserted at +the beginning of the container. Such a problem would not exist if amortized +constant complexity was guaranteed if t is inserted before p, since there is +always some p immediately before which an insert can take place.</p> +<p>4. For a container with equivalent keys, p does not allow specification of +where to insert the element, but rather only acts as a hint for improving +performance. This negates the added functionality that p would provide if it +specified where within a sequence of equivalent keys the insertion should occur. +Specifying the insert location provides more control to the user, while +providing no disadvantage to the container implementation.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69 +for a.insert(p,t) with the following two rows:</p> +<table border="1" cellpadding="5"> + <tbody><tr> + <td><b>expression</b></td> + <td><b>return type</b></td> + <td><b>pre/post-condition</b></td> + <td><b>complexity</b></td> + </tr> + <tr> + <td><tt>a_uniq.insert(p,t)</tt></td> + <td><tt>iterator</tt></td> + <td>inserts t if and only if there is no element with key equivalent to the + key of t. returns the iterator pointing to the element with key equivalent + to the key of t.</td> + <td>logarithmic in general, but amortized constant if t is inserted right + before p or p points to an element with key equivalent to t.</td> + </tr> + <tr> + <td><tt>a_eq.insert(p,t)</tt></td> + <td><tt>iterator</tt></td> + <td>inserts t and returns the iterator pointing to the newly inserted + element. t is inserted right before p if doing so preserves the container + ordering.</td> + <td>logarithmic in general, but amortized constant if t is inserted right + before p.</td> + </tr> +</tbody></table> + + + +<p><b>Rationale:</b></p> +<p>Too big a change. Furthermore, implementors report checking +both before p and after p, and don't want to change this behavior.</p> + + + + + +<hr> +<h3><a name="194"></a>194. rdbuf() functions poorly specified</h3> +<p><b>Section:</b> 27.4.4 [ios] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 1999-09-07</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>In classic iostreams, base class ios had an rdbuf function that returned a +pointer to the associated streambuf. Each derived class had its own rdbuf +function that returned a pointer of a type reflecting the actual type derived +from streambuf. Because in ARM C++, virtual function overrides had to have the +same return type, rdbuf could not be virtual.</p> +<p>In standard iostreams, we retain the non-virtual rdbuf function design, and +in addition have an overloaded rdbuf function that sets the buffer pointer. +There is no need for the second function to be virtual nor to be implemented in +derived classes.</p> +<p>Minor question: Was there a specific reason not to make the original rdbuf +function virtual?</p> +<p>Major problem: Friendly compilers warn about functions in derived classes +that hide base-class overloads. Any standard implementation of iostreams will +result in such a warning on each of the iostream classes, because of the +ill-considered decision to overload rdbuf only in a base class.</p> +<p>In addition, users of the second rdbuf function must use explicit +qualification or a cast to call it from derived classes. An explicit +qualification or cast to basic_ios would prevent access to any later overriding +version if there was one.</p> +<p>What I'd like to do in an implementation is add a using- declaration for the +second rdbuf function in each derived class. It would eliminate warnings about +hiding functions, and would enable access without using explicit qualification. +Such a change I don't think would change the behavior of any valid program, but +would allow invalid programs to compile:</p> +<blockquote> + <pre> filebuf mybuf; + fstream f; + f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre> +</blockquote> +<p>I'd like to suggest this problem as a defect, with the proposed resolution to +require the equivalent of a using-declaration for the rdbuf function that is not +replaced in a later derived class. We could discuss whether replacing the +function should be allowed.</p> + + +<p><b>Rationale:</b></p> +<p>For historical reasons, the standard is correct as written. There is a subtle difference between the base +class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived +class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class +<tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p> + +<p>Permission is not required to add such an extension. See +17.4.4.4 [member.functions].</p> + + + + +<hr> +<h3><a name="196"></a>196. Placement new example has alignment problems</h3> +<p><b>Section:</b> 18.5.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Herb Sutter <b>Date:</b> 1998-12-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a></p> +<p><b>Discussion:</b></p> +<p>The example in 18.5.1.3 [new.delete.placement] paragraph 4 reads: </p> + +<blockquote> + +<p>[Example: This can be useful for constructing an object at a known address:<br> +<br> +<tt> char place[sizeof(Something)];<br> + Something* p = new (place) Something();<br> +<br> +</tt>end example] </p> + +</blockquote> + +<p>This example has potential alignment problems. </p> + + +<p><b>Rationale:</b></p> + + + + + +<hr> +<h3><a name="197"></a>197. max_size() underspecified</h3> +<p><b>Section:</b> 20.1.2 [allocator.requirements], 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-10-21</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Must the value returned by max_size() be unchanged from call to call? </p> + +<p>Must the value returned from max_size() be meaningful? </p> + +<p>Possible meanings identified in lib-6827: </p> + +<p>1) The largest container the implementation can support given "best +case" conditions - i.e. assume the run-time platform is "configured to +the max", and no overhead from the program itself. This may possibly +be determined at the point the library is written, but certainly no +later than compile time.<br> +<br> +2) The largest container the program could create, given "best case" +conditions - i.e. same platform assumptions as (1), but take into +account any overhead for executing the program itself. (or, roughly +"storage=storage-sizeof(program)"). This does NOT include any resource +allocated by the program. This may (or may not) be determinable at +compile time.<br> +<br> +3) The largest container the current execution of the program could +create, given knowledge of the actual run-time platform, but again, +not taking into account any currently allocated resource. This is +probably best determined at program start-up.<br> +<br> +4) The largest container the current execution program could create at +the point max_size() is called (or more correctly at the point +max_size() returns :-), given it's current environment (i.e. taking +into account the actual currently available resources). This, +obviously, has to be determined dynamically each time max_size() is +called. </p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>max_size() isn't useful for very many things, and the existing + wording is sufficiently clear for the few cases that max_size() can + be used for. None of the attempts to change the existing wording + were an improvement.</p> + +<p>It is clear to the LWG that the value returned by max_size() can't + change from call to call.</p> + + + + + + +<hr> +<h3><a name="203"></a>203. basic_istream::sentry::sentry() is uninstantiable with ctype<user-defined type></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#NAD">NAD</a> + <b>Submitter:</b> Matt McClure and Dietmar Kühl <b>Date:</b> 2000-01-01</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.6.1.1.2 Paragraph 4 states:</p> +<blockquote> + <p>To decide if the character c is a whitespace character, the constructor + performs ''as if'' it executes the following code fragment: </p> + <pre>const ctype<charT>& ctype = use_facet<ctype<charT> >(is.getloc()); +if (ctype.is(ctype.space,c)!=0) +// c is a whitespace character.</pre> +</blockquote> + +<p> But Table 51 in 22.1.1.1.1 only requires an implementation to +provide specializations for ctype<char> and +ctype<wchar_t>. If sentry's constructor is implemented using +ctype, it will be uninstantiable for a user-defined character type +charT, unless the implementation has provided non-working (since it +would be impossible to define a correct ctype<charT> specialization +for an arbitrary charT) definitions of ctype's virtual member +functions.</p> + +<p> +It seems the intent the standard is that sentry should behave, in +every respect, not just during execution, as if it were implemented +using ctype, with the burden of providing a ctype specialization +falling on the user. But as it is written, nothing requires the +translation of sentry's constructor to behave as if it used the above +code, and it would seem therefore, that sentry's constructor should be +instantiable for all character types. +</p> + +<p> +Note: If I have misinterpreted the intent of the standard with +respect to sentry's constructor's instantiability, then a note should +be added to the following effect: +</p> + +<blockquote><p> +An implementation is forbidden from using the above code if it renders +the constructor uninstantiable for an otherwise valid character +type. +</p></blockquote> + +<p>In any event, some clarification is needed.</p> + + + +<p><b>Rationale:</b></p> +<p>It is possible but not easy to instantiate on types other than char +or wchar_t; many things have to be done first. That is by intention +and is not a defect.</p> + + + + +<hr> +<h3><a name="204"></a>204. distance(first, last) when "last" is before "first"</h3> +<p><b>Section:</b> 24.3.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Rintala Matti <b>Date:</b> 2000-01-28</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Section 24.3.4 describes the function distance(first, last) (where first and +last are iterators) which calculates "the number of increments or +decrements needed to get from 'first' to 'last'".</p> +<p>The function should work for forward, bidirectional and random access +iterators, and there is a requirement 24.3.4.5 which states that "'last' +must be reachable from 'first'".</p> +<p>With random access iterators the function is easy to implement as "last +- first".</p> +<p>With forward iterators it's clear that 'first' must point to a place before +'last', because otherwise 'last' would not be reachable from 'first'.</p> +<p>But what about bidirectional iterators? There 'last' is reachable from +'first' with the -- operator even if 'last' points to an earlier position than +'first'. However, I cannot see how the distance() function could be implemented +if the implementation does not know which of the iterators points to an earlier +position (you cannot use ++ or -- on either iterator if you don't know which +direction is the "safe way to travel").</p> +<p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they +use ++ to provide linear time implementations". However, the ++ operator is +not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly +mentions that distance() returns the number of increments _or decrements_, +suggesting that it could return a negative number also for bidirectional +iterators when 'last' points to a position before 'first'.</p> +<p>Is a further requirement is needed to state that for forward and +bidirectional iterators "'last' must be reachable from 'first' using the ++ +operator". Maybe this requirement might also apply to random access +iterators so that distance() would work the same way for every iterator +category?</p> + + +<p><b>Rationale:</b></p> +<p>"Reachable" is defined in the standard in 24.1 [iterator.requirements] paragraph 6. +The definition is only in terms of operator++(). The LWG sees no defect in +the standard.</p> + + + + +<hr> +<h3><a name="205"></a>205. numeric_limits unclear on how to determine floating point types</h3> +<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-01-28</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>In several places in 18.2.1.2 [numeric.limits.members], a member is +described as "Meaningful for all floating point types." +However, no clear method of determining a floating point type is +provided.</p> + +<p>In 18.2.1.5 [numeric.special], paragraph 1 states ". . . (for +example, epsilon() is only meaningful if is_integer is +false). . ." which suggests that a type is a floating point type +if is_specialized is true and is_integer is false; however, this is +unclear.</p> + +<p>When clarifying this, please keep in mind this need of users: what +exactly is the definition of floating point? Would a fixed point or +rational representation be considered one? I guess my statement here +is that there could also be types that are neither integer or +(strictly) floating point.</p> + + +<p><b>Rationale:</b></p> +<p>It is up to the implementor of a user define type to decide if it is a +floating point type.</p> + + + + +<hr> +<h3><a name="207"></a>207. ctype<char> members return clause incomplete</h3> +<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Robert Klarer <b>Date:</b> 1999-11-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a></p> +<p><b>Discussion:</b></p> +<p> +The <tt>widen</tt> and <tt>narrow</tt> member functions are described +in 22.2.1.3.2, paragraphs 9-11. In each case we have two overloaded +signatures followed by a <b>Returns</b> clause. The <b>Returns</b> +clause only describes one of the overloads. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] +paragraph 10 from:</p> +<p> Returns: do_widen(low, high, to).</p> + +<p>to:</p> +<p> Returns: do_widen(c) or do_widen(low, high, to), +respectively.</p> + +<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] paragraph 11 +from:</p> +<p> Returns: do_narrow(low, high, to).</p> + +<p>to:</p> +<p> Returns: do_narrow(c) or do_narrow(low, high, to), +respectively.</p> + + +<p><b>Rationale:</b></p> +<p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, which addresses the same +paragraphs.</p> + + + + + + +<hr> +<h3><a name="213"></a>213. Math function overloads ambiguous</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Due to the additional overloaded versions of numeric functions for +float and long double according to Section 26.5, calls such as int x; +std::pow (x, 4) are ambiguous now in a standard conforming +implementation. Current implementations solve this problem very +different (overload for all types, don't overload for float and long +double, use preprocessor, follow the standard and get +ambiguities).</p> <p>This behavior should be standardized or at least +identified as implementation defined.</p> + + +<p><b>Rationale:</b></p> +<p>These math issues are an +understood and accepted consequence of the design. They have +been discussed several times in the past. Users must write casts +or write floating point expressions as arguments.</p> + + + + +<hr> +<h3><a name="215"></a>215. Can a map's key_type be const?</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>A user noticed that this doesn't compile with the Rogue Wave library because +the rb_tree class declares a key_allocator, and allocator<const int> is +not legal, I think:</p> +<blockquote> + <pre>map < const int, ... > // legal?</pre> +</blockquote> +<p>which made me wonder whether it is legal for a map's key_type to be const. In +email from Matt Austern he said:</p> +<blockquote> +<p>I'm not sure whether it's legal to declare a map with a const key type. I +hadn't thought about that question until a couple weeks ago. My intuitive +feeling is that it ought not to be allowed, and that the standard ought to say +so. It does turn out to work in SGI's library, though, and someone in the +compiler group even used it. Perhaps this deserves to be written up as an issue +too.</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>The "key is assignable" requirement from table 69 in +23.1.4 [associative.reqmts] already implies the key cannot be const.</p> + + + + +<hr> +<h3><a name="216"></a>216. setbase manipulator description flawed</h3> +<p><b>Section:</b> 27.6.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Hyman Rosen <b>Date:</b> 2000-02-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a></p> +<p><b>Discussion:</b></p> +<p>27.6.3 [std.manip] paragraph 5 says:</p> +<blockquote> +<pre>smanip setbase(int base);</pre> +<p> Returns: An object s of unspecified type such that if out is an +(instance of) basic_ostream then the expression out<<s behaves +as if f(s) were called, in is an (instance of) basic_istream then the +expression in>>s behaves as if f(s) were called. Where f can be +defined as:</p> +<pre>ios_base& f(ios_base& str, int base) +{ + // set basefield + str.setf(n == 8 ? ios_base::oct : + n == 10 ? ios_base::dec : + n == 16 ? ios_base::hex : + ios_base::fmtflags(0), ios_base::basefield); + return str; +}</pre> +</blockquote> +<p>There are two problems here. First, f takes two parameters, so the +description needs to say that out<<s and in>>s behave as if f(s,base) +had been called. Second, f is has a parameter named base, but is written as if +the parameter was named n.</p> +<p>Actually, there's a third problem. The paragraph has grammatical errors. +There needs to be an "and" after the first comma, and the "Where +f" sentence fragment needs to be merged into its preceding sentence. You +may also want to format the function a little better. The formatting above is +more-or-less what the Standard contains.</p> + + +<p><b>Rationale:</b></p> +<p>The resolution of this defect is subsumed by the proposed resolution for +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>.</p> + +<p><i>[Tokyo: The LWG agrees that this is a defect and notes that it +occurs additional places in the section, all requiring fixes.]</i></p> + + + + + + + + +<hr> +<h3><a name="218"></a>218. Algorithms do not use binary predicate objects for default comparisons</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#NAD">NAD</a> + <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Many of the algorithms take an argument, pred, of template parameter type +BinaryPredicate or an argument comp of template parameter type Compare. These +algorithms usually have an overloaded version that does not take the predicate +argument. In these cases pred is usually replaced by the use of operator== and +comp is replaced by the use of operator<.</p> +<p>This use of hard-coded operators is inconsistent with other parts of the +library, particularly the containers library, where equality is established +using equal_to<> and ordering is established using less<>. Worse, +the use of operator<, would cause the following innocent-looking code to have +undefined behavior:</p> +<blockquote> + <pre>vector<string*> vec; +sort(vec.begin(), vec.end());</pre> +</blockquote> +<p>The use of operator< is not defined for pointers to unrelated objects. If +std::sort used less<> to compare elements, then the above code would be +well-defined, since less<> is explicitly specialized to produce a total +ordering of pointers.</p> + + +<p><b>Rationale:</b></p> +<p>This use of operator== and operator< was a very deliberate, conscious, and +explicitly made design decision; these operators are often more efficient. The +predicate forms are available for users who don't want to rely on operator== and +operator<.</p> + + + + +<hr> +<h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3> +<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> + <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> +<p><b>Discussion:</b></p> +<p>The find function always searches for a value using operator== to compare the +value argument to each element in the input iterator range. This is inconsistent +with other find-related functions such as find_end and find_first_of, which +allow the caller to specify a binary predicate object to be used for determining +equality. The fact that this can be accomplished using a combination of find_if +and bind_1st or bind_2nd does not negate the desirability of a consistent, +simple, alternative interface to find.</p> + + +<p><b>Proposed resolution:</b></p> +<blockquote> +<p>In section 25.1.5 [alg.find], add a second prototype for find +(between the existing prototype and the prototype for find_if), as +follows:</p> +<pre> template<class InputIterator, class T, class BinaryPredicate> + InputIterator find(InputIterator first, InputIterator last, + const T& value, BinaryPredicate bin_pred);</pre> +<p>Change the description of the return from:</p> +<blockquote> + <p>Returns: The first iterator i in the range [first, last) for which the following corresponding + conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p> +</blockquote> +<p> to:</p> +<blockquote> + <p>Returns: The first iterator i in the range [first, last) for which the following + corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*) + != false. Return last if no such iterator is found.</p> +</blockquote> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>This is request for a pure extension, so it is not a defect in the +current standard. As the submitter pointed out, "this can +be accomplished using a combination of find_if and bind_1st or +bind_2nd".</p> + + + + +<hr> +<h3><a name="236"></a>236. ctype<char>::is() member modifies facet</h3> +<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a></p> +<p><b>Discussion:</b></p> +<p>The description of the <tt>is()</tt> member in paragraph 4 of 22.2.1.3.2 [facet.ctype.char.members] is broken: According to this description, the +second form of the <tt>is()</tt> method modifies the masks in the +<tt>ctype</tt> object. The correct semantics if, of course, to obtain +an array of masks. The corresponding method in the general case, +ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p> + + +<p><b>Proposed resolution:</b></p> + <p>Change paragraph 4 from</p> + <blockquote><p> + The second form, for all *p in the range [low, high), assigns + vec[p-low] to table()[(unsigned char)*p]. + </p></blockquote> + <p>to become</p> + <blockquote><p> + The second form, for all *p in the range [low, high), assigns + table()[(unsigned char)*p] to vec[p-low]. + </p></blockquote> + + +<p><b>Rationale:</b></p> + + + + + +<hr> +<h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3> +<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Is the following implementation of <tt>find</tt> acceptable?</p> + +<pre> template<class Iter, class X> + Iter find(Iter begin, Iter end, const X& x) + { + X x1 = x; // this is the crucial statement + while (begin != end && *begin != x1) + ++begin; + return begin; + } +</pre> + +<p>If the answer is yes, then it is implementation-dependent as to +whether the following fragment is well formed:</p> + +<pre> vector<string> v; + + find(v.begin(), v.end(), "foo"); +</pre> + +<p>At issue is whether there is a requirement that the third argument +of find be CopyConstructible. There may be no problem here, but +analysis is necessary.</p> + + +<p><b>Rationale:</b></p> +<p>There is no indication in the standard that find's third argument +is required to be Copy Constructible. The LWG believes that no such +requirement was intended. As noted above, there are times when a user +might reasonably pass an argument that is not Copy Constructible.</p> + + + + +<hr> +<h3><a name="245"></a>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</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#NAD">NAD</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>I do not think the standard specifies what operation(s) on istream +iterators trigger input operations. So, for example:</p> + +<pre> istream_iterator<int> i(cin); + + int n = *i++; +</pre> + +<p>I do not think it is specified how many integers have been read +from cin. The number must be at least 1, of course, but can it be 2? +More?</p> + + +<p><b>Rationale:</b></p> +<p>The standard is clear as written: the stream is read every time +operator++ is called, and it is also read either when the iterator is +constructed or when operator* is called for the first time. In the +example above, exactly two integers are read from cin.</p> + +<p>There may be a problem with the interaction between istream_iterator +and some STL algorithms, such as find. There are no guarantees about +how many times find may invoke operator++.</p> + + + + +<hr> +<h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Mark Rodgers <b>Date:</b> 2000-05-19</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p> +<p><b>Discussion:</b></p> +<p>Closed issue 192 raised several problems with the specification of +this function, but was rejected as Not A Defect because it was too big +a change with unacceptable impacts on existing implementations. +However, issues remain that could be addressed with a smaller change +and with little or no consequent impact.</p> + +<ol> + <li><p> The specification is inconsistent with the original + proposal and with several implementations.</p> + + <p>The initial implementation by Hewlett Packard only ever looked + immediately <i>before</i> p, and I do not believe there was any + intention to standardize anything other than this behavior. + Consequently, current implementations by several leading + implementors also look immediately before p, and will only insert + after p in logarithmic time. I am only aware of one implementation + that does actually look after p, and it looks before p as well. It + is therefore doubtful that existing code would be relying on the + behavior defined in the standard, and it would seem that fixing + this defect as proposed below would standardize existing + practice.</p></li> + + <li><p> + The specification is inconsistent with insertion for sequence + containers.</p> + + <p>This is difficult and confusing to teach to newcomers. All + insert operations that specify an iterator as an insertion location + should have a consistent meaning for the location represented by + that iterator.</p></li> + + <li><p> As specified, there is no way to hint that the insertion + should occur at the beginning of the container, and the way to hint + that it should occur at the end is long winded and unnatural.</p> + + <p>For a container containing n elements, there are n+1 possible + insertion locations and n+1 valid iterators. For there to be a + one-to-one mapping between iterators and insertion locations, the + iterator must represent an insertion location immediately before + the iterator.</p></li> + + <li><p> When appending sorted ranges using insert_iterators, + insertions are guaranteed to be sub-optimal.</p> + + <p>In such a situation, the optimum location for insertion is + always immediately after the element previously inserted. The + mechanics of the insert iterator guarantee that it will try and + insert after the element after that, which will never be correct. + However, if the container first tried to insert before the hint, + all insertions would be performed in amortized constant + time.</p></li> +</ol> + + +<p><b>Proposed resolution:</b></p> +<p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make +the following changes in the row for a.insert(p,t):</p> + +<p><i>assertion/note pre/post condition:</i> +<br>Change the last sentence from</p> + <blockquote><p> + "iterator p is a hint pointing to where the insert should + start to search." + </p></blockquote> +<p>to</p> + <blockquote><p> + "iterator p is a hint indicating that immediately before p + may be a correct location where the insertion could occur." + </p></blockquote> + +<p><i>complexity:</i><br> +Change the words "right after" to "immediately before".</p> + + +<p><b>Rationale:</b></p> + + + + + +<hr> +<h3><a name="249"></a>249. Return Type of <tt>auto_ptr::operator=</tt></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#NAD">NAD</a> + <b>Submitter:</b> Joseph Gottman <b>Date:</b> 2000-06-30</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>According to section 20.4.5, the function +<tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr. +The reason that <tt>operator=()</tt> usually returns a reference is to +facilitate code like</p> + +<pre> int x,y,z; + x = y = z = 1; +</pre> + +<p>However, given analogous code for <tt>auto_ptr</tt>s,</p> +<pre> auto_ptr<int> x, y, z; + z.reset(new int(1)); + x = y = z; +</pre> + +<p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to +NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value. +This makes such cascading assignments useless and counterintuitive for +<tt>auto_ptr</tt>s.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead +of an <tt>auto_ptr</tt> reference.</p> + + +<p><b>Rationale:</b></p> +<p>The return value has uses other than cascaded assignments: a user can +call an auto_ptr member function, pass the auto_ptr to a +function, etc. Removing the return value could break working user +code.</p> + + + + +<hr> +<h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3> +<p><b>Section:</b> 20.6.3 [base], 24.3.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Robert Dick <b>Date:</b> 2000-08-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +According to the November 1997 Draft Standard, the results of deleting an +object of a derived class through a pointer to an object of its base class are +undefined if the base class has a non-virtual destructor. Therefore, it is +potentially dangerous to publicly inherit from such base classes. +</p> + +<p>Defect: +<br> +The STL design encourages users to publicly inherit from a number of classes +which do nothing but specify interfaces, and which contain non-virtual +destructors. +</p> + +<p>Attribution: +<br> +Wil Evers and William E. Kempf suggested this modification for functional +objects. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +When a base class in the standard library is useful only as an interface +specifier, i.e., when an object of the class will never be directly +instantiated, specify that the class contains a protected destructor. This +will prevent deletion through a pointer to the base class without performance, +or space penalties (on any implementation I'm aware of). +</p> + +<p> +As an example, replace... +</p> + +<pre> template <class Arg, class Result> + struct unary_function { + typedef Arg argument_type; + typedef Result result_type; + }; +</pre> + +<p> +... with... +</p> + +<pre> template <class Arg, class Result> + struct unary_function { + typedef Arg argument_type; + typedef Result result_type; + protected: + ~unary_function() {} + }; +</pre> + +<p> +Affected definitions: +<br> + 20.3.1 [lib.function.objects] -- unary_function, binary_function + <br> + 24.3.2 [lib.iterator.basic] -- iterator +</p> + + +<p><b>Rationale:</b></p> +<p> +The standard is clear as written; this is a request for change, not a +defect in the strict sense. The LWG had several different objections +to the proposed change. One is that it would prevent users from +creating objects of type <tt>unary_function</tt> and +<tt>binary_function</tt>. Doing so can sometimes be legitimate, if users +want to pass temporaries as traits or tag types in generic code. +</p> + + + + + +<hr> +<h3><a name="267"></a>267. interaction of strstreambuf::overflow() and seekoff()</h3> +<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-10-05</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It appears that the interaction of the strstreambuf members overflow() +and seekoff() can lead to undefined behavior in cases where defined +behavior could reasonably be expected. The following program +demonstrates this behavior: +</p> + +<pre> #include <strstream> + + int main () + { + std::strstreambuf sb; + sb.sputc ('c'); + + sb.pubseekoff (-1, std::ios::end, std::ios::in); + return !('c' == sb.sgetc ()); + } +</pre> + +<p> +D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf<>(), +which in turn sets all pointers to 0 in 27.5.2.1, p1. +</p> + +<p> +27.5.2.2.5, p1 says that basic_streambuf<>::sputc(c) calls +overflow(traits::to_int_type(c)) if a write position isn't available (it +isn't due to the above). +</p> + +<p> +D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at +least one write position available (i.e., it allows the function to make +any positive number of write positions available). +</p> + +<p> +D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see +seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this +case. newoff is then epptr() - eback(). +</p> + +<p> +D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or +gptr() == epptr() + off holds. +</p> + +<p> +If strstreambuf::overflow() made exactly one write position available +then gptr() will be set to just before epptr(), and the program will +return 0. Buf if the function made more than one write position +available, epptr() and gptr() will both point past pptr() and the +behavior of the program is undefined. +</p> + + +<p><b>Proposed resolution:</b></p> + + + <p>Change the last sentence of D.7.1 [depr.strstreambuf] paragraph 4 from</p> + + <blockquote><p> + Otherwise, seeklow equals gbeg and seekhigh is either pend, if + pend is not a null pointer, or gend. + </p></blockquote> + + <p>to become</p> + + <blockquote><p> + Otherwise, seeklow equals gbeg and seekhigh is either gend if + 0 == pptr(), or pbase() + max where max is the maximum value of + pptr() - pbase() ever reached for this stream. + </p></blockquote> + +<p><i>[ + pre-Copenhagen: Dietmar provided wording for proposed resolution. +]</i></p> + + +<p><i>[ + post-Copenhagen: Fixed a typo: proposed resolution said to fix + 4.7.1, not D.7.1. +]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>This is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>: it's not clear what it +means to seek beyond the current area. Without resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a> we can't resolve this. As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>, +the library working group does not wish to invest time nailing down +corner cases in a deprecated feature.</p> + + + + + +<hr> +<h3><a name="269"></a>269. cstdarg and unnamed parameters</h3> +<p><b>Section:</b> 18.7 [support.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> J. Stephen Adamczyk <b>Date:</b> 2000-10-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +One of our customers asks whether this is valid C++: +</p> + +<pre> #include <cstdarg> + + void bar(const char *, va_list); + + void + foo(const char *file, const char *, ...) + { + va_list ap; + va_start(ap, file); + bar(file, ap); + va_end(ap); + } +</pre> + +<p> +The issue being whether it is valid to use cstdarg when the final +parameter before the "..." is unnamed. cstdarg is, as far +as I can tell, inherited verbatim from the C standard. and the +definition there (7.8.1.1 in the ISO C89 standard) refers to "the +identifier of the rightmost parameter". What happens when there +is no such identifier? +</p> + +<p> +My personal opinion is that this should be allowed, but some tweak +might be required in the C++ standard. +</p> + + +<p><b>Rationale:</b></p> +<p> +Not a defect, the C and C++ standards are clear. It is impossible to +use varargs if the parameter immediately before "..." has no +name, because that is the parameter that must be passed to va_start. +The example given above is broken, because va_start is being passed +the wrong parameter. +</p> + +<p> +There is no support for extending varargs to provide additional +functionality beyond what's currently there. For reasons of C/C++ +compatibility, it is especially important not to make gratuitous +changes in this part of the C++ standard. The C committee has already +been requested not to touch this part of the C standard unless +necessary. +</p> + + + + +<hr> +<h3><a name="277"></a>277. Normative encouragement in allocator requirements unclear</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#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-07</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 20.1.5, paragraph 5, the standard says that "Implementors are +encouraged to supply libraries that can accept allocators that +encapsulate more general memory models and that support non-equal +instances." This is intended as normative encouragement to +standard library implementors. However, it is possible to interpret +this sentence as applying to nonstandard third-party libraries. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.1.5, paragraph 5, change "Implementors" to +"Implementors of the library described in this International +Standard". +</p> + + +<p><b>Rationale:</b></p> +<p>The LWG believes the normative encouragement is already +sufficiently clear, and that there are no important consequences +even if it is misunderstood.</p> + + + + + +<hr> +<h3><a name="279"></a>279. const and non-const iterators should have equivalent typedefs</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#NAD">NAD</a> + <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +This came from an email from Steve Cleary to Fergus in reference to +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed +this in Toronto and believes it should be a separate issue. +</p> + +<p> +Steve said: "We may want to state that the const/non-const iterators must have +the same difference type, size_type, and category." +</p> + +<p> +(Comment from Judy) +I'm not sure if the above sentence should be true for all +const and non-const iterators in a particular container, or if it means +the container's iterator can't be compared with the container's +const_iterator unless the above it true. I suspect the former. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In <b>Section:</b> 23.1 [container.requirements], +table 65, in the assertion/note pre/post condition for X::const_iterator, +add the following: +</p> + +<blockquote> +<p> +typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type) +</p> + +<p> +typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type) +</p> + +<p> +typeid(X::const_iterator::category) == typeid(X::iterator::category) +</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>Going through the types one by one: Iterators don't have a +<tt>size_type</tt>. We already know that the difference types are +identical, because the container requirements already say that the +difference types of both X::iterator and X::const_iterator are both +X::difference_type. The standard does not require that X::iterator +and X::const_iterator have the same iterator category, but the LWG +does not see this as a defect: it's possible to imagine cases in which +it would be useful for the categories to be different.</p> + +<p>It may be desirable to require X::iterator and X::const_iterator to +have the same value type, but that is a new issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>.)</p> + + + + + + +<hr> +<h3><a name="287"></a>287. conflicting ios_base fmtflags</h3> +<p><b>Section:</b> 27.4.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The Effects clause for ios_base::setf(fmtflags fmtfl) says +"Sets fmtfl in flags()". What happens if the user first calls +ios_base::scientific and then calls ios_base::fixed or vice-versa? +This is an issue for all of the conflicting flags, i.e. ios_base::left +and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct. +</p> + +<p> +I see three possible solutions: +</p> + +<ol> +<li>Set ios_base::failbit whenever the user specifies a conflicting +flag with one previously explicitly set. If the constructor is +supposed to set ios_base::dec (see discussion below), then +the user setting hex or oct format after construction will not +set failbit. </li> +<li>The last call to setf "wins", i.e. it clears any conflicting +previous setting.</li> +<li>All the flags that the user specifies are set, but when actually +interpreting them, fixed always override scientific, right always +overrides left, dec overrides hex which overrides oct.</li> +</ol> + +<p> +Most existing implementations that I tried seem to conform to resolution #3, +except that when using the iomanip manipulator hex or oct then that always +overrides dec, but calling setf(ios_base::hex) doesn't. +</p> + +<p> +There is a sort of related issue, which is that although the ios_base +constructor says that each ios_base member has an indeterminate value +after construction, all the existing implementations I tried explicitly set +ios_base::dec. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p> +<tt>adjustfield</tt>, <tt>basefield</tt>, and <tt>floatfield</tt> +are each multi-bit fields. It is possible to set multiple bits within +each of those fields. (For example, <tt>dec</tt> and +<tt>oct</tt>). These fields are used by locale facets. The LWG +reviewed the way in which each of those three fields is used, and +believes that in each case the behavior is well defined for any +possible combination of bits. See for example Table 58, in 22.2.2.2.2 +[facet.num.put.virtuals], noting the requirement in paragraph 6 of that +section. +</p> +<p> +Users are advised to use manipulators, or else use the two-argument +version of <tt>setf</tt>, to avoid unexpected behavior. +</p> + + + + + +<hr> +<h3><a name="289"></a>289. <cmath> requirements missing C float and long double versions</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> + In ISO/IEC 9899:1990 Programming Languages C we find the following + concerning <math.h>: +</p> + +<blockquote><p> + 7.13.4 Mathematics <math.h> + <br> + The names of all existing functions declared in the <math.h> + header, suffixed with f or l, are reserved respectively for + corresponding functions with float and long double arguments + are return values. +</p></blockquote> + +<p> + For example, <tt>float sinf(float)</tt> + is reserved. +</p> + +<p> + In the C99 standard, <math.h> must contain declarations + for these functions. +</p> + +<p> +So, is it acceptable for an implementor to add these prototypes to the +C++ versions of the math headers? Are they required? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add these Functions to Table 80, section 26.5 and to Table 99, +section C.2: +</p> + +<pre> acosf asinf atanf atan2f ceilf cosf coshf + expf fabsf floorf fmodf frexpf ldexpf + logf log10f modff powf sinf sinhf sqrtf + tanf tanhf + acosl asinl atanl atan2l ceill cosl coshl + expl fabsl floorl fmodl frexpl ldexpl + logl log10l modfl powl sinl sinhl sqrtl + tanl tanhl +</pre> + +<p> +There should probably be a note saying that these functions +are optional and, if supplied, should match the description in +the 1999 version of the C standard. In the next round +of C++ standardization they can then become mandatory. +</p> + + +<p><b>Rationale:</b></p> +<p>The C90 standard, as amended, already permits (but does not +require) these functions, and the C++ standard incorporates the +C90 standard by reference. C99 is not an issue, because it is +never referred to by the C++ standard.</p> + + + + + +<hr> +<h3><a name="293"></a>293. Order of execution in transform algorithm</h3> +<p><b>Section:</b> 25.2.4 [alg.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-04</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>This issue is related to issue 242. In case that the resolution +proposed for issue 242 is accepted, we have have the following +situation: The 4 numeric algorithms (accumulate and consorts) as well +as transform would allow a certain category of side effects. The +numeric algorithms specify that they invoke the functor "for +every iterator i in the range [first, last) in order". transform, +in contrast, would not give any guarantee regarding order of +invocation of the functor, which means that the functor can be invoked +in any arbitrary order. +</p> + +<p>Why would that be a problem? Consider an example: say the +transformator that is a simple enumerator ( or more generally +speaking, "is order-sensitive" ). Since a standard +compliant implementation of transform is free to invoke the enumerator +in no definite order, the result could be a garbled enumeration. +Strictly speaking this is not a problem, but it is certainly at odds +with the prevalent understanding of transform as an algorithms that +assigns "a new _corresponding_ value" to the output +elements. +</p> + +<p>All implementations that I know of invoke the transformator in +definite order, namely starting from first and proceeding to last - +1. Unless there is an optimization conceivable that takes advantage of +the indefinite order I would suggest to specify the order, because it +eliminate the uncertainty that users would otherwise have regarding +the order of execution of their potentially order-sensitive function +objects. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In section 25.2.3 - Transform [lib.alg.transform] change:</p> +<blockquote><p> +-1- Effects: Assigns through every iterator i in the range [result, +result + (last1 - first1)) a new corresponding +value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + +(i - result), *(first2 + (i - result))). +</p></blockquote> +<p>to:</p> +<blockquote><p> +-1- Effects: Computes values by invoking the operation op or binary_op +for every iterator in the range [first1, last1) in order. Assigns through +every iterator i in the range [result, result + (last1 - first1)) a new +corresponding +value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + +(i - result), *(first2 + (i - result))). +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p>For Input Iterators an order is already guaranteed, because +only one order is possible. If a user who passes a Forward +Iterator to one of these algorithms really needs a specific +order of execution, it's possible to achieve that effect by +wrapping it in an Input Iterator adaptor.</p> + + + + + +<hr> +<h3><a name="296"></a>296. Missing descriptions and requirements of pair operators</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#NAD">NAD</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>The synopsis of the header <tt><utility></tt> in 20.2 [utility] +lists the complete set of equality and relational operators for <tt>pair</tt> +but the section describing the template and the operators only describes +<tt>operator==()</tt> and <tt>operator<()</tt>, and it fails to mention +any requirements on the template arguments. The remaining operators are +not mentioned at all. +</p> + + +<p><b>Rationale:</b></p> +<p>20.2.1 [operators] paragraph 10 already specifies the semantics. +That paragraph says that, if declarations of operator!=, operator>, +operator<=, and operator>= appear without definitions, they are +defined as specified in 20.2.1 [operators]. There should be no user +confusion, since that paragraph happens to immediately precede the +specification of <tt>pair</tt>.</p> + + + + + +<hr> +<h3><a name="302"></a>302. Need error indication from codecvt<>::do_length</h3> +<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Gregory Bumgardner <b>Date:</b> 2001-01-25</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The effects of <tt>codecvt<>::do_length()</tt> are described in +22.2.1.5.2, paragraph 10. As implied by that paragraph, and clarified +in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <tt>codecvt<>::do_length()</tt> must +process the source data and update the <tt>stateT</tt> argument just +as if the data had been processed by <tt>codecvt<>::in()</tt>. +However, the standard does not specify how <tt>do_length()</tt> would +report a translation failure, should the source sequence contain +untranslatable or illegal character sequences. +</p> + +<p> +The other conversion methods return an "error" result value +to indicate that an untranslatable character has been encountered, but +<tt>do_length()</tt> already has a return value (the number of source +characters that have been processed by the method). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +This issue cannot be resolved without modifying the interface. An exception +cannot be used, as there would be no way to determine how many characters +have been processed and the state object would be left in an indeterminate +state. +</p> + +<p> +A source compatible solution involves adding a fifth argument to length() +and do_length() that could be used to return position of the offending +character sequence. This argument would have a default value that would +allow it to be ignored: +</p> + +<pre> int length(stateT& state, + const externT* from, + const externT* from_end, + size_t max, + const externT** from_next = 0); + + virtual + int do_length(stateT& state, + const externT* from, + const externT* from_end, + size_t max, + const externT** from_next); +</pre> + +<p> +Then an exception could be used to report any translation errors and +the from_next argument, if used, could then be used to retrieve the +location of the offending character sequence. +</p> + + +<p><b>Rationale:</b></p> +<p>The standard is already clear: the return value is the number of +"valid complete characters". If it encounters an invalid sequence of +external characters, it stops.</p> + + + + + +<hr> +<h3><a name="304"></a>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</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#NAD">NAD</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-02-05</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +We all "know" that input iterators are allowed to produce +values when dereferenced of which there is no other in-memory copy. +</p> + +<p> +But: Table 72, with a careful reading, seems to imply that this can only be +the case if the value_type has no members (e.g. is a built-in type). +</p> + +<p>The problem occurs in the following entry:</p> + +<pre> a->m pre: (*a).m is well-defined + Equivalent to (*a).m +</pre> + +<p> +<tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference +type, but since <tt>operator->()</tt> must return a pointer for +<tt>a->m</tt> to be well-formed, it needs something to return a +pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be +buffered somewhere to make a legal input iterator. +</p> + +<p>I don't think this was intentional.</p> + + +<p><b>Rationale:</b></p> +<p>The current standard is clear and consistent. Input iterators that + return rvalues are in fact implementable. They may in some cases + require extra work, but it is still possible to define an operator-> + in such cases: it doesn't have to return a T*, but may return a + proxy type. No change to the standard is justified.</p> + + + + + +<hr> +<h3><a name="313"></a>313. set_terminate and set_unexpected question</h3> +<p><b>Section:</b> 18.7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 2001-04-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +According to section 18.7.3.3 of the standard, std::terminate() is +supposed to call the terminate_handler in effect immediately after +evaluating the throw expression. +</p> + +<p> +Question: what if the terminate_handler in effect is itself +std::terminate? +</p> + +<p>For example:</p> + +<pre> #include <exception> + + int main () { + std::set_terminate(std::terminate); + throw 5; + return 0; + } +</pre> + +<p> +Is the implementation allowed to go into an infinite loop? +</p> + +<p> +I think the same issue applies to std::set_unexpected. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>Infinite recursion is to be expected: users who set the terminate +handler to <tt>terminate</tt> are explicitly asking for <tt>terminate</tt> +to call itself.</p> + + + + + +<hr> +<h3><a name="314"></a>314. Is the stack unwound when terminate() is called?</h3> +<p><b>Section:</b> 18.7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-04-11</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +The standard appears to contradict itself about whether the stack is +unwound when the implementation calls terminate(). +</p> + +<p>From 18.7.3.3p2:</p> +<blockquote><p> + Calls the terminate_handler function in effect immediately + after evaluating the throw-expression (lib.terminate.handler), + if called by the implementation [...] +</p></blockquote> + +<p>So the stack is guaranteed not to be unwound.</p> + +<p>But from 15.3p9:</p> +<blockquote><p> + [...]whether or not the stack is unwound before this call + to terminate() is implementation-defined (except.terminate). +</p></blockquote> + +<p> +And 15.5.1 actually defines that in most cases the stack is unwound. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>There is definitely no contradiction between the core and library +clauses; nothing in the core clauses says that stack unwinding happens +after <tt>terminate</tt> is called. 18.7.3.3p2 does not say anything +about when terminate() is called; it merely specifies which +<tt>terminate_handler</tt> is used.</p> + + + + + +<hr> +<h3><a name="323"></a>323. abs() overloads in different headers</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-04</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>Currently the standard mandates the following overloads of +abs():</p> + +<pre> abs(long), abs(int) in <cstdlib> + + abs(float), abs(double), abs(long double) in <cmath> + + template<class T> T abs(const complex<T>&) in <complex> + + template<class T> valarray<T> abs(const valarray<T>&); in <valarray> +</pre> + +<p> +The problem is that having only some overloads visible of a function +that works on "implicitly inter-convertible" types is dangerous in +practice. The headers that get included at any point in a translation +unit can change unpredictably during program +development/maintenance. The wrong overload might be unintentionally +selected. +</p> + +<p> +Currently, there is nothing that mandates the simultaneous visibility +of these overloads. Indeed, some vendors have begun fastidiously +reducing dependencies among their (public) headers as a QOI issue: it +helps people to write portable code by refusing to compile unless all +the correct headers are #included. +</p> + +<p>The same issue may exist for other functions in the library.</p> + +<p>Redmond: PJP reports that C99 adds two new kinds of abs: complex, +and int_max_abs.</p> + +<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#343">343</a>.</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +The situation is not sufficiently severe to warrant a change. +</blockquote> + + + + +<p><b>Rationale:</b></p> +<p>The programs that could potentially be broken by this situation are + already fragile, and somewhat contrived: For example, a user-defined + class that has conversion overloads both to <tt>long</tt> and + to <tt>float</tt>. If <tt>x</tt> is a value of such a class, then + <tt>abs(x)</tt> would give the <tt>long</tt> version if the user + included <cstdlib>, the <tt>float</tt> version if the user + included <cmath>, and would be diagnosed as ambiguous at + compile time if the user included both headers. The LWG couldn't + find an example of a program whose meaning would be changed (as + opposed to changing it from well-formed to ill-formed) simply by + adding another standard header.</p> + +<p>Since the harm seems minimal, and there don't seem to be any simple + and noninvasive solutions, this is being closed as NAD. It is + marked as "Future" for two reasons. First, it might be useful to + define an <tt><all></tt> header that would include all + Standard Library headers. Second, we should at least make sure that + future library extensions don't make this problem worse.</p> + + + + + +<hr> +<h3><a name="326"></a>326. Missing typedef in moneypunct_byname</h3> +<p><b>Section:</b> 22.2.6.4 [locale.moneypunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-05</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>The definition of the moneypunct facet contains the typedefs char_type +and string_type. Only one of these names, string_type, is defined in +the derived facet, moneypunct_byname.</p> + + +<p><b>Proposed resolution:</b></p> +<p>For consistency with the numpunct facet, add a typedef for +char_type to the definition of the moneypunct_byname facet in +22.2.6.4 [locale.moneypunct.byname].</p> + + +<p><b>Rationale:</b></p> +<p>The absence of the typedef is irrelevant. Users can still access +the typedef, because it is inherited from the base class.</p> + + + + + +<hr> +<h3><a name="330"></a>330. Misleading "exposition only" value in class locale definition</h3> +<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The "exposition only" value of the std::locale::none constant shown in +the definition of class locale is misleading in that it on many +systems conflicts with the value assigned to one if the LC_XXX +constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE +on Linux and SunOS). This causes incorrect behavior when such a +constant is passed to one of the locale member functions that accept a +locale::category argument and interpret it as either the C LC_XXX +constant or a bitmap of locale::category values. At least three major +implementations adopt the suggested value without a change and +consequently suffer from this problem. +</p> + +<p> +For instance, the following code will (presumably) incorrectly copy facets +belonging to the collate category from the German locale on AIX: +</p> + +<pre> std::locale l (std::locale ("C"), "de_DE", std::locale::none); +</pre> + + +<p><b>Rationale:</b></p> +<p>The LWG agrees that it may be difficult to implement locale member +functions in such a way that they can take either <tt>category</tt> +arguments or the LC_ constants defined in <cctype>. In light of +this requirement (22.1.1.1.1 [locale.category], paragraph 2), and in light +of the requirement in the preceding paragraph that it is possible to +combine <tt>category</tt> bitmask elements with bitwise operations, +defining the <tt>category</tt> elements is delicate, +particularly if an implementor is constrained to work with a +preexisting C library. (Just using the existing LC_ constants would +not work in general.) There's no set of "exposition only" values that +could give library implementors proper guidance in such a delicate +matter. The non-normative example we're giving is no worse than +any other choice would be.</p> + +<p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p> + + + + + +<hr> +<h3><a name="332"></a>332. Consider adding increment and decrement operators to std::fpos< T > </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#NAD">NAD</a> + <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Increment and decrement operators are missing from +Table 88 -- Position type requirements in 27.4.3 [fpos]. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Table 88 (section 27.4.3) -- Position type requirements +be updated to include increment and decrement operators. +</p> + +<pre>expression return type operational note + +++p fpos& p += O(1) +p++ fpos { P tmp = p; + ++p; + return tmp; } +--p fpos& p -= O(1) +p-- fpos { P tmp = p; + --p; + return tmp; } +</pre> + + + +<p><b>Rationale:</b></p> +<p>The LWG believes this is a request for extension, not a defect +report. Additionally, nobody saw a clear need for this extension; +<tt>fpos</tt> is used only in very limited ways.</p> + + + + + +<hr> +<h3><a name="344"></a>344. grouping + showbase</h3> +<p><b>Section:</b> 22.2.2 [category.numeric] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-13</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +When both grouping and showbase are active and the basefield is octal, +does the leading 0 participate in the grouping or not? For example, +should one format as: 0,123,456 or 0123,456? +</p> +<p> +An analogy can be drawn with hexadecimal. It appears that 0x123,456 is +preferred over 0x,123,456. However, this analogy is not universally +accepted to apply to the octal base. The standard is not clear on how +to format (or parse) in this manner. +</p> + +<p><b>Proposed resolution:</b></p> +<p> +Insert into 22.2.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last +sentence: +</p> +<blockquote><p> +The leading hexadecimal base specifier "0x" does not participate in +grouping. The leading '0' octal base specifier may participate in +grouping. It is unspecified if the leading '0' participates in +formatting octal numbers. In parsing octal numbers, the implementation +is encouraged to accept both the leading '0' participating in the +grouping, and not participating (e.g. 0123,456 or 0,123,456). +</p></blockquote> + +<p><b>Rationale:</b></p> +<p> +The current behavior may be unspecified, but it's not clear that it +matters. This is an obscure corner case, since grouping is usually +intended for the benefit of humans and oct/hex prefixes are usually +intended for the benefit of machines. There is not a strong enough +consensus in the LWG for action. +</p> + + + + +<hr> +<h3><a name="348"></a>348. Minor issue with std::pair operator<</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#Dup">Dup</a> + <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-23</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#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a></p> +<p><b>Discussion:</b></p> + + +<p> +The current wording of 20.2.2 [lib.pairs] p6 precludes the use of +operator< on any pair type which contains a pointer. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 20.2.3 [pairs] paragraph 6, replace:</p> +<pre> Returns: x.first < y.first || (!(y.first < x.first) && x.second < + y.second). +</pre> +<p>With:</p> +<pre> Returns: std::less<T1>()( x.first, y.first ) || + (!std::less<T1>()( y.first, x.first) && + std::less<T2>()( x.second, y.second ) ) +</pre> + + + +<p><b>Rationale:</b></p> +<p>This is an instance of a much more general problem. If we want + operator< to translate to std::less for pairs of pointers, where + do we draw the line? The same issue applies to individual + pointers, smart pointer wrappers, std::vector<T*>, and so + on.</p> + +<p>Andy Koenig suggests that the real issue here is that we aren't + distinguishing adequately between two different orderings, a + "useful ordering" and a "canonical ordering" that's used just + because we sometimes need <i>some</i> ordering without caring much + which ordering it is. Another example of the later is typeinfo's + <tt>before</tt>.</p> + + + + + + +<hr> +<h3><a name="350"></a>350. allocator<>::address</h3> +<p><b>Section:</b> 20.7.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 2001-10-25</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a></p> +<p><b>Discussion:</b></p> +<p>See c++std-lib-9006 and c++std-lib-9007. This issue is taken +verbatim from -9007.</p> + +<p> +The core language feature allowing definition of operator&() applied +to any non-builtin type makes that operator often unsafe to use in +implementing libraries, including the Standard Library. The result +is that many library facilities fail for legal user code, such as +the fragment</p> +<pre> class A { private: A* operator&(); }; + std::vector<A> aa; + + class B { }; + B* operator&(B&) { return 0; } + std::vector<B> ba; +</pre> + +<p> +In particular, the requirements table for Allocator (Table 32) specifies +no semantics at all for member address(), and allocator<>::address is +defined in terms of unadorned operator &. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.6.1.1, Change the definition of allocator<>::address from:</p> +<blockquote><p> + Returns: &x +</p></blockquote> + +<p>to:</p> + +<p> + Returns: The value that the built in operator&(x) would return if not + overloaded. +</p> + +<p> +In 20.1.6, Table 32, add to the Notes column of the a.address(r) and +a.address(s) lines, respectively: +</p> + +<pre> allocator<T>::address(r) + allocator<T>::address(s) +</pre> + +<p>In addition, in clause 17.4.1.1, add a statement:</p> + +<blockquote><p> + The Standard Library does not apply operator& to any type for which + operator& may be overloaded. +</p></blockquote> + + + +<p><b>Rationale:</b></p> +<p>The LWG believes both examples are ill-formed. The contained type +is required to be CopyConstructible (20.1.1 [utility.arg.requirements]), and that +includes the requirement that &t return the usual types and +values. Since allocators are intended to be used in conjunction with +containers, and since the CopyConstructible requirements appear to +have been written to deal with the concerns of this issue, the LWG +feels it is NAD unless someone can come up with a well-formed example +exhibiting a problem.</p> + +<p>It may well be that the CopyConstructible requirements are too + restrictive and that either the container requirements or the + CopyConstructive requirements should be relaxed, but that's a far + larger issue. Marking this issue as "future" as a pointer to that + larger issue.</p> + + + + + +<hr> +<h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3> +<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Dale Riley <b>Date:</b> 2001-11-12</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 20.6 [function.objects] the header <functional> synopsis declares +the unary_negate and binary_negate function objects as struct. +However in 20.6.10 [negators] the unary_negate and binary_negate +function objects are defined as class. Given the context, they are +not "basic function objects" like negate, so this is either a typo or +an editorial oversight. +</p> + +<p><i>[Taken from comp.std.c++]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p>Change the synopsis to reflect the useage in 20.6.10 [negators]</p> + +<p><i>[Curaçao: Since the language permits "struct", the LWG +views this as NAD. They suggest, however, that the Project Editor +might wish to make the change as editorial.]</i></p> + + + + + + + +<hr> +<h3><a name="353"></a>353. <tt>std::pair</tt> missing template assignment</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#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but +no template assignment operator. This may lead to inefficient code since +assigning an object of <tt>pair<C, D></tt> to <tt>pair<A, B></tt> +where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to +<tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy +ctor to construct an unnamed temporary of type <tt>pair<A, B></tt> +followed by an ordinary (perhaps implicitly defined) assignment operator, +instead of just a straight assignment. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following declaration to the definition of <tt>std::pair</tt>: +</p> +<pre> template<class U, class V> + pair& operator=(const pair<U, V> &p); +</pre> +<p> +And also add a paragraph describing the effects of the function template to the +end of 20.2.2: +</p> +<pre> template<class U, class V> + pair& operator=(const pair<U, V> &p); +</pre> +<p> + <b>Effects</b>: <tt>first = p.first;</tt> + <tt>second = p.second;</tt> + <b>Returns</b>: <tt>*this</tt> +</p> + +<p><i>[Curaçao: There is no indication this is was anything other than +a design decision, and thus NAD. May be appropriate for a future +standard.]</i></p> + + +<p><i>[ +Pre Bellevue: It was recognized that this was taken care of by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>, +and thus moved from NAD Future to NAD Editorial. +]</i></p> + + + + + + +<hr> +<h3><a name="356"></a>356. Meaning of ctype_base::mask enumerators</h3> +<p><b>Section:</b> 22.2.1 [category.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-01-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> + +<p>What should the following program print?</p> + +<pre> #include <locale> + #include <iostream> + + class my_ctype : public std::ctype<char> + { + typedef std::ctype<char> base; + public: + my_ctype(std::size_t refs = 0) : base(my_table, false, refs) + { + std::copy(base::classic_table(), base::classic_table() + base::table_size, + my_table); + my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space); + } + private: + mask my_table[base::table_size]; + }; + + int main() + { + my_ctype ct; + std::cout << "isspace: " << ct.is(std::ctype_base::space, '_') << " " + << "isalpha: " << ct.is(std::ctype_base::alpha, '_') << std::endl; + } +</pre> + +<p>The goal is to create a facet where '_' is treated as whitespace.</p> + +<p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0". On +Microsoft C++ it prints "isspace: 1 isalpha: 1".</p> + +<p> +I believe that both implementations are legal, and the standard does not +give enough guidance for users to be able to use std::ctype's +protected interface portably.</p> + +<p> +The above program assumes that ctype_base::mask enumerators like +<tt>space</tt> and <tt>print</tt> are disjoint, and that the way to +say that a character is both a space and a printing character is to or +those two enumerators together. This is suggested by the "exposition +only" values in 22.2.1 [category.ctype], but it is nowhere specified in +normative text. An alternative interpretation is that the more +specific categories subsume the less specific. The above program +gives the results it does on the Microsoft compiler because, on that +compiler, <tt>print</tt> has all the bits set for each specific +printing character class. +</p> + +<p>From the point of view of std::ctype's public interface, there's no +important difference between these two techniques. From the point of +view of the protected interface, there is. If I'm defining a facet +that inherits from std::ctype<char>, I'm the one who defines the +value that table()['a'] returns. I need to know what combination of +mask values I should use. This isn't so very esoteric: it's exactly +why std::ctype has a protected interface. If we care about users +being able to write their own ctype facets, we have to give them a +portable way to do it. +</p> + +<p> +Related reflector messages: +lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274, +lib-9277, lib-9279. +</p> + +<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical. The +proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that +ctype_base::mask must be a bitmask type. It does not say that the +ctype_base::mask elements are bitmask elements, so it doesn't +directly affect this issue.</p> + +<p>More comments from Benjamin Kosnik, who believes that +that C99 compatibility essentially requires what we're +calling option 1 below.</p> + +<blockquote> +<pre>I think the C99 standard is clear, that isspace -> !isalpha. +-------- + +#include <locale> +#include <iostream> + +class my_ctype : public std::ctype<char> +{ +private: + typedef std::ctype<char> base; + mask my_table[base::table_size]; + +public: + my_ctype(std::size_t refs = 0) : base(my_table, false, refs) + { + std::copy(base::classic_table(), base::classic_table() + base::table_size, + my_table); + mask both = base::print | base::space; + my_table[static_cast<mask>('_')] = both; + } +}; + +int main() +{ + using namespace std; + my_ctype ct; + cout << "isspace: " << ct.is(ctype_base::space, '_') << endl; + cout << "isprint: " << ct.is(ctype_base::print, '_') << endl; + + // ISO C99, isalpha iff upper | lower set, and !space. + // 7.5, p 193 + // -> looks like g++ behavior is correct. + // 356 -> bitmask elements are required for ctype_base + // 339 -> bitmask type required for mask + cout << "isalpha: " << ct.is(ctype_base::alpha, '_') << endl; +} +</pre> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p>Informally, we have three choices:</p> +<ol> +<li>Require that the enumerators are disjoint (except for alnum and +graph)</li> +<li>Require that the enumerators are not disjoint, and specify which +of them subsume which others. (e.g. mandate that lower includes alpha +and print)</li> +<li>Explicitly leave this unspecified, which the result that the above +program is not portable.</li> +</ol> + +<p>Either of the first two options is just as good from the standpoint +of portability. Either one will require some implementations to +change.</p> + + +<p><b>Rationale:</b></p> +<p>The LWG agrees that this is a real ambiguity, and that both +interpretations are conforming under the existing standard. However, +there's no evidence that it's causing problems for real users. Users +who want to define ctype facets portably can test the ctype_base masks +to see which interpretation is being used.</p> + + + + + +<hr> +<h3><a name="357"></a>357. <cmath> float functions cannot return HUGE_VAL</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-02-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The float versions of the math functions have no meaningful value to return +for a range error. The long double versions have a value they can return, +but it isn't necessarily the most reasonable value. +</p> + +<p> +Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long +double overloaded versions of these functions, with the same semantics," +referring to the math functions from the C90 standard. +</p> + +<p> +The C90 standard, in section 7.5.1, paragraph 3, says that functions return +"the value of the macro HUGE_VAL" when they encounter a range error. +Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a +positive double expression, not necessarily representable as a float." +</p> + +<p> +Therefore, the float versions of the math functions have no way to +signal a range error. <i>[Curaçao: The LWG notes that this isn't +strictly correct, since errno is set.]</i> The semantics require that they +return HUGE_VAL, but they cannot because HUGE_VAL might not be +representable as a float. +</p> + +<p> +The problem with long double functions is less severe because HUGE_VAL is +representable as a long double. On the other hand, it might not be a "huge" +long double value, and might fall well within the range of normal return +values for a long double function. Therefore, it does not make sense for a +long double function to return a double (HUGE_VAL) for a range error. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Curaçao: C99 was faced with a similar problem, which they fixed by +adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p> + +<p>C++ must also fix, but it should be done in the context of the +general C99 based changes to C++, not via DR. Thus the LWG in Curaçao +felt the resolution should be NAD, FUTURE, but the issue is being held +open for one more meeting to ensure LWG members not present during the +discussion concur.</p> + + +<p><b>Rationale:</b></p> +<p>Will be fixed as part of more general work in the TR.</p> + + + + + +<hr> +<h3><a name="361"></a>361. num_get<>::do_get (..., void*&) checks grouping</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#NAD">NAD</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only +for integral types (issue 282 suggests that this should be done for +all arithmetic types). +</p> + +<p> +22.2.2.1.2, p12 requires that grouping be checked for all extractors +including that for <tt>void*</tt>. +</p> + +<p> +I don't think that's right. <tt>void*</tt> values should not be checked for +grouping, should they? (Although if they should, then <tt>num_put</tt> needs +to write them out, otherwise their extraction will fail.) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the first sentence of 22.2.2.2.2, p12 from +</p> +<blockquote><p> + Digit grouping is checked. That is, the positions of discarded + separators is examined for consistency with + use_facet<numpunct<charT> >(loc).grouping(). + If they are not consistent then ios_base::failbit is assigned + to err. +</p></blockquote> + +<p>to</p> +<blockquote><p> + Except for conversions to void*, digit grouping is checked... +</p></blockquote> + + + +<p><b>Rationale:</b></p> +<p>This would be a change: as it stands, the standard clearly + specifies that grouping applies to void*. A survey of existing + practice shows that most existing implementations do that, as they + should.</p> + + + + + +<hr> +<h3><a name="366"></a>366. Excessive const-qualification</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#NAD">NAD</a> + <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The following member functions are declared const, yet return non-const +pointers. We believe they are should be changed, because they allow code +that may surprise the user. See document N1360 for details and +rationale. +</p> + +<p><i>[Santa Cruz: the real issue is that we've got const member +functions that return pointers to non-const, and N1360 proposes +replacing them by overloaded pairs. There isn't a consensus about +whether this is a real issue, since we've never said what our +constness policy is for iostreams. N1360 relies on a distinction +between physical constness and logical constness; that distinction, or +those terms, does not appear in the standard.]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p>In 27.4.4 and 27.4.4.2</p> +<p>Replace</p> +<pre> basic_ostream<charT,traits>* tie() const; +</pre> +<p>with</p> +<pre> basic_ostream<charT,traits>* tie(); + const basic_ostream<charT,traits>* tie() const; +</pre> + +<p>and replace</p> +<pre> basic_streambuf<charT,traits>* rdbuf() const; +</pre> +<p>with</p> +<pre> basic_streambuf<charT,traits>* rdbuf(); + const basic_streambuf<charT,traits>* rdbuf() const; +</pre> + +<p>In 27.5.2 and 27.5.2.3.1</p> +<p>Replace</p> +<pre> char_type* eback() const; +</pre> +<p>with</p> +<pre> char_type* eback(); + const char_type* eback() const; +</pre> + +<p>Replace</p> +<pre> char_type gptr() const; +</pre> +<p>with</p> +<pre> char_type* gptr(); + const char_type* gptr() const; +</pre> + +<p>Replace</p> +<pre> char_type* egptr() const; +</pre> +<p>with</p> +<pre> char_type* egptr(); + const char_type* egptr() const; +</pre> + +<p>In 27.5.2 and 27.5.2.3.2</p> +<p>Replace</p> +<pre> char_type* pbase() const; +</pre> +<p>with</p> +<pre> char_type* pbase(); + const char_type* pbase() const; +</pre> + +<p>Replace</p> +<pre> char_type* pptr() const; +</pre> +<p>with</p> +<pre> char_type* pptr(); + const char_type* pptr() const; +</pre> + +<p>Replace</p> +<pre> char_type* epptr() const; +</pre> +<p>with</p> +<pre> char_type* epptr(); + const char_type* epptr() const; +</pre> + +<p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p> +<p>Replace</p> +<pre> basic_stringbuf<charT,traits,Allocator>* rdbuf() const; +</pre> +<p>with</p> +<pre> basic_stringbuf<charT,traits,Allocator>* rdbuf(); + const basic_stringbuf<charT,traits,Allocator>* rdbuf() const; +</pre> + +<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p> +<p>Replace</p> +<pre> basic_filebuf<charT,traits>* rdbuf() const; +</pre> +<p>with</p> +<pre> basic_filebuf<charT,traits>* rdbuf(); + const basic_filebuf<charT,traits>* rdbuf() const; +</pre> + + +<p><b>Rationale:</b></p> +<p>The existing specification is a bit sloppy, but there's no + particular reason to change this other than tidiness, and there are + a number of ways in which streams might have been designed + differently if we were starting today. There's no evidence that the + existing constness policy is harming users. We might consider + a different constness policy as part of a full stream redesign.</p> + + + + + +<hr> +<h3><a name="367"></a>367. remove_copy/remove_copy_if and Input Iterators</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#NAD">NAD</a> + <b>Submitter:</b> Anthony Williams <b>Date:</b> 2002-05-13</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +remove_copy and remove_copy_if (25.2.8 [alg.remove]) permit their +input range to be marked with Input Iterators. However, since two +operations are required against the elements to copy (comparison and +assigment), when the input range uses Input Iterators, a temporary +copy must be taken to avoid dereferencing the iterator twice. This +therefore requires the value type of the InputIterator to be +CopyConstructible. If the iterators are at least Forward Iterators, +then the iterator can be dereferenced twice, or a reference to the +result maintained, so the temporary is not required. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add "If InputIterator does not meet the requirements of forward +iterator, then the value type of InputIterator must be copy +constructible. Otherwise copy constructible is not required." to +25.2.8 [alg.remove] paragraph 6. +</p> + + +<p><b>Rationale:</b></p> +<p>The assumption is that an input iterator can't be dereferenced + twice. There's no basis for that assumption in the Standard.</p> + + + + + +<hr> +<h3><a name="368"></a>368. basic_string::replace has two "Throws" paragraphs</h3> +<p><b>Section:</b> 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2002-06-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +21.3.6.6 [string::replace] basic_string::replace, second +signature, given in paragraph 1, has two "Throws" paragraphs (3 and +5). +</p> + +<p> +In addition, the second "Throws" paragraph (5) includes specification +(beginning with "Otherwise, the function replaces ...") that should be +part of the "Effects" paragraph. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>This is editorial. Both "throws" statements are true. The bug is + just that the second one should be a sentence, part of the "Effects" + clause, not a separate "Throws". The project editor has been + notified.</p> + + + + + +<hr> +<h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3> +<p><b>Section:</b> 17.4.4.9 [res.on.exception.handling], 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Randy Maddox <b>Date:</b> 2002-07-22</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> + +<p>Paragraph 3 under clause 17.4.4.9 [res.on.exception.handling], Restrictions on +Exception Handling, states that "Any other functions defined in the +C++ Standard Library that do not have an exception-specification may +throw implementation-defined exceptions unless otherwise specified." +This statement is followed by a reference to footnote 178 at the +bottom of that page which states, apparently in reference to the C++ +Standard Library, that "Library implementations are encouraged (but +not required) to report errors by throwing exceptions from (or derived +from) the standard exceptions."</p> + +<p>These statements appear to be in direct contradiction to clause +18.6.1 [type.info], which states "The class exception defines the +base class for the types of objects thrown as exceptions by the C++ +Standard library components ...".</p> + +<p>Is this inconsistent?</p> + + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>Clause 17 is setting the overall library requirements, and it's + clear and consistent. This sentence from Clause 18 is descriptive, + not setting a requirement on any other class. +</p> + + + + + +<hr> +<h3><a name="374"></a>374. moneypunct::frac_digits returns int not unsigned</h3> +<p><b>Section:</b> 22.2.6.3.1 [locale.moneypunct.members], 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-08</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In section 22.2.6.3.1 [locale.moneypunct.members], frac_digits() returns type +"int". This implies that frac_digits() might return a negative value, +but a negative value is nonsensical. It should return "unsigned". +</p> + +<p> +Similarly, in section 22.2.6.3.2 [locale.moneypunct.virtuals], do_frac_digits() +should return "unsigned". +</p> + + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>Regardless of whether the return value is int or unsigned, it's +always conceivable that frac_digits might return a nonsensical +value. (Is 4294967295 really any better than -1?) The clients of +moneypunct, the get and put facets, can and do perform range +checks.</p> + + + + + +<hr> +<h3><a name="377"></a>377. basic_string::insert and length_error</h3> +<p><b>Section:</b> 21.3.6.4 [string::insert] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-16</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 21.3.6.4 [string::insert], paragraph 4, contains the following, +"Then throws length_error if size() >= npos - rlen." +</p> + +<p> +Related to DR 83, this sentence should probably be removed. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p><p>This requirement is redundant but correct. No change is +needed.</p> + + + + +<hr> +<h3><a name="378"></a>378. locale immutability and locale::operator=()</h3> +<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a></p> +<p><b>Discussion:</b></p> +<p> +I think there is a problem with 22.1.1, p6 which says that +</p> +<pre> -6- An instance of locale is immutable; once a facet reference + is obtained from it, that reference remains usable as long + as the locale value itself exists. +</pre> +<p> +and 22.1.1.2, p4: +</p> +<pre> const locale& operator=(const locale& other) throw(); + + -4- Effects: Creates a copy of other, replacing the current value. +</pre> +<p> +How can a reference to a facet obtained from a locale object remain +valid after an assignment that clearly must replace all the facets +in the locale object? Imagine a program such as this +</p> +<pre> std::locale loc ("de_DE"); + const std::ctype<char> &r0 = std::use_facet<std::ctype<char> >(loc); + loc = std::locale ("en_US"); + const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(loc); +</pre> +<p> +Is r0 really supposed to be preserved and destroyed only when loc goes +out of scope? +</p> + + +<p><b>Proposed resolution:</b></p> +<p><i>[Summer '04 mid-meeting mailing: Martin and Dietmar believe this + is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a> and recommend that it be + closed. +]</i></p> + + + + + + +<hr> +<h3><a name="385"></a>385. Does call by value imply the CopyConstructible requirement?</h3> +<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Many function templates have parameters that are passed by value; +a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in +25.1.5 [alg.find]. Are the corresponding template parameters +(<tt>Predicate</tt> in this case) implicitly required to be +CopyConstructible, or does that need to be spelled out explicitly? +</p> + +<p> +This isn't quite as silly a question as it might seem to be at first +sight. If you call <tt>find_if</tt> in such a way that template +argument deduction applies, then of course you'll get call by value +and you need to provide a copy constructor. If you explicitly provide +the template arguments, however, you can force call by reference by +writing something like <tt>find_if<my_iterator, +my_predicate&></tt>. The question is whether implementation +are required to accept this, or whether this is ill-formed because +my_predicate& is not CopyConstructible. +</p> + +<p> +The scope of this problem, if it is a problem, is unknown. Function +object arguments to generic algorithms in clauses 25 [algorithms] +and 26 [numerics] are obvious examples. A review of the whole +library is necessary. +</p> +<p><i>[ +This is really two issues. First, predicates are typically passed by +value but we don't say they must be Copy Constructible. They should +be. Second: is specialization allowed to transform value arguments +into references? References aren't copy constructible, so this should +not be allowed. +]</i></p> + +<p><i>[ +2007-01-12, Howard: First, despite the note above, references <b>are</b> +copy constructible. They just aren't assignable. Second, this is very +closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> and should be consistent with that. +That issue already says that implementations are allowed to copy +function objects. If one passes in a reference, it is copyable, but +susceptible to slicing if one passes in a reference to a base. Third, +with rvalue reference in the language one only needs to satisfy +MoveConstructible to pass an rvalue "by value". Though the function +might still copy the function object internally (requiring +CopyConstructible). Finally (and fwiw), if we wanted to, it is easy to +code all of the std::algorithms such that they do not copy function +objects internally. One merely passes them by reference internally if +desired (this has been fully implemented and shipped for several years). + If this were mandated, it would reverse <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, allowing +function objects to reliably maintain state. E.g. the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> would reliably remove only the third element. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Recommend NAD. +</p> + + +<p><b>Rationale:</b></p> +<p> +Generic algorithms will be marked with concepts and these will imply a requirement +of MoveConstructible (not CopyConstructible). The signature of the function will +then precisely describe and enforce the precise requirements. +</p> + + + + + +<hr> +<h3><a name="388"></a>388. Use of complex as a key in associative containers</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#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Practice with std::complex<> and the associative containers +occasionally reveals artificial and distracting issues with constructs +resembling: std::set<std::complex<double> > s; +</p> + +<p> +The main reason for the above to fail is the absence of an approriate +definition for std::less<std::complex<T> >. That in turn comes from +the definition of the primary template std::less<> in terms of +operator<. +</p> + +<p> +The usual argument goes as follows: Since there is no ordering over +the complex field compatible with field operations it makes little +sense to define a function operator< operating on the datatype +std::complex<T>. That is fine. However, that reasoning does not carry +over to std::less<T> which is used, among other things, by associative +containers as an ordering useful to meet complexity requirements. +</p> + +<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p> + +<p><i>[ +Pre Bellevue: Reopened at the request of Alisdair. +]</i></p> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +This is a request for a design change, and not a defect in the standard. +It is in scope to consider, but the group feels that it is not a change +that we need to do. Is there a total ordering for floating point values, +including NaN? There is not a clear enough solution or big enough +problem for us to solve. Solving this problem would require solving the +problem for floating point, which is equally unclear. The LWG noted that +users who want to put objects into an associative container for which +operator< isn't defined can simply provide their own comparison function +object. NAD +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>Informally: Add a specialization of std::less for std::complex.</p> + + +<p><b>Rationale:</b></p> +<p>Discussed in Santa Cruz. An overwhelming majority of the LWG +believes this should not be treated a DR: it's a request for a design +change, not a defect in the existing standard. Most people (10-3) +believed that we probably don't want this change, period: as with +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, it's hard to know where to draw the line. +The LWG noted that users who want to put objects into an associative +container for which <tt>operator<</tt> isn't defined can simply +provide their own comparison function object.</p> + + + + + +<hr> +<h3><a name="390"></a>390. CopyConstructible requirements too strict</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#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Doug Gregor <b>Date:</b> 2002-10-24</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The CopyConstructible requirements in Table 30 state that for an +object t of type T (where T is CopyConstructible), the expression &t +returns the address of t (with type T*). This requirement is overly +strict, in that it disallows types that overload operator& to not +return a value of type T*. This occurs, for instance, in the <a href="http://www.boost.org/libs/lambda">Boost.Lambda</a> library, where +operator& is overloaded for a Boost.Lambda function object to return +another function object. +</p> + +<p>Example:</p> + +<pre> std::vector<int> u, v; + int x; + // ... + std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x); +</pre> + +<p> +_1 * x returns an unnamed function object with operator& overloaded to +not return T* , therefore rendering the std::transform call ill-formed. +However, most standard library implementations will compile this code +properly, and the viability of such binder libraries is severely hindered +by the unnecessary restriction in the CopyConstructible requirements. +</p> + +<p> +For reference, the address of an object can be retrieved without using +the address-of operator with the following function template: +</p> + +<pre> template <typename T> T* addressof(T& v) + { + return reinterpret_cast<T*>( + &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); + } +</pre> + +<p> +Note: this relates directly to library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, which +will need to be reexamined if the CopyConstructible requirements +change. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Remove the last two rows of Table 30, eliminating the requirements +that &t and &u return the address of t and u, respectively. +</p> + + +<p><b>Rationale:</b></p> +<p>This was a deliberate design decision. Perhaps it should be + reconsidered for C++0x. </p> + + + + + +<hr> +<h3><a name="392"></a>392. 'equivalence' for input iterators</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#NAD">NAD</a> + <b>Submitter:</b> Corwin Joy <b>Date:</b> 2002-12-11</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +In section 24.1.1 [input.iterators] table 72 - +'Input Iterator Requirements' we have as a postcondition of *a: +"If a==b and (a, b) is in the domain of == then *a is equivalent to *b". +</p> + +<p> +In section 24.5.3.5 [istreambuf.iterator::equal] it states that +"istreambuf_iterator::equal returns true if and only if both iterators +are at end-of-stream, or neither is at end-of-stream, <i>regardless of +what streambuf object they use</i>." (My emphasis). +</p> + +<p> +The defect is that either 'equivalent' needs to be more precisely +defined or the conditions for equality in 24.5.3.5 [istreambuf.iterator::equal] +are incorrect. (Or both). +</p> + +<p>Consider the following example:</p> +<pre> #include <iostream> + #include <fstream> + #include <iterator> + using namespace std; + + int main() { + ifstream file1("file1.txt"), file2("file2.txt"); + istreambuf_iterator<char> f1(file1), f2(file2); + cout << "f1 == f2 : " << boolalpha << (f1 == f2) << endl; + cout << "f1 = " << *f1 << endl; + cout << "f2 = " << *f2 << endl; + return 0; + } +</pre> + +<p>Now assuming that neither f1 or f2 are at the end-of-stream then +f1 == f2 by 24.5.3.5 [istreambuf.iterator::equal].</p> + +<p>However, it is unlikely that *f1 will give the same value as *f2 except +by accident.</p> + +<p>So what does *f1 'equivalent' to *f2 mean? I think the standard should +be clearer on this point, or at least be explicit that this does not +mean that *f1 and *f2 are required to have the same value in the case +of input iterators.</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p><p>The two iterators aer not in the domain of ==</p> + + + + + + +<hr> +<h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3> +<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +this DR follows the discussion on the previous thread "codecvt::do_in +not consuming external characters". It's just a clarification issue +and not a request for a change. +</p> +<p> +Can do_in()/do_out() produce output characters without consuming input +characters as a result of operation on state? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add a note at the end of 22.2.1.4.2 [locale.codecvt.virtuals], +paragraph 3: +</p> + +<p> +[Note: As a result of operations on state, it can return ok or partial +and set from_next == from and to_next != to. --end note] +</p> + + +<p><b>Rationale:</b></p> +<p> +The submitter believes that standard already provides an affirmative +answer to the question. However, the current wording has induced a few +library implementors to make the incorrect assumption that +do_in()/do_out() always consume at least one internal character when +they succeed. +</p> + +<p> +The submitter also believes that the proposed resolution is not in +conflict with the related issue 76. Moreover, by explicitly allowing +operations on state to produce characters, a codecvt implementation +may effectively implement N-to-M translations without violating the +"one character at a time" principle described in such issue. On a side +note, the footnote in the proposed resolution of issue 76 that +informally rules out N-to-M translations for basic_filebuf should be +removed if this issue is accepted as valid. +</p> + + +<p><i>[ +Kona (2007): The proposed resolution is to add a note. Since this is +non-normative, the issue is editorial, but we believe that the note is +correct. Proposed Disposition: NAD, Editorial +]</i></p> + + + + + + +<hr> +<h3><a name="399"></a>399. volations of unformatted input function requirements</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#NAD">NAD</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#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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> + <p> +The Effects clauses for the two functions below violate the +general requirements on unformatted input functions outlined +in 27.6.1.3: they do not begin by constructing a sentry object. +Instead, they begin by calling widen ('\n'), which may throw +an exception. The exception is then allowed to propagate from +the unformatted input function irrespective of the setting of +exceptions(). + </p> + <p> +Note that in light of 27.6.1.1, p3 and p4, the fact that the +functions allow exceptions thrown from widen() to propagate +may not strictly speaking be a defect (but the fact that the +functions do not start by constructing a sentry object still +is). However, since an exception thrown from ctype<charT> +::widen() during any other input operation (say, from within +a call to num_get<charT>::get()) will be caught and cause +badbit to be set, these two functions should not be treated +differently for the sake of consistency. + </p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p> +Not a defect. The standard is consistent, and the behavior required +by the standard is unambiguous. Yes, it's theoretically possible for +widen to throw. (Not that this will happen for the default ctype +facet or for most real-world replacement ctype facets.) Users who +define ctype facets that can throw, and who care about this behavior, +can use alternative signatures that don't call widen. +</p> + + + + + + +<hr> +<h3><a name="424"></a>424. normative notes</h3> +<p><b>Section:</b> 17.3.1.1 [structure.summary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +The text in 17.3.1.1, p1 says: +<br> + +"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other +paragraphs are normative." +<br> + +The library section makes heavy use of paragraphs labeled "Notes(s)," +some of which are clearly intended to be normative (see list 1), while +some others are not (see list 2). There are also those where the intent +is not so clear (see list 3). +<br><br> + +List 1 -- Examples of (presumably) normative Notes: +<br> + +20.7.5.1 [allocator.members], p3,<br> +20.7.5.1 [allocator.members], p10,<br> +21.3.2 [string.cons], p11,<br> +22.1.1.2 [locale.cons], p11,<br> +23.2.2.3 [deque.modifiers], p2,<br> +25.3.7 [alg.min.max], p3,<br> +26.3.6 [complex.ops], p15,<br> +27.5.2.4.3 [streambuf.virt.get], p7.<br> +<br> + +List 2 -- Examples of (presumably) informative Notes: +<br> + +18.5.1.3 [new.delete.placement], p3,<br> +21.3.6.6 [string::replace], p14,<br> +22.2.1.4.2 [locale.codecvt.virtuals], p3,<br> +25.1.4 [alg.foreach], p4,<br> +26.3.5 [complex.member.ops], p1,<br> +27.4.2.5 [ios.base.storage], p6.<br> +<br> + +List 3 -- Examples of Notes that are not clearly either normative +or informative: +<br> + +22.1.1.2 [locale.cons], p8,<br> +22.1.1.5 [locale.statics], p6,<br> +27.5.2.4.5 [streambuf.virt.put], p4.<br> +<br> + +None of these lists is meant to be exhaustive. +</p> + +<p><i>[Definitely a real problem. The big problem is there's material + that doesn't quite fit any of the named paragraph categories + (e.g. <b>Effects</b>). Either we need a new kind of named + paragraph, or we need to put more material in unnamed paragraphs + jsut after the signature. We need to talk to the Project Editor + about how to do this. +]</i></p> + + +<p><i>[ +Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2, +22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete +will handle editorially. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p><i>[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks". +Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004. +Recommend NAD.]</i></p> + +<p><i>[ +Batavia: We feel that the references in List 2 above should be changed from <i>Remarks</i> +to <i>Notes</i>. We also feel that those items in List 3 need to be double checked for +the same change. Alan and Pete to review. +]</i></p> + + + + + +<hr> +<h3><a name="429"></a>429. typo in basic_ios::clear(iostate)</h3> +<p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <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#iostate.flags">issues</a> in [iostate.flags].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a></p> +<p><b>Discussion:</b></p> + <p> + +The Effects clause in 27.4.4.3, p5 describing the effects of a call to +the ios_base member function clear(iostate state) says that the function +only throws if the respective bits are already set prior to the function +call. That's obviously not the intent. If it was, a call to clear(badbit) +on an object for which (rdstate() == goodbit && exceptions() == badbit) +holds would not result in an exception being thrown. + + </p> + + <p><b>Proposed resolution:</b></p> + <p> + +The text ought to be changed from +<br> + +"If (rdstate() & exceptions()) == 0, returns. ..." +<br> + +to +<br> + +"If (state & exceptions()) == 0, returns. ..." + </p> + + +<p><b>Rationale:</b></p> + + + + + + +<hr> +<h3><a name="433"></a>433. Contradiction in specification of unexpected()</h3> +<p><b>Section:</b> 18.7.2.4 [unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Date:</b> 2003-09-29</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected(); +is called (18.7.2) immediately after completing the stack unwinding +for the former function", but 18.7.2.4 (Effects) says that "void +unexpected(); . . . Calls the unexpected_handler function in effect +immediately after evaluating the throwexpression (18.7.2.2),". Isn't +here a contradiction: 15.5.2 requires stack have been unwound when in +void unexpected() and therefore in unexpected_handler but 18.7.2.4 +claims that unexpected_handler is called "in effect immediately" after +evaluation of throw expression is finished, so there is no space left +for stack to be unwound therefore? I think the phrase "in effect +immediately" should be removed from the standard because it brings +ambiguity in understanding. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>There is no contradiction. The phrase "in effect immediately" is + just to clarify which handler is to be called.</p> + + + + + +<hr> +<h3><a name="437"></a>437. Formatted output of function pointers is confusing</h3> +<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Ivan Godard <b>Date:</b> 2003-10-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Given: +</p> +<pre>void f(int) {} +void(*g)(int) = f; +cout << g; +</pre> + +<p> +(with the expected #include and usings), the value printed is a rather +surprising "true". Rather useless too. +</p> + +<p>The standard defines:</p> + +<pre>ostream& operator<<(ostream&, void*);</pre> + +<p>which picks up all data pointers and prints their hex value, but does +not pick up function pointers because there is no default conversion +from function pointer to void*. Absent that, we fall back to legacy +conversions from C and the function pointer is converted to bool. +</p> + +<p>There should be an analogous inserter that prints the address of a + function pointer.</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>This is indeed a wart, but there is no good way to solve it. C + doesn't provide a portable way of outputting the address of a + function point either.</p> + + + + + +<hr> +<h3><a name="439"></a>439. Should facets be copyable?</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#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-02</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>The following facets classes have no copy constructors described in + the standard, which, according to the standard, means that they are + supposed to use the compiler-generated defaults. Default copy + behavior is probably inappropriate. We should either make these + classes uncopyable or else specify exactly what their constructors do.</p> + +<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#421">421</a>.</p> + +<pre> ctype_base + ctype + ctype_byname + ctype<char> + ctype_byname<char> + codecvt_base + codecvt + codecvt_byname + num_get + num_put + numpunct + numpunct_byname + collate + collate_byname + time_base + time_get + time_get_byname + time_put + time_put_byname + money_get + money_put + money_base + moneypunct + moneypunct_byname + messages_base + messages + messages_byname +</pre> + + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>The copy constructor in the base class is private.</p> + + + + + +<hr> +<h3><a name="440"></a>440. Should std::complex use unqualified transcendentals?</h3> +<p><b>Section:</b> 26.3.8 [complex.transcendentals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-05</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Operations like <tt>pow</tt> and <tt>exp</tt> on +<tt>complex<T></tt> are typically implemented in terms of +operations like <tt>sin</tt> and <tt>cos</tt> on <tt>T</tt>. +Should implementations write this as <tt>std::sin</tt>, or as plain +unqualified <tt>sin</tt>? +</p> + +<p>The issue, of course, is whether we want to use +argument-dependent lookup in the case where <tt>T</tt> is a +user-defined type. This is similar to the issue of valarray +transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>.</p> + +<p>This issue differs from valarray transcendentals in two important +ways. First, "the effect of instantiating the template +<tt>complex</tt> for types other than float, double or long double is +unspecified." (26.3.1 [complex.synopsis]) Second, the standard does not +dictate implementation, so there is no guarantee that a particular +real math function is used in the implementation of a particular +complex function.</p> + + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>If you instantiate std::complex for user-defined types, all bets +are off.</p> + + + + + +<hr> +<h3><a name="447"></a>447. Wrong template argument for time facets</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#Dup">Dup</a> + <b>Submitter:</b> Pete Becker <b>Date:</b> 2003-12-26</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#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a></p> +<p><b>Discussion:</b></p> +<p> +22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others: +</p> +<pre> time_get<char,InputIterator> + time_get_byname<char,InputIterator> + time_get<wchar_t,OutputIterator> + time_get_byname<wchar_t,OutputIterator> +</pre> + +<p> +The second argument to the last two should be InputIterator, not +OutputIterator. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the second template argument to InputIterator. +</p> + + +<p><b>Rationale:</b></p> + + + + + + +<hr> +<h3><a name="450"></a>450. set::find is inconsistent with associative container requirements</h3> +<p><b>Section:</b> 23.3.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <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#set">issues</a> in [set].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a></p> +<p><b>Discussion:</b></p> +<p>map/multimap have:</p> + +<pre> iterator find(const key_type& x) const; + const_iterator find(const key_type& x) const; +</pre> + +<p> +which is consistent with the table of associative container requirements. +But set/multiset have: +</p> +<pre> iterator find(const key_type&) const; +</pre> + +<p> +set/multiset should look like map/multimap, and honor the requirements +table, in this regard. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> + + + + + + +<hr> +<h3><a name="451"></a>451. Associative erase should return an iterator</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.3 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <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#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p> +<p><b>Discussion:</b></p> +<p>map/multimap/set/multiset have:</p> +<pre> void erase(iterator); + void erase(iterator, iterator); +</pre> + +<p>But there's no good reason why these can't return an iterator, as for +vector/deque/list:</p> +<pre> iterator erase(iterator); + iterator erase(iterator, iterator); +</pre> + + + +<p><b>Proposed resolution:</b></p> +<p> +Informally: The table of associative container requirements, and the +relevant template classes, should return an iterator designating the +first element beyond the erased subrange. +</p> + + +<p><b>Rationale:</b></p> + + + + + + +<hr> +<h3><a name="452"></a>452. locale::combine should be permitted to generate a named locale</h3> +<p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <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#locale.members">issues</a> in [locale.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<pre>template<class Facet> + locale::combine(const locale&) const; +</pre> +<p> +is obliged to create a locale that has no name. This is overspecification +and overkill. The resulting locale should follow the usual rules -- it +has a name if the locale argument has a name and Facet is one of the +standard facets. +</p> + +<p><i>[ + Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440, + c++std-lib-13443): agreed that it's overkill to say that the locale + is obligated to be nameless. However, we also can't require it to + have a name. At the moment, locale names are based on categories + and not on individual facets. If a locale contains two different + facets of different names from the same category, then this would + not fit into existing naming schemes. We need to give + implementations more freedom. Bill will provide wording. +]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>After further discussion the LWG decided to close this as NAD. + The fundamental problem is that names right now are per-category, + not per-facet. The <tt>combine</tt> member function works at the + wrong level of granularity.</p> + + + + + +<hr> +<h3><a name="462"></a>462. Destroying objects with static storage duration</h3> +<p><b>Section:</b> 3.6.3 [basic.start.term], 18.3 [cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +3.6.3 Termination spells out in detail the interleaving of static +destructor calls and calls to functions registered with atexit. To +match this behavior requires intimate cooperation between the code +that calls destructors and the exit/atexit machinery. The former +is tied tightly to the compiler; the latter is a primitive mechanism +inherited from C that traditionally has nothing to do with static +construction and destruction. The benefits of intermixing destructor +calls with atexit handler calls is questionable at best, and <i>very</i> +difficult to get right, particularly when mixing third-party C++ +libraries with different third-party C++ compilers and C libraries +supplied by still other parties. +</p> + +<p> +I believe the right thing to do is defer all static destruction +until after all atexit handlers are called. This is a change in +behavior, but one that is likely visible only to perverse test +suites. At the very least, we should <i>permit</i> deferred destruction +even if we don't require it. +</p> + +<p><i>[If this is to be changed, it should probably be changed by CWG. + At this point, however, the LWG is leaning toward NAD. Implementing + what the standard says is hard work, but it's not impossible and + most vendors went through that pain years ago. Changing this + behavior would be a user-visible change, and would break at least + one real application.]</i></p> + + +<p><i>[ +Batavia: Send to core with our recommendation that we should permit deferred +destruction but not require it. +]</i></p> + + +<p><i>[ +Howard: The course of action recommended in Batavia would undo LWG +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a> and break current code implementing the "phoenix +singleton". Search the net for "phoenix singleton atexit" to get a feel +for the size of the adverse impact this change would have. Below is +sample code which implements the phoenix singleton and would break if +<tt>atexit</tt> is changed in this way: +]</i></p> + + +<blockquote><pre>#include <cstdlib> +#include <iostream> +#include <type_traits> +#include <new> + +class A +{ + bool alive_; + A(const A&); + A& operator=(const A&); +public: + A() : alive_(true) {std::cout << "A()\n";} + ~A() {alive_ = false; std::cout << "~A()\n";} + void use() + { + if (alive_) + std::cout << "A is alive\n"; + else + std::cout << "A is dead\n"; + } +}; + +void deallocate_resource(); + +// This is the phoenix singleton pattern +A& get_resource(bool create = true) +{ + static std::aligned_storage<sizeof(A), std::alignment_of<A>::value>::type buf; + static A* a; + if (create) + { + if (a != (A*)&buf) + { + a = ::new (&buf) A; + std::atexit(deallocate_resource); + } + } + else + { + a->~A(); + a = (A*)&buf + 1; + } + return *a; +} + +void deallocate_resource() +{ + get_resource(false); +} + +void use_A(const char* message) +{ + A& a = get_resource(); + std::cout << "Using A " << message << "\n"; + a.use(); +} + +struct B +{ + ~B() {use_A("from ~B()");} +}; + +B b; + +int main() +{ + use_A("from main()"); +} +</pre></blockquote> + +<p> +The correct output is: +</p> + +<blockquote><pre>A() +Using A from main() +A is alive +~A() +A() +Using A from ~B() +A is alive +~A() +</pre></blockquote> + +<p><i>[ +Bellevue: Confirmed no interaction with <tt>quick_exit</tt>. +Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change, +as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard. +Bill agrees issue is no longer serious, and accepts NAD. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</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#NAD">NAD</a> + <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-06-10</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Today, my colleagues and me wasted a lot of time. After some time, I +found the problem. It could be reduced to the following short example: +</p> + +<pre> #include <string> + int main() { std::string( 0 ); } +</pre> + +<p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and +Comeau online) compile the above without errors or warnings! The +programs (at least for the GCC) resulted in a SEGV.</p> + +<p>I know that the standard explicitly states that the ctor of string +requires a char* which is not zero. STLs could easily detect the above +case with a private ctor for basic_string which takes a single 'int' +argument. This would catch the above code at compile time and would not +ambiguate any other legal ctors.</p> + +<p><i>[Redmond: No great enthusiasm for doing this. If we do, + however, we want to do it for all places that take <tt>charT*</tt> + pointers, not just the single-argument constructor. The other + question is whether we want to catch this at compile time (in which + case we catch the error of a literal 0, but not an expression whose + value is a null pointer), at run time, or both.]</i></p> + + + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p> +Recommend NAD. Relegate this functionality to debugging implementations. +</p> + + + + + +<hr> +<h3><a name="470"></a>470. accessing containers from their elements' special functions</h3> +<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +The standard doesn't prohibit the destructors (or any other special +functions) of containers' elements invoked from a member function +of the container from "recursively" calling the same (or any other) +member function on the same container object, potentially while the +container is in an intermediate state, or even changing the state +of the container object while it is being modified. This may result +in some surprising (i.e., undefined) behavior. +</p> + +<p>Read email thread starting with c++std-lib-13637 for more.</p> + + + +<p><b>Proposed resolution:</b></p> + +<p>Add to Container Requirements the following new paragraph:</p> + +<pre> Unless otherwise specified, the behavior of a program that + invokes a container member function f from a member function + g of the container's value_type on a container object c that + called g from its mutating member function h, is undefined. + I.e., if v is an element of c, directly or indirectly calling + c.h() from v.g() called from c.f(), is undefined. +</pre> + +<p><i>[Redmond: This is a real issue, but it's probably a clause 17 + issue, not clause 23. We get the same issue, for example, if we + try to destroy a stream from one of the stream's callback functions.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p> +Recommend NAD. We agree this is an issue, but not a defect. +We believe that there is no wording we can put in the standard +that will cover all cases without introducing unfortunate +corner cases. +</p> + + + + + +<hr> +<h3><a name="472"></a>472. Missing "Returns" clause in std::equal_range</h3> +<p><b>Section:</b> 25.3.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Prateek R Karandikar <b>Date:</b> 2004-06-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a></p> +<p><b>Discussion:</b></p> +<p> +There is no "Returns:" clause for std::equal_range, which returns non-void. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>Fixed as part of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>.</p> + + + + + + +<hr> +<h3><a name="476"></a>476. Forward Iterator implied mutability</h3> +<p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> + +<p>24.1/3 says:</p> +<blockquote><p> + Forward iterators satisfy all the requirements of the input and + output iterators and can be used whenever either kind is specified +</p></blockquote> + +<p> +The problem is that satisfying the requirements of output iterator +means that you can always assign *something* into the result of +dereferencing it. That makes almost all non-mutable forward +iterators non-conforming. I think we need to sever the refinement +relationship between forward iterator and output iterator. +</p> + +<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>. But this is not a dup.</p> + + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>Yes, 24.1/3 does say that. But it's introductory material. The +precise specification is in 24.1.3, and the requrements table there is +right. We don't need to fine-tune introductory wording. (Especially +since this wording is likely to be changed as part of the iterator +overhaul.)</p> + + + + + +<hr> +<h3><a name="477"></a>477. Operator-> for const forward iterators</h3> +<p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-11</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p> +<p><b>Discussion:</b></p> +<p> +The Forward Iterator requirements table contains the following: +</p> +<pre> expression return type operational precondition + semantics + ========== ================== =========== ========================== + a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined. + otherwise const U& + + r->m U& (*r).m pre: (*r).m is well-defined. +</pre> + +<p> +The first line is exactly right. The second line is wrong. Basically +it implies that the const-ness of the iterator affects the const-ness +of referenced members. But Paragraph 11 of [lib.iterator.requirements] says: +</p> + +<blockquote><p> + In the following sections, a and b denote values of type const X, n + denotes a value of the difference type Distance, u, tmp, and m + denote identifiers, r denotes a value of X&, t denotes a value of + value type T, o denotes a value of some type that is writable to + the output iterator. +</p></blockquote> + +<p>AFAICT if we need the second line at all, it should read the same +as the first line.</p> + +<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>The LWG agrees that this is a real problem. Marked as a DUP + because the LWG chose to adopt the solution proposed in + <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. +</p> + + + + + +<hr> +<h3><a name="479"></a>479. Container requirements and placement new</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#Dup">Dup</a> + <b>Submitter:</b> Herb Sutter <b>Date:</b> 2004-08-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#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a></p> +<p><b>Discussion:</b></p> +<p>Nothing in the standard appears to make this program ill-formed:</p> + +<pre> struct C { + void* operator new( size_t s ) { return ::operator new( s ); } + // NOTE: this hides in-place and nothrow new + }; + + int main() { + vector<C> v; + v.push_back( C() ); + } +</pre> + +<p>Is that intentional? We should clarify whether or not we intended + to require containers to support types that define their own special + versions of <tt>operator new</tt>.</p> + +<p><i>[ +Lillehammer: A container will definitely never use this overridden +operator new, but whether it will fail to compile is unclear from the +standard. Are containers supposed to use qualified or unqualified +placement new? 20.4.1.1 is somewhat relevant, but the standard +doesn't make it completely clear whether containers have to use +Allocator::construct(). If containers don't use it, the details of how +containers use placement new are unspecified. That is the real bug, +but it needs to be fixed as part of the allocator overhaul. Weak +support that the eventual solution should make this code well formed. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> + + + + + + + +<hr> +<h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3> +<p><b>Section:</b> 20.6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Joe Gottman <b>Date:</b> 2004-08-19</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>The classes std::unary_function and std::binary_function are both +designed to be inherited from but contain no virtual functions. This +makes it too easy for a novice programmer to write code like +binary_function<int, int, int> *p = new plus<int>; delete p;</p> + +<p>There are two common ways to prevent this source of undefined +behavior: give the base class a public virtual destructor, or give it +a protected nonvirtual destructor. Since unary_function and +binary_function have no other virtual functions, (note in particular +the absence of an operator()() ), it would cost too much to give them +public virtual destructors. Therefore, they should be given protected +nonvirtual destructors.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change Paragraph 20.3.1 of the Standard from</p> +<pre> template <class Arg, class Result> + struct unary_function { + typedef Arg argument_type; + typedef Result result_type; + }; + + template <class Arg1, class Arg2, class Result> + struct binary_function { + typedef Arg1 first_argument_type; + typedef Arg2 second_argument_type; + typedef Result result_type; + }; +</pre> + +<p>to</p> +<pre> template <class Arg, class Result> + struct unary_function { + typedef Arg argument_type; + typedef Result result_type; + protected: + ~unary_function() {} + }; + + template <class Arg1, class Arg2, class Result> + struct binary_function { + typedef Arg1 first_argument_type; + typedef Arg2 second_argument_type; + typedef Result result_type; + protected: + ~binary_function() {} + }; +</pre> + + +<p><b>Rationale:</b></p> +<p>The LWG doesn't believe the existing definition causes anybody any + concrete harm.</p> + + + + + +<hr> +<h3><a name="481"></a>481. unique's effects on the range [result, last)</h3> +<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-08-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The standard says that unique(first, last) "eliminates all but the +first element from every consecutive group of equal elements" in +[first, last) and returns "the end of the resulting range". So a +postcondition is that [first, result) is the same as the old [first, +last) except that duplicates have been eliminated. +</p> + +<p>What postconditions are there on the range [result, last)? One + might argue that the standard says nothing about those values, so + they can be anything. One might also argue that the standard + doesn't permit those values to be changed, so they must not be. + Should the standard say something explicit one way or the other?</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + +<p><b>Rationale:</b></p> +<p>We don't want to make many guarantees about what's in [result, +end). Maybe we aren't being quite explicit enough about not being +explicit, but it's hard to think that's a major problem.</p> + + + + + +<hr> +<h3><a name="482"></a>482. Swapping pairs</h3> +<p><b>Section:</b> 20.2.3 [pairs], 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-09-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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p>(Based on recent comp.std.c++ discussion)</p> + +<p>Pair (and tuple) should specialize std::swap to work in terms of +std::swap on their components. For example, there's no obvious reason +why swapping two objects of type pair<vector<int>, +list<double> > should not take O(1).</p> + +<p><i>[Lillehammer: We agree it should be swappable. Howard will + provide wording.]</i></p> + + +<p><i>[ +Post Oxford: We got <tt>swap</tt> for <tt>pair</tt> but accidently +missed <tt>tuple</tt>. <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +Wording provided in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>. +</p> + +<p><b>Rationale:</b></p> +<p> +Recommend NAD, fixed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>. +</p> + + + + + +<hr> +<h3><a name="483"></a>483. Heterogeneous equality and EqualityComparable</h3> +<p><b>Section:</b> 25.1 [alg.nonmodifying], 25.2 [alg.modifying.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2004-09-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a></p> +<p><b>Discussion:</b></p> +<p>c++std-lib-14262</p> + +<p>[lib.alg.find] requires T to be EqualityComparable:</p> + +<pre>template <class InputIterator, class T> + InputIterator find(InputIterator first, InputIterator last, + const T& value); +</pre> + +<p> +However the condition being tested, as specified in the Effects +clause, is actually *i == value, where i is an InputIterator. +</p> + +<p> +The two clauses are in agreement only if the type of *i is T, but this +isn't necessarily the case. *i may have a heterogeneous comparison +operator that takes a T, or a T may be convertible to the type of *i. +</p> + +<p>Further discussion (c++std-lib-14264): this problem affects a + number of algorithsm in clause 25, not just <tt>find</tt>. We + should try to resolve this problem everywhere it appears.</p> + + +<p><b>Proposed resolution:</b></p> + +<p>[lib.alg.find]:</p> +<blockquote><p> + Remove [lib.alg.find]/1. +</p></blockquote> + +<p>[lib.alg.count]:</p> +<blockquote><p> + Remove [lib.alg.count]/1. +</p></blockquote> + +<p>[lib.alg.search]:</p> +<blockquote><p> + Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4. +</p></blockquote> + +<p>[lib.alg.replace]:</p> + +<blockquote> + <p> + Remove [lib.alg.replace]/1. + Replace [lb.alg.replace]/2 with: + </p> + + <blockquote><p> + For every iterator i in the range [first, last) for which *i == value + or pred(*i) holds perform *i = new_value. + </p></blockquote> + + <p> + Remove the first sentence of /4. + Replace the beginning of /5 with: + </p> + + <blockquote><p> + For every iterator i in the range [result, result + (last - + first)), assign to *i either... + </p></blockquote> + + <p>(Note the defect here, current text says assign to i, not *i).</p> +</blockquote> + +<p>[lib.alg.fill]:</p> + +<blockquote> + <p> + Remove "Type T is Assignable (23.1), " from /1. + Replace /2 with: + </p> + + <blockquote><p> + For every iterator i in the range [first, last) or [first, first + n), + perform *i = value. + </p></blockquote> +</blockquote> + +<p>[lib.alg.remove]:</p> +<blockquote><p> + Remove /1. + Remove the first sentence of /6. +</p></blockquote> + + + +<p><b>Rationale:</b></p> +<p>Duplicate of (a subset of) issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>.</p> + + + + + + +<hr> +<h3><a name="486"></a>486. min/max CopyConstructible requirement is too strict</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#Dup">Dup</a> + <b>Submitter:</b> Dave Abrahams <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#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#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a></p> +<p><b>Discussion:</b></p> +<p>A straightforward implementation of these algorithms does not need to +copy T.</p> + + +<p><b>Proposed resolution:</b></p> +<p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p> + + +<p><b>Rationale:</b></p> + + + + + + +<hr> +<h3><a name="487"></a>487. Allocator::construct is too limiting</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#NAD">NAD</a> + <b>Submitter:</b> Dhruv Matani <b>Date:</b> 2004-10-17</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The standard's version of allocator::construct(pointer, +const_reference) severely limits what you can construct using this +function. Say you can construct a socket from a file descriptor. Now, +using this syntax, I first have to manually construct a socket from +the fd, and then pass the constructed socket to the construct() +function so it will just to an uninitialized copy of the socket I +manually constructed. Now it may not always be possible to copy +construct a socket eh! So, I feel that the changes should go in the +allocator::construct(), making it: +</p> +<pre> template<typename T> + struct allocator{ + template<typename T1> + void construct(pointer T1 const& rt1); + }; +</pre> + +<p> +Now, the ctor of the class T which matches the one that takes a T1 can +be called! Doesn't that sound great? +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>NAD. STL uses copying all the time, and making it possible for + allocators to construct noncopyable objects is useless in the + absence of corresponding container changes. We might consider this + as part of a larger redesign of STL.</p> + + + + + +<hr> +<h3><a name="489"></a>489. std::remove / std::remove_if wrongly specified</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#NAD">NAD</a> + <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the +behavior of the mutating sequence operations std::remove and +std::remove_if. However, the wording does not reflect the intended +behavior [Note: See definition of intended behavior below] of these +algorithms, as it is known to the C++ community [1]. +</p> + + + +<p>1) Analysis of current wording:</p> + + +<p>25.2.7 [lib.alg.remove], paragraph 2:</p> + +<p>Current wording says: +"Effects: Eliminates all the elements referred to by iterator i in the +range [first, last) for which the following corresponding conditions +hold: *i == value, pred(*i) != false."</p> + +<p> +This sentences expresses specifically that all elements denoted by the +(original) range [first, last) for which the corresponding condition +hold will be eliminated. Since there is no formal definition of the term +"eliminate" provided, the meaning of "eliminate" in everyday language +implies that as postcondition, no element in the range denoted by +[first, last) will hold the corresponding condition on reiteration over +the range [first, last). +</p> + +<p> +However, this is neither the intent [Note: See definition of intended +behavior below] nor a general possible approach. It can be easily proven +that if all elements of the original range[first, last) will hold the +condition, it is not possible to substitute them by an element for which +the condition will not hold. +</p> + + +<p>25.2.7 [lib.alg.remove], paragraph 3:</p> + +<p> +Current wording says: +"Returns: The end of the resulting range." +</p> + +<p> +The resulting range is not specified. In combination with 25.2.7 +[lib.alg.remove], paragraph 2, the only reasonable interpretation of +this so-called resulting range is the range [first,last) - thus +returning always the ForwardIterator 'last' parameter. +</p> + + +<p> +25.2.7 [lib.alg.remove], paragraph 4: +</p> + +<p> +Current wording says: +"Notes: Stable: the relative order of the elements that are not removed +is the same as their relative order in the original range" +</p> + +<p> +This sentences makes use of the term "removed", which is neither +specified, nor used in a previous paragraph (which uses the term +"eliminate"), nor unamgiuously separated from the name of the algorithm. +</p> + + +<p>2) Description of intended behavior:</p> + +<p> +For the rest of this Defect Report, it is assumed that the intended +behavior was that all elements of the range [first, last) which do not +hold the condition *i == value (std::remove) or pred(*i) != false +(std::remove_if)], call them s-elements [Note: s...stay], will be placed +into a contiguous subrange of [first, last), denoted by the iterators +[first, return value). The number of elements in the resulting range +[first, return value) shall be equal to the number of s-elements in the +original range [first, last). The relative order of the elements in the +resulting subrange[first, return value) shall be the same as the +relative order of the corresponding elements in the original range. It +is undefined whether any elements in the resulting subrange [return +value, last) will hold the corresponding condition, or not. +</p> + +<p> +All implementations known to the author of this Defect Report comply +with this intent. Since the intent of the behavior (contrary to the +current wording) is also described in various utility references serving +the C++ community [1], it is not expected that fixing the paragraphs +will influence current code - unless the code relies on the behavior as +it is described by current wording and the implementation indeed +reflects the current wording, and not the intent. +</p> + + + +<p>3) Proposed fixes:</p> + + +<p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p> + +<p> +"Effect: Places all the elements referred to by iterator i in the range +[first, last) for which the following corresponding conditions hold : +!(*i == value), pred(*i) == false into the subrange [first, k) of the +original range, where k shall denote a value of type ForwardIterator. It +is undefined whether any elements in the resulting subrange [k, last) +will hold the corresponding condition, or not." +</p> + +<p>Comments to the new wording:</p> + +<p> +a) "Places" has no special meaning, and the everyday language meaning +should fit. +b) The corresponding conditions were negated compared to the current +wording, becaue the new wording requires it. +c) The wording "of the original range" might be redundant, since any +subrange starting at 'first' and containing no more elements than the +original range is implicitly a subrange of the original range [first, +last). +d) The iterator k was introduced instead of "return value" in order to +avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall +denote a value of type ForwardIterator" might be redundant, because it +follows implicitly by 25.2.7/3. +e) "Places" does, in the author's opinion, explicitly forbid duplicating +any element holding the corresponding condition in the original range +[first, last) within the resulting range [first, k). If there is doubt +this term might be not unambiguous regarding this, it is suggested that +k is specified more closely by the following wording: "k shall denote a +value of type ForwardIterator [Note: see d)] so that k - first is equal +to the number of elements in the original range [first, last) for which +the corresponding condition did hold". This could also be expressed as a +separate paragraph "Postcondition:" +f) The senctence "It is undefined whether any elements in the resulting +subrange [k, last) will hold the corresponding condition, or not." was +added consciously so the term "Places" does not imply if the original +range [first, last) contains n elements holding the corresponding +condition, the identical range[first, last) will also contain exactly n +elements holding the corresponding condition after application of the +algorithm. +</p> + +<p> +Change 25.2.7 [lib.alg.remove], paragraph 3 to: + +"Returns: The iterator k." +</p> + +<p> +Change 25.2.7 [lib.alg.remove], paragraph 4 to: + +"Notes: Stable: the relative order of the elements that are placed into +the subrange [first, return value) shall be the same as their relative +order was in the original range [first, last) prior to application of +the algorithm." +</p> + +<p> +Comments to the new wording: +</p> + +<p> +a) the wording "was ... prior to application of the algorithm" is used +to explicitly distinguish the original range not only by means of +iterators, but also by a 'chronological' factor from the resulting range +[first, return value). It might be redundant. +</p> + +<p> +[1]: +The wording of these references is not always unambiguous, and provided +examples partially contradict verbal description of the algorithms, +because the verbal description resembles the problematic wording of +ISO/IEC 14882:2003. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>The LWG believes that the standard is sufficiently clear, and that + there is no evidence of any real-world confusion about this point.</p> + + + + + +<hr> +<h3><a name="490"></a>490. std::unique wrongly specified</h3> +<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the +behavior of the mutating sequence operation std::unique. However, the +wording does not reflect the intended behavior [Note: See definition of +intended behavior below] of these algorithms, as it is known to the C++ +community [1].</p> + + + +<p>1) Analysis of current wording:</p> + + +<p>25.2.8 [lib.alg.unique], paragraph 1:</p> + +<p> +Current wording says: +"Effects: Eliminates all but the first element from every consecutive +group of equal elements referred to by the iterator i in the range +[first, last) for which the following corresponding conditions hold: *i +== *(i - 1) or pred(*i, *(i -1)) != false" +</p> + +<p> +This sentences expresses specifically that all elements denoted by the +(original) range [first, last) which are not but the first element from +a consecutive group of equal elements (where equality is defined as *i +== *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call +them r-elements [Note: r...remove], will be eliminated. Since there is +no formal definition of the term "eliminate" provided, it is undefined +how this "elimination" takes place. But the meaning of "eliminate" in +everyday language seems to disallow explicitly that after application of +the algorithm, any r-element will remain at any position of the range +[first, last) [2]. +</p> + +<p> +Another defect in the current wording concerns the iterators used to +compare two elements for equality: The current wording contains the +expression "(i - 1)", which is not covered by 25/9 [Note: See DR +submitted by Thomas Mang regarding invalid iterator arithmetic +expressions]. +</p> + + +<p> +25.2.8 [lib.alg.unique], paragraph 2: +</p> +<p>Current wording says: +"Returns: The end of the resulting range."</p> + +<p> +The resulting range is not specified. In combination with 25.2.8 +[lib.alg.unique], paragraph 1, one reasonable interpretation (in the +author's opinion even the only possible interpretation) of this +so-called resulting range is the range [first, last) - thus returning +always the ForwardIterator 'last' parameter. +</p> + +<p>2) Description of intended behavior:</p> + +<p> +For the rest of this Defect Report, it is assumed that the intended +behavior was that all elements denoted by the original range [first, +last) which are the first element from a consecutive group of elements +for which the corresponding conditions: *(i-1) == *i (for the version of +unique without a predicate argument) or pred(*(i-1), *i) ! = false (for +the version of unique with a predicate argument) [Note: If such a group +of elements consists of only a single element, this is also considered +the first element] [Note: See resolutions of DR 202], call them +s-elements [Note: s...stay], will be placed into a contiguous subrange +of [first, last), denoted by the iterators [first, return value). The +number of elements in the resulting range [first, return value) shall be +equal to the number of s-elements in the original range [first, last). +Invalid iterator arithmetic expressions are expected to be resolved as +proposed in DR submitted by Thomas Mang regarding invalid iterator +arithmetic expressions. It is also assumed by the author that the +relative order of the elements in the resulting subrange [first, return +value) shall be the same as the relative order of the corresponding +elements (the s-elements) in the original range [Note: If this was not +intended behavior, the additional proposed paragraph about stable order +will certainly become obsolete]. +Furthermore, the resolutions of DR 202 are partially considered. +</p> + +<p> +All implementations known to the author of this Defect Report comply +with this intent [Note: Except possible effects of DR 202]. Since this +intent of the behavior (contrary to the current wording) is also +described in various utility references serving the C++ community [1], +it is not expected that fixing the paragraphs will influence current +code [Note: Except possible effects of DR 202] - unless the code relies +on the behavior as it is described by current wording and the +implementation indeed reflects the current wording, and not the intent. +</p> + + + +<p>3) Proposed fixes:</p> + +<p> +Change 25.2.8 [lib.alg.unique], paragraph 1 to: +</p> + +<p> +"Effect: Places the first element from every consecutive group of +elements, referred to by the iterator i in the range [first, last), for +which the following conditions hold: *(i-1) == *i (for the version of +unique without a predicate argument) or pred(*(i -1), *i) != false (for +the version of unique with a predicate argument), into the subrange +[first, k) of the original range, where k shall denote a value of type +ForwardIterator." +</p> + +<p>Comments to the new wording:</p> + +<p> +a) The new wording was influenced by the resolutions of DR 202. If DR +202 is resolved in another way, the proposed wording need also +additional review. +b) "Places" has no special meaning, and the everyday language meaning +should fit. +c) The expression "(i - 1)" was left, but is expected that DR submitted +by Thomas Mang regarding invalid iterator arithmetic expressions will +take this into account. +d) The wording "(for the version of unique without a predicate +argument)" and "(for the version of unique with a predicate argument)" +was added consciously for clarity and is in resemblence with current +23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant. +e) The wording "of the original range" might be redundant, since any +subrange starting at first and containing no more elements than the +original range is implicitly a subrange of the original range [first, +last). +f) The iterator k was introduced instead of "return value" in order to +avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The +wording ", where k shall denote a value of type ForwardIterator" might +be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique], +paragraph 2. +g) "Places" does, in the author's opinion, explicitly forbid duplicating +any s-element in the original range [first, last) within the resulting +range [first, k). If there is doubt this term might be not unambiguous +regarding this, it is suggested that k is specified more closely by the +following wording: "k shall denote a value of type ForwardIterator +[Note: See f)] so that k - first is equal to the number of elements in +the original range [first, last) being the first element from every +consecutive group of elements for which the corresponding condition did +hold". This could also be expressed as a separate paragraph +"Postcondition:". +h) If it is considered that the wording is unclear whether it declares +the element of a group which consists of only a single element +implicitly to be the first element of this group [Note: Such an +interpretation could eventually arise especially in case last - first == +1] , the following additional sentence is proposed: "If such a group of +elements consists of only a single element, this element is also +considered the first element." +</p> + +<p> +Change 25.2.8 [lib.alg.unique], paragraph 2 to: +"Returns: The iterator k." +</p> + +<p> +Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph +2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8 +[lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if +the preceding expressions are used, or the preceding expressions shall +be eliminated if wording inside {} is used): +</p> + +<p> +"Notes:{Postcondition:} Stable: the relative order of the elements that +are placed into the subrange [first, return value {k}) shall be the same +as their relative order was in the original range [first, last) prior to +application of the algorithm." +</p> + +<p>Comments to the new wording:</p> + +<p> +a) It is assumed by the author that the algorithm was intended to be +stable. +In case this was not the intent, this paragraph becomes certainly +obsolete. +b) The wording "was ... prior to application of the algorithm" is used +to explicitly distinguish the original range not only by means of +iterators, but also by a 'chronological' factor from the resulting range +[first, return value). It might be redundant. +</p> + +<p> +25.2.8 [lib.alg.unique], paragraph 3: +</p> +<p>See DR 239.</p> + +<p> +4) References to other DRs: +</p> + +<p> +See DR 202, but which does not address any of the problems described in +this Defect Report [Note: This DR is supposed to complement DR 202]. +See DR 239. +See DR submitted by Thomas Mang regarding invalid iterator arithmetic +expressions. +</p> + +<p> +[1]: +The wording of these references is not always unambiguous, and provided +examples partially contradict verbal description of the algorithms, +because the verbal description resembles the problematic wording of +ISO/IEC 14882:2003. +</p> + +<p> +[2]: +Illustration of conforming implementations according to current wording: +</p> + +<p> +One way the author of this DR considers how this "elimination" could be +achieved by a conforming implementation according to current wording is +by substituting each r-element by _any_ s-element [Note: s...stay; any +non-r-element], since all r-elements are "eliminated". +</p> + +<p> +In case of a sequence consisting of elements being all 'equal' [Note: +See DR 202], substituting each r-element by the single s-element is the +only possible solution according to current wording. +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>The LWG believes the standard is sufficiently clear. No +implementers get it wrong, and changing it wouldn't cause any code to +change, so there is no real-world harm here.</p> + + + + + +<hr> +<h3><a name="491"></a>491. std::list<>::unique incorrectly specified</h3> +<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>In Section 23.2.4.4 [list.ops], paragraphs 19 to 21 describe the +behavior of the std::list<T, Allocator>::unique operation. However, the +current wording is defective for various reasons.</p> + + + +<p> +1) Analysis of current wording: +</p> + +<p>23.2.4.4 [list.ops], paragraph 19:</p> + +<p> +Current wording says: +"Effects: Eliminates all but the first element from every consecutive +group of equal elements referred to by the iterator i in the range +[first + 1, last) for which *i == *(i - 1) (for the version of unique +with no argument) or pred(*i, *(i -1)) (for the version of unique with a +predicate argument) holds."</p> + +<p> +This sentences makes use of the undefined term "Eliminates". Although it +is, to a certain degree, reasonable to consider the term "eliminate" +synonymous with "erase", using "Erase" in the first place, as the +wording of 23.2.4.4 [list.ops], paragraph 15 does, would be clearer.</p> + +<p> +The range of the elements referred to by iterator i is "[first + 1, +last)". However, neither "first" nor "last" is defined.</p> + +<p> +The sentence makes three times use of iterator arithmetic expressions ( +"first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not +defined for bidirectional iterator [see DR submitted by Thomas Mang +regarding invalid iterator arithmetic expressions].</p> + +<p> +The same problems as pointed out in DR 202 (equivalence relation / order +of arguments for pred()) apply to this paragraph.</p> + +<p> +23.2.4.4 [list.ops], paragraph 20: +</p> + +<p> +Current wording says: +"Throws: Nothing unless an exception in thrown by *i == *(i-1) or +pred(*i, *(i - 1))"</p> + +<p> +The sentence makes two times use of invalid iterator arithmetic +expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ). +</p> +<p> +[Note: Minor typos: "in" / missing dot at end of sentence.] +</p> + +<p> +23.2.4.4 [list.ops], paragraph 21:</p> + +<p> +Current wording says: +"Complexity: If the range (last - first) is not empty, exactly (last - +first) - 1 applications of the corresponding predicate, otherwise no +application of the predicate.</p> + +<p> +See DR 315 regarding "(last - first)" not yielding a range.</p> + +<p> +Invalid iterator arithmetic expression "(last - first) - 1" left .</p> + + +<p>2) Description of intended behavior:</p> + +<p> +For the rest of this Defect Report, it is assumed that "eliminate" is +supposed to be synonymous to "erase", that "first" is equivalent to an +iterator obtained by a call to begin(), "last" is equivalent to an +iterator obtained by a call to end(), and that all invalid iterator +arithmetic expressions are resolved as described in DR submitted by +Thomas Mang regarding invalid iterator arithmetic expressions.</p> + +<p> +Furthermore, the resolutions of DR 202 are considered regarding +equivalence relation and order of arguments for a call to pred.</p> + +<p> +All implementations known to the author of this Defect Report comply +with these assumptions, apart from the impact of the alternative +resolution of DR 202. Except for the changes implied by the resolutions +of DR 202, no impact on current code is expected.</p> + +<p> +3) Proposed fixes:</p> + +<p> +Change 23.2.4.4 [list.ops], paragraph 19 to:</p> + +<p> +"Effect: Erases all but the first element from every consecutive group +of elements, referred to by the iterator i in the range [begin(), +end()), for which the following conditions hold: *(i-1) == *i (for the +version of unique with no argument) or pred(*(i-1), *i) != false (for +the version of unique with a predicate argument)."</p> + +<p> +Comments to the new wording:</p> + +<p> +a) The new wording was influenced by DR 202 and the resolutions +presented there. If DR 202 is resolved in another way, the proposed +wording need also additional review. +b) "Erases" refers in the author's opinion unambiguously to the member +function "erase". In case there is doubt this might not be unamgibuous, +a direct reference to the member function "erase" is suggested [Note: +This would also imply a change of 23.2.4.4 [list.ops], paragraph +15.]. +c) The expression "(i - 1)" was left, but is expected that DR submitted +by Thomas Mang regarding invalid iterator arithmetic expressions will +take this into account. +d) The wording "(for the version of unique with no argument)" and "(for +the version of unique with a predicate argument)" was kept consciously +for clarity. +e) "begin()" substitutes "first", and "end()" substitutes "last". The +range need adjustment from "[first + 1, last)" to "[begin(), end())" to +ensure a valid range in case of an empty list. +f) If it is considered that the wording is unclear whether it declares +the element of a group which consists of only a single element +implicitly to be the first element of this group [Note: Such an +interpretation could eventually arise especially in case size() == 1] , +the following additional sentence is proposed: "If such a group of +elements consists of only a single element, this element is also +considered the first element."</p> + +<p> +Change 23.2.4.4 [list.ops], paragraph 20 to:</p> + +<p> +"Throws: Nothing unless an exception is thrown by *(i-1) == *i or +pred(*(i-1), *i)."</p> + +<p> +Comments to the new wording:</p> + +<p> +a) The wording regarding the conditions is identical to proposed +23.2.4.4 [list.ops], paragraph 19. If 23.2.4.4 [list.ops], +paragraph 19 is resolved in another way, the proposed wording need also +additional review. +b) The expression "(i - 1)" was left, but is expected that DR submitted +by Thomas Mang regarding invalid iterator arithmetic expressions will +take this into account. +c) Typos fixed.</p> + +<p> +Change 23.2.4.4 [list.ops], paragraph 21 to:</p> + +<p> +"Complexity: If empty() == false, exactly size() - 1 applications of the +corresponding predicate, otherwise no applications of the corresponding +predicate."</p> + +<p> +Comments to the new wording:</p> + +<p> +a) The new wording is supposed to also replace the proposed resolution +of DR 315, which suffers from the problem of undefined "first" / "last". +</p> + +<p> +5) References to other DRs:</p> + +<p>See DR 202. +See DR 239. +See DR 315. +See DR submitted by Thomas Mang regarding invalid iterator arithmetic +expressions.</p> + + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>"All implementations known to the author of this Defect Report +comply with these assumption", and "no impact on current code is +expected", i.e. there is no evidence of real-world confusion or +harm.</p> + + + + + +<hr> +<h3><a name="493"></a>493. Undefined Expression in Input Iterator Note Title</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#NAD">NAD</a> + <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-12-13</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>1) In 24.1.1/3, the following text is currently present.</p> + +<p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does +not guarantee the substitution property or referential transparency)."</p> + +<p>However, when in Table 72, part of the definition of ++r is given as:</p> + +<p>"pre: r is dereferenceable. +post: any copies of the previous value of r are no longer required +either to be dereferenceable ..."</p> + +<p>While a==b does not imply that b is a copy of a, this statement should +perhaps still be made more clear.</p> + +<p>2) There are no changes to intended behaviour</p> + +<p> +3) This Note should be altered to say "Note: For input iterators a==b, +when its behaviour is defined ++a==++b may still be false (Equality does +not guarantee the substitution property or referential transparency).</p> + + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>This is descriptive text, not normative, and the meaning is clear.</p> + + + + + +<hr> +<h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Hans B os <b>Date:</b> 2004-12-19</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p>According to [lib.associative.reqmts] table 69, the runtime comlexity +of insert(p, t) and erase(q) can be done in amortized constant time.</p> + +<p>It was my understanding that an associative container could be +implemented as a balanced binary tree.</p> + +<p>For inser(p, t), you 'll have to iterate to p's next node to see if t +can be placed next to p. Furthermore, the insertion usually takes +place at leaf nodes. An insert next to the root node will be done at +the left of the root next node</p> + +<p>So when p is the root node you 'll have to iterate from the root to +its next node, which takes O(log(size)) time in a balanced tree.</p> + +<p>If you insert all values with insert(root, t) (where root is the +root of the tree before insertion) then each insert takes O(log(size)) +time. The amortized complexity per insertion will be O(log(size)) +also.</p> + +<p>For erase(q), the normal algorithm for deleting a node that has no +empty left or right subtree, is to iterate to the next (or previous), +which is a leaf node. Then exchange the node with the next and delete +the leaf node. Furthermore according to DR 130, erase should return +the next node of the node erased. Thus erasing the root node, +requires iterating to the next node.</p> + +<p>Now if you empty a map by deleting the root node until the map is +empty, each operation will take O(log(size)), and the amortized +complexity is still O(log(size)).</p> + +<p>The operations can be done in amortized constant time if iterating +to the next node can be done in (non amortized) constant time. This +can be done by putting all nodes in a double linked list. This +requires two extra links per node. To me this is a bit overkill since +you can already efficiently insert or erase ranges with erase(first, +last) and insert(first, last).</p> + + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p>Only "amortized constant" in special circumstances, and we believe + that's implementable. That is: doing this N times will be O(N), not + O(log N).</p> + + + + + +<hr> +<h3><a name="499"></a>499. Std. doesn't seem to require stable_sort() to be stable!</h3> +<p><b>Section:</b> 25.3.1.2 [stable.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Prateek Karandikar <b>Date:</b> 2005-04-12</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<blockquote><p> +17.3.1.1 Summary</p> + +<p> +1 The Summary provides a synopsis of the category, and introduces the +first-level subclauses. Each subclause also provides a summary, listing +the headers specified in the subclause and the library entities +provided in each header. +</p> +<p> +2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, +other paragraphs are normative. +</p></blockquote> + +<p>So this means that a "Notes" paragraph wouldn't be normative. </p> + +<blockquote><p> +25.3.1.2 stable_sort +</p> +<pre>template<class RandomAccessIterator> +void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); + +template<class RandomAccessIterator, class Compare> +void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp); +</pre> +<p> +1 Effects: Sorts the elements in the range [first, last). +</p> +<p> +2 Complexity: It does at most N(log N)^2 (where N == last - first) +comparisons; if enough extra memory is available, it is N log N. +</p> +<p> +3 Notes: Stable: the relative order of the equivalent elements is +preserved. +</p></blockquote> + +<p> +The Notes para is informative, and nowhere else is stability mentioned above. +</p> + +<p> +Also, I just searched for the word "stable" in my copy of the Standard. +and the phrase "Notes: Stable: the relative order of the elements..." +is repeated several times in the Standard library clauses for +describing various functions. How is it that stability is talked about +in the informative paragraph? Or am I missing something obvious? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + +<p><b>Rationale:</b></p> +<p> +This change has already been made. +</p> + + + + + +<hr> +<h3><a name="500"></a>500. do_length cannot be implemented correctly</h3> +<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Krzysztof Żelechowski <b>Date:</b> 2005-05-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<ol> +<li>codecvt::do_length is of type int;</li> +<li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li> +<li>ptrdiff_t cannot be cast to an int without data loss.</li> +</ol> +<p> +Contradiction. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3> +<p><b>Section:</b> 20.6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Me <anti_spam_email2003@yahoo.com> <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#base">issues</a> in [base].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<blockquote><p> +"For templates greater, less, greater_equal, and less_equal, +the specializations for any pointer type yield a total order, even if +the built-in operators <, >, <=, >= do not." +</p></blockquote> + +<p> +The standard should do much better than guarantee that these provide a +total order, it should guarantee that it can be used to test if memory +overlaps, i.e. write a portable memmove. You can imagine a platform +where the built-in operators use a uint32_t comparison (this tests for +overlap on this platform) but the less<T*> functor is allowed to be +defined to use a int32_t comparison. On this platform, if you use +std::less with the intent of making a portable memmove, comparison on +an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give +incorrect results. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add a footnote to 20.5.3/8 saying: +</p> + +<blockquote><p> +Given a p1 and p2 such that p1 points to N objects of type T and p2 +points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M), +less returns the same value when comparing all pointers in [p1,p1+N) to +all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R +such that less returns the same value when comparing all pointers in +[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when +comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M). +For the sake of completeness, the null pointer value (4.10) for T is +considered to be an array of 1 object that doesn't overlap with any +non-null pointer to T. less_equal, greater, greater_equal, equal_to, +and not_equal_to give the expected results based on the total ordering +semantics of less. For T of void, treat it as having similar semantics +as T of char i.e. less<cv T*>(a, b) gives the same results as less<cv +void*>(a, b) which gives the same results as less<cv char*>((cv +char*)(cv void*)a, (cv char*)(cv void*)b). +</p></blockquote> + +<p> +I'm also thinking there should be a footnote to 20.5.3/1 saying that if +A and B are similar types (4.4/4), comp<A>(a,b) returns the same value +as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might +be problematic if there is some really funky operator overloading going +on that does different things based on cv (that should be undefined +behavior if somebody does that though). This at least should be +guaranteed for all POD types (especially pointers) that use the +built-in comparison operators. +</p> + + + +<p><b>Rationale:</b></p> +<p> +less is already required to provide a strict weak ordering which is good enough +to detect overlapping memory situations. +</p> + + + + + +<hr> +<h3><a name="504"></a>504. Integer types in pseudo-random number engine requirements</h3> +<p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type, +g is an ... object returning values of unsigned integral type ..." +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 5.1.1 [tr.rand.req], Paragraph 2 replace +</p> + +<blockquote><p> +... s is a value of integral type, g is an lvalue of a type other than X that +defines a zero-argument function object returning values of <del>unsigned integral</del> type +<ins><tt>unsigned long int</tt></ins>, +... +</p></blockquote> + +<p> +In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s) +</p> + +<blockquote><p> +creates an engine with the initial internal state +determined by <ins><tt>static_cast<unsigned long>(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins> +</p></blockquote> + +<p><i>[ +Mont Tremblant: Both s and g should be unsigned long. +This should refer to the constructor signatures. Jens provided wording post Mont Tremblant. +]</i></p> + + +<p><i>[ +Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved +to Ready. +]</i></p> + + + + +<p><b>Rationale:</b></p> +<p> +Jens: Just requiring X(unsigned long) still makes it possible +for an evil library writer to also supply a X(int) that does something +unexpected. The wording above requires that X(s) always performs +as if X(unsigned long) would have been called. I believe that is +sufficient and implements our intentions from Mont Tremblant. I +see no additional use in actually requiring a X(unsigned long) +signature. u.seed(s) is covered by its reference to X(s), same +arguments. +</p> + + +<p><i>[ +Portland: Subsumed by N2111. +]</i></p> + + + + + +<hr> +<h3><a name="506"></a>506. Requirements of Distribution parameter for variate_generator</h3> +<p><b>Section:</b> 26.4 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Paragraph 3 requires that template argument U (which corresponds to template +parameter Engine) satisfy all uniform random number generator requirements. +However, there is no analogous requirement regarding the template argument +that corresponds to template parameter Distribution. We believe there should +be, and that it should require that this template argument satisfy all random +distribution requirements. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18. +</p> +<p> +Consequence 2: Add max() and min() functions to those distributions that +do not already have them. +</p> + +<p><i>[ +Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere. +Marc supports having min and max to satisfy generic programming interface. +]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>Berlin: N1932 makes this moot: variate_generator has been eliminated.</p> + + + + + +<hr> +<h3><a name="509"></a>509. Uniform_int template parameters</h3> +<p><b>Section:</b> 26.4.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In [tr.rand.dist.iunif] the uniform_int distribution currently has a single +template parameter, IntType, used as the input_type and as the result_type +of the distribution. We believe there is no reason to conflate these types +in this way. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +We recommend that there be a second template parameter to +reflect the distribution's input_type, and that the existing first template +parameter continue to reflect (solely) the result_type: +</p> +<blockquote><pre>template< class IntType = int, UIntType = unsigned int > +class uniform_int +{ +public: + // types + typedef UIntType input_type; + typedef IntType result_type; +</pre></blockquote> + +<p><i>[ +Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been +eliminated. +]</i></p> + + + + + + + +<hr> +<h3><a name="510"></a>510. Input_type for bernoulli_distribution</h3> +<p><b>Section:</b> 26.4.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In [tr.rand.dist.bern] the distribution currently requires; +</p> +<blockquote><pre>typedef int input_type; +</pre></blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +We believe this is an unfortunate choice, and recommend instead: +</p> +<blockquote><pre>typedef unsigned int input_type; +</pre></blockquote> + +<p><i>[ +Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been +eliminated. +]</i></p> + + + + + + + +<hr> +<h3><a name="511"></a>511. Input_type for binomial_distribution</h3> +<p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Unlike all other distributions in TR1, this binomial_distribution has an +implementation-defined input_type. We believe this is an unfortunate choice, +because it hinders users from writing portable code. It also hinders the +writing of compliance tests. We recommend instead: +</p> +<blockquote><pre>typedef RealType input_type; +</pre></blockquote> +<p> +While this choice is somewhat arbitrary (as it was for some of the other +distributions), we make this particular choice because (unlike all other +distributions) otherwise this template would not publish its RealType +argument and so users could not write generic code that accessed this +second template parameter. In this respect, the choice is consistent with +the other distributions in TR1. +</p> +<p> +We have two reasons for recommending that a real type be specified instead. +One reason is based specifically on characteristics of binomial distribution +implementations, while the other is based on mathematical characteristics of +probability distribution functions in general. +</p> +<p> +Implementations of binomial distributions commonly use Stirling approximations +for values in certain ranges. It is far more natural to use real values to +represent these approximations than it would be to use integral values to do +so. In other ranges, implementations reply on the Bernoulli distribution to +obtain values. While TR1's bernoulli_distribution::input_type is specified as +int, we believe this would be better specified as double. +</p> +<p> +This brings us to our main point: The notion of a random distribution rests +on the notion of a cumulative distribution function, which in turn mathematically +depends on a continuous dependent variable. Indeed, such a distribution function +would be meaningless if it depended on discrete values such as integers - and this +remains true even if the distribution function were to take discrete steps. +</p> +<p> +Although this note is specifically about binomial_distribution::input_type, +we intend to recommend that all of the random distributions input_types be +specified as a real type (either a RealType template parameter, or double, +as appropriate). +</p> +<p> +Of the nine distributions in TR1, four already have this characteristic +(uniform_real, exponential_distribution, normal_distribution, and +gamma_distribution). We have already argued the case for the binomial the +remaining four distributions. +</p> +<p> +In the case of uniform_int, we believe that the calculations to produce an +integer result in a specified range from an integer in a different specified +range is best done using real arithmetic. This is because it involves a +product, one of whose terms is the ratio of the extents of the two ranges. +Without real arithmetic, the results become less uniform: some numbers become +more (or less) probable that they should be. This is, of course, undesireable +behavior in a uniform distribution. +</p> +<p> +Finally, we believe that in the case of the bernoulli_distribution (briefly +mentioned earlier), as well as the cases of the geometric_distribution and the +poisson_distribution, it would be far more natural to have a real input_type. +This is because the most natural computation involves the random number +delivered and the distribution's parameter p (in the case of bernoulli_distribution, +for example, the computation is a comparison against p), and p is already specified +in each case as having some real type. +</p> + + +<p><b>Proposed resolution:</b></p> +<blockquote><pre>typedef RealType input_type; +</pre></blockquote> + +<p><i>[ +Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been +eliminated. +]</i></p> + + + + + + +<hr> +<h3><a name="512"></a>512. Seeding subtract_with_carry_01 from a single unsigned long</h3> +<p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine +is to be seeded given a single unsigned long. This algorithm is seriously +flawed in the case where the engine parameter w (also known as word_size) +exceeds 31 [bits]. The key part of the paragraph reads: +</p> +<blockquote><p> +sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1 +</p></blockquote> +<p> +and so forth. +</p> +<p> +Since the specified linear congruential engine, lcg, delivers numbers with +a maximum of 2147483563 (just a shade under 31 bits), then when w is, for +example, 48, each of the x(i) will be less than 2**-17. The consequence +is that roughly the first 400 numbers delivered will be conspicuously +close to either zero or one. +</p> +<p> +Unfortunately, this is not an innocuous flaw: One of the predefined engines +in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit +this poor behavior, while the original N1378 proposal states that these +pre-defined engines are intended to be of "known good properties." +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for +void seed(unsigned long value = 19780503) by +</p> + +<blockquote><p> +<i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any +case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters +<tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>, +<tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del> +sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) … x(-1)</tt> +<ins>as if executing</ins></p> + +<blockquote><pre><ins> +linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value); +seed(lcg); +</ins></pre></blockquote> + +<p> +<del>to <tt>(<i>lcg</i>(1) · 2<sup>-<i>w</i></sup>) mod 1 +… (<i>lcg</i>(<i>r</i>) · 2<sup>-<i>w</i></sup>) mod 1</tt>, +respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>, +else sets carry<tt>(-1) = 0</tt>.</del></p> +</blockquote> + +<p><i>[ +Jens provided revised wording post Mont Tremblant. +]</i></p> + + +<p><i>[ +Berlin: N1932 adopts the originally-proposed resolution of the issue. +Jens's supplied wording is a clearer description of what is +intended. Moved to Ready. +]</i></p> + + + + +<p><b>Rationale:</b></p> +<p> +Jens: I'm using an explicit type here, because fixing the +prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a> even +stricter) requirements we have for seed(Gen&). +</p> + +<p><i>[ +Portland: Subsumed by N2111. +]</i></p> + + + + + + +<hr> +<h3><a name="513"></a>513. Size of state for subtract_with_carry_01</h3> +<p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Paragraph 3 begins: +</p> +<blockquote><p> +The size of the state is r. +</p></blockquote> +<p> +However, this is not quite consistent with the remainder of the paragraph +which specifies a total of nr+1 items in the textual representation of +the state. We recommend the sentence be corrected to match: +</p> +<blockquote><p> +The size of the state is nr+1. +</p></blockquote> +<p> +To give meaning to the coefficient n, it may be also desirable to move +n's definition from later in the paragraph. Either of the following +seem reasonable formulations: +</p> +<blockquote><p> +With n=..., the size of the state is nr+1. +</p></blockquote> +<blockquote><p> +The size of the state is nr+1, where n=... . +</p></blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p><i>[ +Jens: I plead for "NAD" on the grounds that "size of state" is only +used as an argument for big-O complexity notation, thus +constant factors and additions don't count. +]</i></p> + + +<p><i>[ +Berlin: N1932 adopts the proposed NAD. +]</i></p> + + + + + + + +<hr> +<h3><a name="514"></a>514. Size of state for subtract_with_carry</h3> +<p><b>Section:</b> 26.4.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Paragraph 2 begins: +</p> +<blockquote><p> +The size of the state is r. +</p></blockquote> +<p> +However, the next sentence specifies a total of r+1 items in the textual +representation of the state, r specific x's as well as a specific carry. +This makes a total of r+1 items that constitute the size of the state, +rather than r. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +We recommend the sentence be corrected to match: +</p> +<blockquote><p> + The size of the state is r+1. +</p></blockquote> + +<p><i>[ +Jens: I plead for "NAD" on the grounds that "size of state" is only +used as an argument for big-O complexity notation, thus +constant factors and additions don't count. +]</i></p> + + +<p><i>[ +Berlin: N1932 adopts the proposed NAD. +]</i></p> + + + + + + + +<hr> +<h3><a name="515"></a>515. Random number engine traits</h3> +<p><b>Section:</b> 26.4.2 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +To accompany the concept of a pseudo-random number engine as defined in Table 17, +we propose and recommend an adjunct template, engine_traits, to be declared in +[tr.rand.synopsis] as: +</p> +<blockquote><pre>template< class PSRE > +class engine_traits; +</pre></blockquote> +<p> +This template's primary purpose would be as an aid to generic programming involving +pseudo-random number engines. Given only the facilities described in tr1, it would +be very difficult to produce any algorithms involving the notion of a generic engine. +The intent of this proposal is to provide, via engine_traits<>, sufficient +descriptive information to allow an algorithm to employ a pseudo-random number engine +without regard to its exact type, i.e., as a template parameter. +</p> +<p> +For example, today it is not possible to write an efficient generic function that +requires any specific number of random bits. More specifically, consider a +cryptographic application that internally needs 256 bits of randomness per call: +</p> +<blockquote><pre>template< class Eng, class InIter, class OutIter > +void crypto( Eng& e, InIter in, OutIter out ); +</pre></blockquote> +<p> +Without knowning the number of bits of randomness produced per call to a provided +engine, the algorithm has no means of determining how many times to call the engine. +</p> +<p> +In a new section [tr.rand.eng.traits], we proposed to define the engine_traits +template as: +</p> +<blockquote><pre>template< class PSRE > +class engine_traits +{ + static std::size_t bits_of_randomness = 0u; + static std::string name() { return "unknown_engine"; } + // TODO: other traits here +}; +</pre></blockquote> +<p> +Further, each engine described in [tr.rand.engine] would be accompanied by a +complete specialization of this new engine_traits template. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p><i>[ +Berlin: Walter: While useful for implementation per TR1, N1932 has no need for this +feature. Recommend close as NAD. +]</i></p> + + + +<p><b>Rationale:</b></p> +<p> +Recommend NAD, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1932.pdf">N1932</a>, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a> +covers this. Already in WP. +</p> + + + + + +<hr> +<h3><a name="516"></a>516. Seeding subtract_with_carry_01 using a generator</h3> +<p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Paragraph 6 says: +</p> +<blockquote><p> +... obtained by successive invocations of g, ... +</p></blockquote> +<p> +We recommend instead: +</p> +<blockquote><p> +... obtained by taking successive invocations of g mod 2**32, ... +</p></blockquote> +<p> +as the context seems to require only 32-bit quantities be used here. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready. +</p> + +<p><i>[ +Portland: Subsumed by N2111. +]</i></p> + + + + + + +<hr> +<h3><a name="517"></a>517. Should include name in external representation</h3> +<p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The last two rows of Table 16 deal with the i/o requirements of an engine, +specifying that the textual representation of an engine's state, +appropriately formatted, constitute the engine's external representation. +</p> +<p> +This seems adequate when an engine's type is known. However, it seems +inadequate in the context of generic code, where it becomes useful and +perhaps even necessary to determine an engine's type via input. +</p> +<p> +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +We therefore recommend that, in each of these two rows of Table 16, the +text "textual representation" be expanded so as to read "engine name +followed by the textual representation." +</p> + +<p><i>[ +Berlin: N1932 considers this NAD. This is a QOI issue. +]</i></p> + + + + + + + +<hr> +<h3><a name="525"></a>525. type traits definitions not clear</h3> +<p><b>Section:</b> 20.5.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Robert Klarer <b>Date:</b> 2005-07-11</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It is not completely clear how the primary type traits deal with +cv-qualified types. And several of the secondary type traits +seem to be lacking a definition. +</p> + +<p><i>[ +Berlin: Howard to provide wording. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Wording provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028</a>. +A +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a> +provides more detail for motivation. +</p> + + +<p><b>Rationale:</b></p> +Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a> +in the WP. + + + + + +<hr> +<h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2005-09-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Problem: There are a number of places in the C++ standard library where +it is possible to write what appear to be sensible ways of calling +functions, but which can cause problems in some (or all) +implementations, as they cause the values given to the function to be +changed in a way not specified in standard (and therefore not coded to +correctly work). These fall into two similar categories. +</p> + +<p> +1) Parameters taken by const reference can be changed during execution +of the function +</p> + +<p> +Examples: +</p> + +<p> +Given std::vector<int> v: +</p> +<p> +v.insert(v.begin(), v[2]); +</p> +<p> +v[2] can be changed by moving elements of vector +</p> + + +<p> +Given std::list<int> l: +</p> +<p> +l.remove(*l.begin()); +</p> +<p> +Will delete the first element, and then continue trying to access it. +This is particularily vicious, as it will appear to work in almost all +cases. +</p> + +<p> +2) A range is given which changes during the execution of the function: +Similarly, +</p> + +<p> +v.insert(v.begin(), v.begin()+4, v.begin()+6); +</p> + +<p> +This kind of problem has been partly covered in some cases. For example +std::copy(first, last, result) states that result cannot be in the range +[first, last). However, does this cover the case where result is a +reverse_iterator built from some iterator in the range [first, last)? +Also, std::copy would still break if result was reverse_iterator(last + +1), yet this is not forbidden by the standard +</p> + +<p> +Solution: +</p> + +<p> +One option would be to try to more carefully limit the requirements of +each function. There are many functions which would have to be checked. +However as has been shown in the std::copy case, this may be difficult. +A simpler, more global option would be to somewhere insert text similar to: +</p> + +<p> +If the execution of any function would change either any values passed +by reference or any value in any range passed to a function in a way not +defined in the definition of that function, the result is undefined. +</p> + +<p> +Such code would have to at least cover chapters 23 and 25 (the sections +I read through carefully). I can see no harm on applying it to much of +the rest of the standard. +</p> + +<p> +Some existing parts of the standard could be improved to fit with this, +for example the requires for 25.2.1 (Copy) could be adjusted to: +</p> + +<p> +Requires: For each non-negative integer n < (last - first), assigning to +*(result + n) must not alter any value in the range [first + n, last). +</p> + +<p> +However, this may add excessive complication. +</p> + +<p> +One other benefit of clearly introducing this text is that it would +allow a number of small optimisations, such as caching values passed +by const reference. +</p> + +<p> +Matt Austern adds that this issue also exists for the <tt>insert</tt> and +<tt>erase</tt> members of the ordered and unordered associative containers. +</p> + +<p><i>[ +Berlin: Lots of controversey over how this should be solved. Lots of confusion +as to whether we're talking about self referencing iterators or references. +Needs a good survey as to the cases where this matters, for which +implementations, and how expensive it is to fix each case. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p> +Recommend NAD. +</p> +<ul> +<li><tt>vector::insert(iter, value)</tt> is required to work because the standard +doesn't give permission for it not to work.</li> +<li><tt>list::remove(value)</tt> is required to work because the standard +doesn't give permission for it not to work.</li> +<li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because +23.1.3 [sequence.reqmts], p4 says so.</li> +<li><tt>copy</tt> has to work, except where 25.2.1 [alg.copy] says +it doesn't have to work. While a language lawyer can tear this wording apart, +it is felt that the wording is not prone to accidental interpretation.</li> +<li>The current working draft provide exceptions for the unordered associative +containers similar to the containers requirements which exempt the member +template insert functions from self referencing.</li> +</ul> + + + + + +<hr> +<h3><a name="528"></a>528. <tt>const_iterator</tt> <tt>iterator</tt> issue when they are the same type</h3> +<p><b>Section:</b> 23.4 [unord], TR1 6.3.4 [tr.unord.unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-10-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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +while implementing the resolution of issue 6.19 I'm noticing the +following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and +unordered_multiset: +</p> + +<blockquote><p> + "The iterator and const_iterator types are both const types. It is +unspecified whether they are the same type" +</p></blockquote> + +<p> +Now, according to the resolution of 6.19, we have overloads of insert +with hint and erase (single and range) both for iterator and +const_iterator, which, AFAICS, can be meaningful at the same time *only* +if iterator and const_iterator *are* in fact different types. +</p> +<p> +Then, iterator and const_iterator are *required* to be different types? +Or that is an unintended consequence? Maybe the overloads for plain +iterators should be added only to unordered_map and unordered_multimap? +Or, of course, I'm missing something? +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add to 6.3.4.3p2 (and 6.3.4.5p2): +</p> +<p> +2 ... The iterator and const_iterator types are both <del>const</del> +<ins>constant</ins> iterator types. +It is unspecified whether they are the same type. +</p> + +<p> +Add a new subsection to 17.4.4 [lib.conforming]: +</p> + +<blockquote> +<p> +An implementation shall not supply an overloaded function + signature specified in any library clause if such a signature + would be inherently ambiguous during overload resolution + due to two library types referring to the same type. +</p> +<p> + [Note: For example, this occurs when a container's iterator + and const_iterator types are the same. -- end note] +</p> +</blockquote> + +<p><i>[ +Post-Berlin: Beman supplied wording. +]</i></p> + + + + +<p><b>Rationale:</b></p> +Toronto: The first issue has been fixed by N2350 (the insert and erase members +are collapsed into one signature). Alisdair to open a separate issue on the +chapter 17 wording. + + + + + +<hr> +<h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3> +<p><b>Section:</b> 17.4.3.10 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +17.4.3.8/1 says: +</p> + +<blockquote><p> +Violation of the preconditions specified in a function's +Required behavior: paragraph results in undefined behavior unless the +function's Throws: paragraph specifies throwing an exception when the +precondition is violated. +</p></blockquote> + +<p> +This implies that a precondition violation can lead to defined +behavior. That conflicts with the only reasonable definition of +precondition: that a violation leads to undefined behavior. Any other +definition muddies the waters when it comes to analyzing program +correctness, because precondition violations may be routinely done in +correct code (e.g. you can use std::vector::at with the full +expectation that you'll get an exception when your index is out of +range, catch the exception, and continue). Not only is it a bad +example to set, but it encourages needless complication and redundancy +in the standard. For example: +</p> + +<blockquote><pre> 21 Strings library + 21.3.3 basic_string capacity + + void resize(size_type n, charT c); + + 5 Requires: n <= max_size() + 6 Throws: length_error if n > max_size(). + 7 Effects: Alters the length of the string designated by *this as follows: +</pre></blockquote> + +<p> +The Requires clause is entirely redundant and can be dropped. We +could make that simplifying change (and many others like it) even +without changing 17.4.3.8/1; the wording there just seems to encourage +the redundant and error-prone Requires: clause. +</p> + +<p><i>[ +Batavia: Alan and Pete to work. +]</i></p> + + +<p><i>[ +Bellevue: NAD Editorial, this group likes +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>, +Pete agrees, accepting it is Pete's business. +General agreement that precondition violations are synonymous with UB. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +1. Change 17.4.3.8/1 to read: +</p> + +<blockquote><p> +Violation of the preconditions specified in a function's +<i>Required behavior:</i> paragraph results in undefined behavior +<del>unless the function's <i>Throws:</i> paragraph specifies throwing +an exception when the precondition is violated</del>. +</p></blockquote> + +<p> +2. Go through and remove redundant Requires: clauses. Specifics to be + provided by Dave A. +</p> + +<p><i>[ +Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution. +]</i></p> + + +<p><i>[ +Alan provided the survey +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>. +]</i></p> + + + + + + + +<hr> +<h3><a name="532"></a>532. Tuple comparison</h3> +<p><b>Section:</b> 20.4.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> + <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-11-29</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a></p> +<p><b>Discussion:</b></p> +<p> +Where possible, tuple comparison operators <,<=,=>, and > ought to be +defined in terms of std::less rather than operator<, in order to +support comparison of tuples of pointers. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +change 6.1.3.5/5 from: +</p> + +<blockquote><p> + Returns: The result of a lexicographical comparison between t and + u. The result is defined as: (bool)(get<0>(t) < get<0>(u)) || + (!(bool)(get<0>(u) < get<0>(t)) && ttail < utail), where rtail for + some tuple r is a tuple containing all but the first element of + r. For any two zero-length tuples e and f, e < f returns false. +</p></blockquote> + +<p> +to: +</p> + +<blockquote> +<p> + Returns: The result of a lexicographical comparison between t and + u. For any two zero-length tuples e and f, e < f returns false. + Otherwise, the result is defined as: cmp( get<0>(t), get<0>(u)) || + (!cmp(get<0>(u), get<0>(t)) && ttail < utail), where rtail for some + tuple r is a tuple containing all but the first element of r, and + cmp(x,y) is an unspecified function template defined as follows. +</p> +<p> + Where T is the type of x and U is the type of y: +</p> + +<p> + if T and U are pointer types and T is convertible to U, returns + less<U>()(x,y) +</p> + +<p> + otherwise, if T and U are pointer types, returns less<T>()(x,y) +</p> + +<p> + otherwise, returns (bool)(x < y) +</p> +</blockquote> + +<p><i>[ +Berlin: This issue is much bigger than just tuple (pair, containers, +algorithms). Dietmar will survey and work up proposed wording. +]</i></p> + + + + +<p><b>Rationale:</b></p> +<p> +Recommend NAD. This will be fixed with the next revision of concepts. +</p> + + + + + +<hr> +<h3><a name="536"></a>536. Container iterator constructor and explicit convertibility</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#Dup">Dup</a> + <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2005-12-17</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#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a></p> +<p><b>Discussion:</b></p> +<p> +The iterator constructor X(i,j) for containers as defined in 23.1.1 and +23.2.2 does only require that i and j be input iterators but +nothing is said about their associated value_type. There are three +sensible +options: +</p> +<ol> +<li>iterator's value_type is exactly X::value_type (modulo cv).</li> +<li>iterator's value_type is *implicitly* convertible to X::value_type.</li> +<li>iterator's value_type is *explicitly* convertible to X::value_type.</li> +</ol> +<p> +The issue has practical implications, and stdlib vendors have +taken divergent approaches to it: Dinkumware follows 2, +libstdc++ follows 3. +</p> +<p> +The same problem applies to the definition of insert(p,i,j) for +sequences and insert(i,j) for associative contianers, as well as +assign. +</p> + +<p><i>[ +The following added by Howard and the example code was originally written by +Dietmar. +]</i></p> + +<p> +Valid code below? +</p> + +<blockquote><pre>#include <vector> +#include <iterator> +#include <iostream> + +struct foo +{ + explicit foo(int) {} +}; + +int main() +{ + std::vector<int> v_int; + std::vector<foo> v_foo1(v_int.begin(), v_int.end()); + std::vector<foo> v_foo2((std::istream_iterator<int>(std::cin)), + std::istream_iterator<int>()); +} +</pre></blockquote> +<p><i>[ +Berlin: Some support, not universal, for respecting the explicit qualifier. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> + + + + + + +<hr> +<h3><a name="544"></a>544. minor NULL problems in C.2</h3> +<p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-25</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>, +<cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, +or <cwchar>." This is consistent with the C standard. +</p> +<p> +However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>. +</p> +<p> +In addition, C.2, p2 claims that "The C++ Standard library provides +54 standard macros from the C library, as shown in Table 95." While +table 95 does have 54 entries, since a couple of them (including the +NULL macro) are listed more than once, the actual number of macros +defined by the C++ Standard Library may not be 54. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +I propose we add <clocale> and <cstdlib> to Table 96 and remove the +number of macros from C.2, p2 and reword the sentence as follows: +</p> +<blockquote><p> +The C++ Standard library <del>provides 54 standard macros from</del> +<ins>defines a number macros corresponding to those defined by</ins> the C +<ins>Standard</ins> library, as shown in Table 96. +</p></blockquote> + +<p><i>[ +Portland: Resolution is considered editorial. It will be incorporated into the WD. +]</i></p> + + + + + + + +<hr> +<h3><a name="547"></a>547. division should be floating-point, not integer</h3> +<p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Paragraph 10 describes how a variate generator uses numbers produced by an +engine to pass to a generator. The sentence that concerns me is: "Otherwise, if +the value for engine_value_type::result_type is true and the value for +Distribution::input_type is false [i.e. if the engine produces integers and the +engine wants floating-point values], then the numbers in s_eng are divided by +engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the +engine is producing integers, both the numerator and the denominator are +integers and we'll be doing integer division, which I don't think is what we +want. Shouldn't we be performing a conversion to a floating-point type first? +</p> + + +<p><b>Proposed resolution:</b></p> + + +<p><b>Rationale:</b></p> +<p> +Recommend NAD as the affected section is now gone and so the issue is moot. +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>. +</p> + + + + + +<hr> +<h3><a name="548"></a>548. May random_device block?</h3> +<p><b>Section:</b> 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Class random_device "produces non-deterministic random numbers", using some +external source of entropy. In most real-world systems, the amount of available +entropy is limited. Suppose that entropy has been exhausted. What is an +implementation permitted to do? In particular, is it permitted to block +indefinitely until more random bits are available, or is the implementation +required to detect failure immediately? This is not an academic question. On +Linux a straightforward implementation would read from /dev/random, and "When +the entropy pool is empty, reads to /dev/random will block until additional +environmental noise is gathered." Programmers need to know whether random_device +is permitted to (or possibly even required to?) behave the same way. +</p> + +<p><i>[ +Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin +may block? +]</i></p> + + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +for some further discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> (NAD). +</p> + + + + + +<hr> +<h3><a name="549"></a>549. Undefined variable in binomial_distribution</h3> +<p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Paragraph 1 says that "A binomial distributon random distribution produces +integer values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and +p are the parameters of the distribution. OK, that tells us what t, p, and i +are. What's n? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1. +</p> + +<p><i>[ +Portland: Subsumed by N2111. +]</i></p> + + + + + + +<hr> +<h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3> +<p><b>Section:</b> 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-01-30</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the synopsis, some types are identified as optional: int8_t, int16_t, +and so on, consistently with C99, indeed. +</p> +<p> +On the other hand, intptr_t and uintptr_t, are not marked as such and +probably should, consistently with C99, 7.18.1.4. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 18.3.1 [cstdint.syn]: +</p> + +<blockquote><pre>... +typedef <i>signed integer type</i> intptr_t; <ins><i>// optional</i></ins> +... +typedef <i>unsigned integer type</i> uintptr_t; <ins><i>// optional</i></ins> +... +</pre></blockquote> + + + +<p><b>Rationale:</b></p> +Recommend NAD and fix as editorial with the proposed resolution. + + + + + +<hr> +<h3><a name="554"></a>554. Problem with lwg DR 184 numeric_limits<bool></h3> +<p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I believe we have a bug in the resolution of: +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a> +(WP status). +</p> + +<p> +The resolution spells out each member of <tt>numeric_limits<bool></tt>. +The part I'm having a little trouble with is: +</p> +<blockquote><pre>static const bool traps = false; +</pre></blockquote> + +<p> +Should this not be implementation defined? Given: +</p> + +<blockquote><pre>int main() +{ + bool b1 = true; + bool b2 = false; + bool b3 = b1/b2; +} +</pre></blockquote> + +<p> +If this causes a trap, shouldn't <tt>numeric_limits<bool>::traps</tt> be +<tt>true</tt>? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 18.2.1.5p3: +</p> + +<blockquote><p> +-3- The specialization for <tt>bool</tt> shall be provided as follows: </p> +<blockquote><pre>namespace std { + template <> class numeric_limits<bool> { + ... + static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>; + ... + }; +} +</pre></blockquote> +</blockquote> + +<p><i>[ +Redmond: NAD because traps refers to values, not operations. There is no bool +value that will trap. +]</i></p> + + + + + + + +<hr> +<h3><a name="555"></a>555. TR1, 8.21/1: typo</h3> +<p><b>Section:</b> TR1 8.21 [tr.c99.boolh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-02</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +This one, if nobody noticed it yet, seems really editorial: +s/cstbool/cstdbool/ +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 8.21p1: +</p> +<blockquote><p> +-1- The header behaves as if it defines the additional macro defined in +<tt><cst<ins>d</ins>bool></tt> by including the header <tt><cstdbool></tt>. +</p></blockquote> + +<p><i>[ +Redmond: Editorial. +]</i></p> + + + + + + + +<hr> +<h3><a name="557"></a>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3> +<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I'm seeing a problem with such overloads: when, _Longlong == intmax_t == +long long we end up, essentially, with the same arguments and different +return types (lldiv_t and imaxdiv_t, respectively). Similar issue with +abs(_Longlong) and abs(intmax_t), of course. +</p> +<p> +Comparing sections 8.25 and 8.11, I see an important difference, +however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong +types (rightfully, because not moved over directly from C99), whereas +there is no equivalent in 8.11: the abs and div overloads for intmax_t +types appear only in the synopsis and are not described anywhere, in +particular no mention in 8.11.2 (at variance with 8.25.2). +</p> +<p> +I'm wondering whether we really, really, want div and abs for intmax_t... +</p> + + + +<p><b>Proposed resolution:</b></p> + + + +<p><i>[ +Portland: no consensus. +]</i></p> + + +<p><b>Rationale:</b></p> +<p><i>[ +Batavia, Bill: The <tt><cstdint></tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains: +]</i></p> + +<blockquote><pre>intmax_t imaxabs(intmax_t i); +intmax_t abs(intmax_t i); + +imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); +imaxdiv_t div(intmax_t numer, intmax_t denom); +</pre></blockquote> + +<p><i>[ +and in TR1 8.11.2 [tr.c99.cinttypes.def]: +]</i></p> + + +<blockquote><p> +The header defines all functions, types, and macros the same as C99 +subclause 7.8. +</p></blockquote> + +<p><i>[ +This is as much definition as we give for most other C99 functions, +so nothing need change. We might, however, choose to add the footnote: +]</i></p> + + +<blockquote><p> +[<i>Note:</i> These overloads for <tt>abs</tt> and <tt>div</tt> may well be equivalent to +those that take <tt>long long</tt> arguments. If so, the implementation is +responsible for avoiding conflicting declarations. -- <i>end note</i>] +</p></blockquote> + +<p><i>[ +Bellevue: NAD Editorial. Pete must add a footnote, as described below. +]</i></p> + + +<blockquote> +<p><i>[ +Looks like a real problem. Dietmar suggests div() return a template +type. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedef +for lldiv_t when _Longlong == intmax_t? PJP seems to agree. We would +need a non-normative note declaring that the types lldiv_t and imaxdiv_t +may not be unique if intmax_t==_longlong. +]</i></p> + +</blockquote> + + + + + + +<hr> +<h3><a name="558"></a>558. lib.input.iterators Defect</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#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> David Abrahams <b>Date:</b> 2006-02-09</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<blockquote> +<p> + 24.1.1 Input iterators [lib.input.iterators] +</p> +<p> + 1 A class or a built-in type X satisfies the requirements of an + input iterator for the value type T if the following expressions are + valid, where U is the type of any specified member of type T, as + shown in Table 73. +</p> +</blockquote> +<p> +There is no capital U used in table 73. There is a lowercase u, but +that is clearly not meant to denote a member of type T. Also, there's +no description in 24.1.1 of what lowercase a means. IMO the above +should have been...Hah, a and b are already covered in 24.1/11, so maybe it +should have just been: +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 24.1.1p1: +</p> +<blockquote><p> +-1- A class or a built-in type <tt>X</tt> satisfies the requirements of an +input iterator for the value type <tt>T</tt> if the following expressions +are valid<del>, where <tt>U</tt> is the type of any specified member of type +<tt>T</tt>,</del> as shown in Table 73. +</p></blockquote> + +<p><i>[ +Portland: Editorial. +]</i></p> + + + + + + + +<hr> +<h3><a name="560"></a>560. User-defined allocators without default constructor</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#NAD">NAD</a> + <b>Submitter:</b> Sergey P. Derevyago <b>Date:</b> 2006-02-17</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<h4>1. The essence of the problem.</h4> +<p> +User-defined allocators without default constructor are not explicitly +supported by the standard but they can be supported just like std::vector +supports elements without default constructor. +</p> +<p> +As a result, there exist implementations that work well with such allocators +and implementations that don't. +</p> + +<h4>2. The cause of the problem.</h4> +<p> +1) The standard doesn't explicitly state this intent but it should. In +particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator +instances that compare non-equal. So it can similarly state the intent w.r.t. +the user-defined allocators without default constructor. +</p> +<p> +2) Some container operations are obviously underspecified. In particular, +21.3.7.1p2 tells: +</p> +<blockquote><pre>template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator> operator+( + const charT* lhs, + const basic_string<charT,traits,Allocator>& rhs + ); +</pre> +<p> +Returns: <tt>basic_string<charT,traits,Allocator>(lhs) + rhs</tt>. +</p> +</blockquote> +<p> +That leads to the basic_string<charT,traits,Allocator>(lhs, Allocator()) call. +Obviously, the right requirement is: +</p> +<blockquote><p> +Returns: <tt>basic_string<charT,traits,Allocator>(lhs, rhs.get_allocator()) + rhs</tt>. +</p></blockquote> +<p> +It seems like a lot of DRs can be submitted on this "Absent call to +get_allocator()" topic. +</p> + +<h4>3. Proposed actions.</h4> +<p> +1) Explicitly state the intent to allow for user-defined allocators without +default constructor in 20.1.5 Allocator requirements. +</p> +<p> +2) Correct all the places, where a correct allocator object is available +through the get_allocator() call but default Allocator() gets passed instead. +</p> +<h4>4. Code sample.</h4> +<p> +Let's suppose that the following memory pool is available: +</p> +<blockquote><pre>class mem_pool { + // ... + void* allocate(size_t size); + void deallocate(void* ptr, size_t size); +}; +</pre></blockquote> +<p> +So the following allocator can be implemented via this pool: +</p> +<blockquote><pre>class stl_allocator { + mem_pool& pool; + + public: + explicit stl_allocator(mem_pool& mp) : pool(mp) {} + stl_allocator(const stl_allocator& sa) : pool(sa.pool) {} + template <class U> + stl_allocator(const stl_allocator<U>& sa) : pool(sa.get_pool()) {} + ~stl_allocator() {} + + pointer allocate(size_type n, std::allocator<void>::const_pointer = 0) + { + return (n!=0) ? static_cast<pointer>(pool.allocate(n*sizeof(T))) : 0; + } + + void deallocate(pointer p, size_type n) + { + if (n!=0) pool.deallocate(p, n*sizeof(T)); + } + + // ... +}; +</pre></blockquote> +<p> +Then the following code works well on some implementations and doesn't work on +another: +</p> +<blockquote><pre>typedef basic_string<char, char_traits<char>, stl_allocator<char> > + tl_string; +mem_pool mp; +tl_string s1("abc", stl_allocator<int>(mp)); +printf("(%s)\n", ("def"+s1).c_str()); +</pre></blockquote> +<p> +In particular, on some implementations the code can't be compiled without +default stl_allocator() constructor. +</p> +<p> +The obvious way to solve the compile-time problems is to intentionally define +a NULL pointer dereferencing default constructor +</p> +<blockquote><pre>stl_allocator() : pool(*static_cast<mem_pool*>(0)) {} +</pre></blockquote> +<p> +in a hope that it will not be called. The problem is that it really gets +called by operator+(const char*, const string&) under the current 21.3.7.1p2 +wording. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + +<p><b>Rationale:</b></p> +<p> +Recommend NAD. <tt>operator+()</tt> with <tt>string</tt> already requires the desired +semantics of copying the allocator from one of the strings (<i>lhs</i> when there is a choice). +</p> + + + + + +<hr> +<h3><a name="569"></a>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</h3> +<p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> + <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-03-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a></p> +<p><b>Discussion:</b></p> +<p> +Section: 27.4.4.3 [lib.iostate.flags] +</p> +<p> +Paragraph 4 says: +</p> +<blockquote> +<blockquote><pre>void clear(iostate <i>state</i> = goodbit); +</pre></blockquote> +<p> +<i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt> +otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>. +</p> +</blockquote> + +<p> +The postcondition "rdstate()==state|ios_base::badbit" is parsed as +"(rdstate()==state)|ios_base::badbit", which is probably what the +committee meant. +</p> + + + + +<p><b>Rationale:</b></p> + + + + + + +<hr> +<h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</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#NAD">NAD</a> + <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Currently, the Standard Library specifies only a declaration for template class +char_traits<> and requires the implementation provide two explicit +specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard +should require explicit specializations for all built-in character types, i.e. +char, wchar_t, unsigned char, and signed char. +</p> +<p> +I have put together a paper +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>) +that describes this in more detail and +includes all the necessary wording. +</p> +<p><i>[ +Portland: Jack will rewrite +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a> +to propose a primary template that will work with other integral types. +]</i></p> + +<p><i>[ +Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>. +]</i></p> + + +<p><i>[ +post Bellevue: +]</i></p> + + +<blockquote> +<p> +We suggest that Jack be asked about the status of his paper, and if it +is not forthcoming, the work-item be assigned to someone else. If no one +steps forward to do the paper before the next meeting, we propose to +make this NAD without further discussion. We leave this Open for now, +but our recommendation is NAD. +</p> +<p> +Note: the issue statement should be updated, as the Toronto comment has +already been resolved. E.g., char_traits specializations for char16_t +and char32_t are now in the working paper. +</p> +</blockquote> + +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="571"></a>571. Update C90 references to C99?</h3> +<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC +9899:1990, Programming languages - C. Should that be changed to ISO/IEC +9899:1999? +</p> +<p> +What impact does this have on the library? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 1.2/1 [intro.refs] of the WP, change: +</p> +<blockquote> +<ul> +<li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i></li> +</ul> +</blockquote> + + + +<p><b>Rationale:</b></p> +Recommend NAD, fixed editorially. + + + + + +<hr> +<h3><a name="572"></a>572. Oops, we gave 507 WP status</h3> +<p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-04-11</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot: +variate_generator has been eliminated. Then in full committee we voted to give +this issue WP status (mistakenly). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Strike the proposed resolution of issue 507. +</p> +<p><i>[ +post-Portland: Walter and Howard recommend NAD. The proposed resolution of 507 no longer +exists in the current WD. +]</i></p> + + + +<p><b>Rationale:</b></p> +<p> +NAD. Will be moot once +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf">N2135</a> +is adopted. +</p> + + + + + +<hr> +<h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</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#NAD">NAD</a> + <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2006-06-13</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +See +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a> +for full discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Option 1: +</p> + +<p> +The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an +iterator. This is, however, in contrast with the equivalent requirements for other +standard containers. +</p> + +<p> +Option 2: +</p> + +<p> +<tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested: +the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so +that +</p> + +<blockquote><pre>iterator q1=a.erase(q); +</pre></blockquote> + +<p> +works as expected, while +</p> + +<blockquote><pre>a.erase(q); +</pre></blockquote> + +<p> +does not ever invoke the conversion-to-iterator operator, thus avoiding the associated +computation. To allow this technique, some sections of TR1 along the line "return value +is an iterator..." should be changed to "return value is an unspecified object implicitly +convertible to an iterator..." Although this trick is expected to work transparently, it can +have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic +code. +</p> + + + +<p><b>Rationale:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a> +was discussed in Portland and the consensus was that there appears to be +no need for either change proposed in the paper. The consensus opinion +was that since the iterator could serve as its own proxy, there appears +to be no need for the change. In general, "converts to" is undesirable +because it interferes with template matching. +</p> + +<p> +Post Toronto: There does not at this time appear to be consensus with the Portland consensus. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +The Bellevue review of this issue reached consensus with the Portland +consensus, in contravention of the Toronto non-consensus. Common +implementations have the iterator readily available, and most common +uses depend on the iterator being returned. +</blockquote> + + + + + + +<hr> +<h3><a name="583"></a>583. div() for unsigned integral types</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +There is no div() function for unsigned integer types. +</p> +<p> +There are several possible resolutions. The simplest one is noted below. Other +possibilities include a templated solution. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to 26.7 [lib.c.math] paragraph 8: +</p> + +<blockquote><pre>struct udiv_t div(unsigned, unsigned); +struct uldiv_t div(unsigned long, unsigned long); +struct ulldiv_t div(unsigned long long, unsigned long long); +</pre></blockquote> + + + +<p><b>Rationale:</b></p> +Toronto: C99 does not have these unsigned versions because +the signed version exist just to define the implementation-defined behavior +of signed integer division. Unsigned integer division has no implementation-defined +behavior and thus does not need this treatment. + + + + + +<hr> +<h3><a name="584"></a>584. missing int pow(int,int) functionality</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +There is no pow() function for any integral type. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add something like: +</p> + +<blockquote><pre>template< typename T> +T power( T x, int n ); +// requires: n >=0 +</pre></blockquote> + + +<p><b>Rationale:</b></p> +Toronto: We already have double pow(integral, integral) from 26.7 [c.math] p11. + + + + + +<hr> +<h3><a name="587"></a>587. iststream ctor missing description</h3> +<p><b>Section:</b> D.7.2.1 [depr.istrstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The <code>iststream(char*, streamsize)</code> ctor is in the class +synopsis in D.7.2 but its signature is missing in the description +below (in D.7.2.1). + + </p> + + + <p><b>Proposed resolution:</b></p> + <p> + +This seems like a simple editorial issue and the missing signature can +be added to the one for <code>const char*</code> in paragraph 2. + + </p> + +<p><i>[ +post Oxford: Noted that it is already fixed in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a> +]</i></p> + + + + + + +<hr> +<h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3> +<p><b>Section:</b> 20.5 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-08-10</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +20.4.9 [lib.meta.req], Implementation requirements, provides latitude for type +traits implementers that is not needed in C++0x. It includes the wording: +</p> + +<blockquote><p> +[<i>Note:</i> the latitude granted to implementers in this clause is temporary, +and is expected to be removed in future revisions of this document. -- <i>end note</i>] +</p></blockquote> + +<p> +Note: +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">N2157: Minor Modifications to the type traits Wording</a> +also has the intent of removing this wording from the WP. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Remove 20.4.9 [lib.meta.req] in its entirety from the WP. +</p> + +<p><i>[ +post-Oxford: Recommend NAD Editorial. This resolution is now in the +current working draft. +]</i></p> + + + + + + + +<hr> +<h3><a name="591"></a>591. Misleading "built-in</h3> +<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> whyglinux <b>Date:</b> 2006-08-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +18.2.1.2 numeric_limits members [lib.numeric.limits.members] +Paragraph 7: +</p> +<blockquote><p> +"For built-in integer types, the number of non-sign bits in the +representation." +</p></blockquote> + +<p> +26.1 Numeric type requirements [lib.numeric.requirements] +Footnote: +</p> + +<blockquote><p> +"In other words, value types. These include built-in arithmetic types, +pointers, the library class complex, and instantiations of valarray for +value types." +</p></blockquote> + +<p> +Integer types (which are bool, char, wchar_t, and the signed and +unsigned integer types) and arithmetic types (which are integer and +floating types) are all built-in types and thus there are no +non-built-in (that is, user-defined) integer or arithmetic types. Since +the redundant "built-in" in the above 2 sentences can mislead that +there may be built-in or user-defined integer and arithmetic types +(which is not correct), the "built-in" should be removed. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +18.2.1.2 numeric_limits members [lib.numeric.limits.members] +Paragraph 7: +</p> +<blockquote><p> +"For <del>built-in</del> integer types, the number of non-sign bits in the +representation." +</p></blockquote> + +<p> +26.1 Numeric type requirements [lib.numeric.requirements] +Footnote: +</p> + +<blockquote><p> +"In other words, value types. These include <del>built-in</del> arithmetic types, +pointers, the library class complex, and instantiations of valarray for +value types." +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p> +Recommend NAD / Editorial. The proposed resolution is accepted as editorial. +</p> + + + + + +<hr> +<h3><a name="592"></a>592. Incorrect treatment of rdbuf()->close() return type</h3> +<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 2006-08-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I just spotted a minor problem in 27.8.1.7 +[lib.ifstream.members] para 4 and also 27.8.1.13 +[lib.fstream.members] para 4. In both places it says: +</p> +<blockquote> +<pre>void close(); +</pre> +<p> +Effects: Calls rdbuf()->close() and, if that function returns false, ... +</p> +</blockquote> +<p> +However, basic_filebuf::close() (27.8.1.2) returns a pointer to the +filebuf on success, null on failure, so I think it is meant to +say "if that function returns a null pointer". Oddly, it is +correct for basic_ofstream. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 27.8.1.9 [ifstream.members], p5: +</p> + +<blockquote><p> +<i>Effects:</i> Calls <tt>rdbuf()->close()</tt> and, if that function +<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>, +calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt> +(27.4.4.3)). +</p></blockquote> + +<p> +Change 27.8.1.17 [fstream.members], p5: +</p> + +<blockquote><p> +<i>Effects:</i> Calls <tt>rdbuf()->close()</tt> and, if that function +<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>, +calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt> +(27.4.4.3)). +</p></blockquote> + + + +<p><i>[ +Kona (2007): Proposed Disposition: NAD, Editorial +]</i></p> + + + + + +<hr> +<h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</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#NAD%20Editorial">Pending NAD Editorial</a> + <b>Submitter:</b> Niels Dekker <b>Date:</b> 2006-11-02</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It seems undesirable to define the Swappable requirement in terms of +CopyConstructible and Assignable requirements. And likewise, once the +MoveConstructible and MoveAssignable requirements (N1860) have made it +into the Working Draft, it seems undesirable to define the Swappable +requirement in terms of those requirements. Instead, it appears +preferable to have the Swappable requirement defined exclusively in +terms of the existence of an appropriate swap function. +</p> +<p> +Section 20.1.4 [lib.swappable] of the current Working Draft (N2009) +says: +</p> +<blockquote><p> +The Swappable requirement is met by satisfying one or more of the +following conditions:</p> +<ul> +<li> +T is Swappable if T satisfies the CopyConstructible requirements +(20.1.3) and the Assignable requirements (23.1); +</li> +<li> +T is Swappable if a namespace scope function named swap exists in the +same namespace as the definition of T, such that the expression +swap(t,u) is valid and has the semantics described in Table 33. +</li> +</ul> +</blockquote> +I can think of three disadvantages of this definition: +<ol> +<li> +If a client's type T satisfies the first condition (T is both +CopyConstructible and Assignable), the client cannot stop T from +satisfying the Swappable requirement without stopping T from +satisfying the first condition. +<p> +A client might want to stop T from satisfying the Swappable +requirement, because swapping by means of copy construction and +assignment might throw an exception, and she might find a throwing +swap unacceptable for her type. On the other hand, she might not feel +the need to fully implement her own swap function for this type. In +this case she would want to be able to simply prevent algorithms that +would swap objects of type T from being used, e.g., by declaring a +swap function for T, and leaving this function purposely undefined. +This would trigger a link error, if an attempt would be made to use +such an algorithm for this type. For most standard library +implementations, this practice would indeed have the effect of +stopping T from satisfying the Swappable requirement. +</p> +</li> +<li> +A client's type T that does not satisfy the first condition can not be +made Swappable by providing a specialization of std::swap for T. +<p> +While I'm aware about the fact that people have mixed feelings about +providing a specialization of std::swap, it is well-defined to do so. +It sounds rather counter-intuitive to say that T is not Swappable, if +it has a valid and semantically correct specialization of std::swap. +Also in practice, providing such a specialization will have the same +effect as satisfying the Swappable requirement. +</p> +</li> +<li> +For a client's type T that satisfies both conditions of the Swappable +requirement, it is not specified which of the two conditions prevails. +After reading section 20.1.4 [lib.swappable], one might wonder whether +objects of T will be swapped by doing copy construction and +assignments, or by calling the swap function of T. +<p> +I'm aware that the intention of the Draft is to prefer calling the +swap function of T over doing copy construction and assignments. Still +in my opinion, it would be better to make this clear in the wording of +the definition of Swappable. +</p> +</li> +</ol> +<p> +I would like to have the Swappable requirement defined in such a way +that the following code fragment will correctly swap two objects of a +type T, if and only if T is Swappable: +</p> +<pre> using std::swap; + swap(t, u); // t and u are of type T. +</pre> +<p> +This is also the way Scott Meyers recommends calling a swap function, +in Effective C++, Third Edition, item 25. +</p> +<p> +Most aspects of this issue have been dealt with in a discussion on +comp.std.c++ about the Swappable requirement, from 13 September to 4 +October 2006, including valuable input by David Abrahams, Pete Becker, +Greg Herlihy, Howard Hinnant and others. +</p> + +<p><b>Proposed resolution:</b></p> +<p> +Change section 20.1.4 [lib.swappable] as follows: +</p> +<blockquote><p> +The Swappable requirement is met by satisfying +<del>one or more of the following conditions:</del> +<ins>the following condition:</ins></p> +<ul> + +<li> +<del>T is Swappable if T satisfies the CopyConstructible requirements +(20.1.3) and the Assignable requirements (23.1);</del> +</li> +<li> +<del> +T is Swappable if a namespace scope function named swap exists in the +same namespace as the definition of T, such that the expression +swap(t,u) is valid and has the semantics described in Table 33. +</del> +T is Swappable if an unqualified function call swap(t,u) is valid +within the namespace std, and has the semantics described in Table 33. +</li> +</ul> +</blockquote> + + +<p><b>Rationale:</b></p> +<p> +Recommend NAD. Concepts, specifically +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2082.pdf">N2082</a> +and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2084.pdf">N2084</a>, +will essentially rewrite this section and provide the desired semantics. +</p> + + + + + +<hr> +<h3><a name="615"></a>615. Inconsistencies in Section 21.4</h3> +<p><b>Section:</b> 21.5 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-11</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the current draft N2134, 21.4/1 says +</p> +<p> +"Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers <cctype>, +<cwctype>, <cstring>, <cwchar>, and <cstdlib> (character conversions), +respectively." +</p> +<p> +Here footnote 229 applies to table 62, not table 63. +</p> +<p> +Also, footnote 230 lists the new functions in table 63, "atoll, strtoll, +strtoull, strtof, and strtold added by TR1". However, strtof is not present +in table 63. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + +<p><b>Rationale:</b></p> +<p> +Recommend NAD, editorial. Send to Pete. +</p> + + + + + +<hr> +<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3> +<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +Many member functions of <code>basic_string</code> are overloaded, +with some of the overloads taking a <code>string</code> argument, +others <code>value_type*</code>, others <code>size_type</code>, and +others still <code>iterators</code>. Often, the requirements on one of +the overloads are expressed in the form of <i>Effects</i>, +<i>Throws</i>, and in the Working Paper +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>) +also <i>Remark</i> clauses, while those on the rest of the overloads +via a reference to this overload and using a <i>Returns</i> clause. + + </p><p> + </p> + +The difference between the two forms of specification is that per +17.3.1.3 [structure.specifications], p3, an <i>Effects</i> clause specifies +<i>"actions performed by the functions,"</i> i.e., its observable +effects, while a <i>Returns</i> clause is <i>"a description of the +return value(s) of a function"</i> that does not impose any +requirements on the function's observable effects. + + <p> + </p> + +Since only <i>Notes</i> are explicitly defined to be informative and +all other paragraphs are explicitly defined to be normative, like +<i>Effects</i> and <i>Returns</i>, the new <i>Remark</i> clauses also +impose normative requirements. + + <p> + </p> + +So by this strict reading of the standard there are some member +functions of <code>basic_string</code> that are required to throw an +exception under some conditions or use specific traits members while +many other otherwise equivalent overloads, while obliged to return the +same values, aren't required to follow the exact same requirements +with regards to the observable effects. + + <p> + </p> + +Here's an example of this problem that was precipitated by the change +from informative Notes to normative <i>Remark</i>s (presumably made to +address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>): + + <p> + </p> + +In the Working Paper, <code>find(string, size_type)</code> contains a +<i>Remark</i> clause (which is just a <i>Note</i> in the current +standard) requiring it to use <code>traits::eq()</code>. + + <p> + </p> + +<code>find(const charT *s, size_type pos)</code> is specified to +return <code>find(string(s), pos)</code> by a <i>Returns</i> clause +and so it is not required to use <code>traits::eq()</code>. However, +the Working Paper has replaced the original informative <i>Note</i> +about the function using <code>traits::length()</code> with a +normative requirement in the form of a <i>Remark</i>. Calling +<code>traits::length()</code> may be suboptimal, for example when the +argument is a very long array whose initial substring doesn't appear +anywhere in <code>*this</code>. + + <p> + </p> + +Here's another similar example, one that existed even prior to the +introduction of <i>Remark</i>s: + + <p> + </p> + +<code> insert(size_type pos, string, size_type, size_type)</code> is +required to throw <code>out_of_range</code> if <code>pos > +size()</code>. + + <p> + </p> + +<code>insert(size_type pos, string str)</code> is specified to return +<code>insert(pos, str, 0, npos)</code> by a <i>Returns</i> clause and +so its effects when <code>pos > size()</code> are strictly speaking +unspecified. + + + <p> + +I believe a careful review of the current <i>Effects</i> and +<i>Returns</i> clauses is needed in order to identify all such +problematic cases. In addition, a review of the Working Paper should +be done to make sure that the newly introduced normative <i>Remark</i> +clauses do not impose any undesirable normative requirements in place +of the original informative <i>Notes</i>. + + </p> +<p><i>[ +Batavia: Alan and Pete to work. +]</i></p> + + +<p><i>[ +Bellevue: Marked as NAD Editorial. +]</i></p> + + +<p><i>[ +Post-Sophia Antipolis: Martin indicates there is still work to be done on this issue. +Reopened. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3> +<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The <i>Remark</i> clauses newly introduced into the Working Paper +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>) +are not mentioned in 17.3.1.3 [structure.specifications] where we list the +meaning of <i>Effects</i>, <i>Requires</i>, and other clauses (with +the exception of <i>Notes</i> which are documented as informative in +17.3.1.1 [structure.summary], p2, and which they replace in many cases). + + </p> + <p> + +Propose add a bullet for <i>Remarks</i> along with a brief description. + + </p> +<p><i>[ +Batavia: Alan and Pete to work. +]</i></p> + + +<p><i>[ +Bellevue: Already resolved in current working paper. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="627"></a>627. Low memory and exceptions</h3> +<p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-01-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I recognize the need for nothrow guarantees in the exception reporting +mechanism, but I strongly believe that implementors also need an escape hatch +when memory gets really low. (Like, there's not enough heap to construct and +copy exception objects, or not enough stack to process the throw.) I'd like to +think we can put this escape hatch in 18.5.1.1 [new.delete.single], +<tt>operator new</tt>, but I'm not sure how to do it. We need more than a +footnote, but the wording has to be a bit vague. The idea is that if +<tt>new</tt> can't allocate something sufficiently small, it has the right to +<tt>abort</tt>/call <tt>terminate</tt>/call <tt>unexpected</tt>. +</p> + +<p><i>[ +Bellevue: NAD. 1.4p2 specifies a program must behave correctly "within +its resource limits", so no further escape hatch is necessary. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3> +<p><b>Section:</b> 20.6.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +20.6.15.2.5 [func.wrap.func.targ], p4 says: +</p> +<blockquote><p> +<i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored +function target; otherwise a null pointer. +</p></blockquote> + +<ol> +<li> +There exists neither a type, a typedef <tt>type</tt>, nor member +function <tt>type()</tt> in class template function nor in the global or +<tt>std</tt> namespace. +</li> +<li> +Assuming that <tt>type</tt> should have been <tt>target_type()</tt>, +this description would lead to false results, if <tt>T = <i>cv</i> +void</tt> due to returns clause 20.6.15.2.5 [func.wrap.func.targ], p1. +</li> +</ol> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.6.15.2.5 [func.wrap.func.targ], p4: +</p> + +<blockquote><p> +<i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&& typeid(T) != +typeid(void)</ins></tt>, a pointer to the stored function target; +otherwise a null pointer. +</p></blockquote> + +<p><i>[ +Pete: Agreed. It's editorial, so I'll fix it. +]</i></p> + + + + + + + +<hr> +<h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3> +<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-11</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The signature of the const operator[] has been changed to return a const +reference. +</p> +<p> +The description in paragraph 1 still says that the operator returns by +value. +</p> +<p><i>[ +Pete recommends editorial fix. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-13</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +26.7 [c.math], paragraph 10 has long lists of added signatures for float and long double +functions. All the signatures have float/long double return values, which is +inconsistent with some of the double functions they are supposed to +overload. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.7 [c.math], paragraph 10, +</p> + +<blockquote><pre><del>float</del> <ins>int</ins> ilogb(float); +<del>float</del> <ins>long</ins> lrint(float); +<del>float</del> <ins>long</ins> lround(float); +<del>float</del> <ins>long long</ins> llrint(float); +<del>float</del> <ins>long long</ins> llround(float); + +<del>long double</del> <ins>int</ins> ilogb(long double); +<del>long double</del> <ins>long</ins> lrint(long double); +<del>long double</del> <ins>long</ins> lround(long double); +<del>long double</del> <ins>long long</ins> llrint(long double); +<del>long double</del> <ins>long long</ins> llround(long double); +</pre></blockquote> + + + + + +<hr> +<h3><a name="639"></a>639. Still problems with exceptions during streambuf IO</h3> +<p><b>Section:</b> 27.6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +There already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13 +from 14882:2003(E), namely <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>. +</p> + +<p> +Even with these proposed corrections, already maintained in N2134, +I have the feeling, that the current wording does still not properly +handle the "exceptional" situation. The combination of para 14 +</p> + +<blockquote><p> +"[..] Characters are extracted and inserted until +any of the following occurs: +</p> +<p> +[..] +</p> +<p> +- an exception occurs (in which case the exception is caught)." +</p></blockquote> + +<p> +and 15 +</p> + +<blockquote><p> +"If the function inserts no characters, it calls setstate(failbit), +which +may throw ios_base::failure (27.4.4.3). If it inserted no characters +because it caught an exception thrown while extracting characters +from *this and failbit is on in exceptions() (27.4.4.3), then the +caught +exception is rethrown." +</p></blockquote> + +<p> +both in N2134 seems to imply that any exception, which occurs +*after* at least one character has been inserted is caught and lost +for +ever. It seems that even if failbit is on in exceptions() rethrow is +not +allowed due to the wording "If it inserted no characters because it +caught an exception thrown while extracting". +</p> + +<p> +Is this behaviour by design? +</p> + +<p> +I would like to add that its output counterpart in 27.6.2.6.3 [ostream.inserters]/7-9 +(also +N2134) does not demonstrate such an exception-loss-behaviour. +On the other side, I wonder concerning several subtle differences +compared to input:: +</p> +<p> +1) Paragraph 8 says at its end: +</p> + +<blockquote><p> +"- an exception occurs while getting a character from sb." +</p></blockquote> + +<p> +Note that there is nothing mentioned which would imply that such +an exception will be caught compared to 27.6.1.2.3 [istream::extractors]/14. +</p> + +<p> +2) Paragraph 9 says: +</p> + +<blockquote><p> +"If the function inserts no characters, it calls setstate(failbit) +(which +may throw ios_base::failure (27.4.4.3)). If an exception was thrown +while extracting a character, the function sets failbit in error +state, +and if failbit is on in exceptions() the caught exception is +rethrown." +</p></blockquote> + +<p> +The sentence starting with "If an exception was thrown" seems to +imply that such an exception *should* be caught before. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence +</p> + +<blockquote><p> +If the function inserts no characters, it calls +<tt>setstate(failbit)</tt>, which may throw <tt>ios_base::failure</tt> +(27.4.4.3). If <del>it inserted no characters because it caught an +exception thrown while extracting characters from <tt>*this</tt></del> +<ins>an exception was thrown while extracting a character from +<tt>*this</tt>, the function sets <tt>failbit</tt> in error state,</ins> +and <tt>failbit</tt> is on in <tt>exceptions()</tt> (27.4.4.3), then the +caught exception is rethrown. +</p></blockquote> + +<p> +(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence: +</p> + +<blockquote> +<p> +Gets characters from <tt>sb</tt> and inserts them in <tt>*this</tt>. +Characters are read from <tt>sb</tt> and inserted until any of the +following occurs: +</p> +<ul> +<li>end-of-file occurs on the input sequence;</li> +<li>inserting in the output sequence fails (in which case the character to be inserted is not extracted);</li> +<li>an exception occurs while getting a character from <tt>sb</tt> <ins>(in which +case the exception is caught)</ins>.</li> +</ul> +</blockquote> + + + +<p><b>Rationale:</b></p> +This extractor is described as a formatted input function so the +exception behavior is already specified. There is additional behavior +described in this section that applies to the case in which failbit is +set. This doesn't contradict the usual exception behavior for formatted +input functions because that applies to the case in which badbit is set. + + + + + +<hr> +<h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</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#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-18</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The function <tt>f</tt> in para 4 (27.6.4 [ext.manip]) references an unknown <tt>strm</tt> +in the following line: +</p> + +<blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon); +</pre></blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 27.6.4 [ext.manip], p4: +</p> + +<blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon); +</pre></blockquote> + +<p><i>[ +Oxford: Editorial. +]</i></p> + + + + + + + +<hr> +<h3><a name="642"></a>642. Invalidated fstream footnotes in N2134</h3> +<p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The standard wording of N2134 has extended the 14882:2003(E) +wording for the ifstream/ofstream/fstream open function to fix +a long standing problem, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>. +</p> + +<p> +Now it's properly written as +</p> + +<blockquote><p> +"If that function does not return a null pointer calls clear(), +otherwise +calls setstate(failbit)[..]" +</p></blockquote> + +<p> +instead of the previous +</p> + +<blockquote><p> +"If that function returns a null pointer, calls setstate(failbit)[..] +</p></blockquote> + +<p> +While the old footnotes saying +</p> + +<blockquote><p> +"A successful open does not change the error state." +</p></blockquote> + +<p> +where correct and important, they are invalid now for ifstream and +ofstream (because clear *does* indeed modify the error state) and +should be removed (Interestingly fstream itself never had these, +although +they where needed for that time). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 27.8.1.9 [ifstream.members], remove footnote: +</p> + +<blockquote><p> +<del><sup>334)</sup> A successful open does not change the error state.</del> +</p></blockquote> + +<p> +In 27.8.1.13 [ofstream.members], remove footnote: +</p> + +<blockquote><p> +<del><sup>335)</sup> A successful open does not change the error state.</del> +</p></blockquote> + + + + + + +<hr> +<h3><a name="645"></a>645. Missing members in match_results</h3> +<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +According to the description given in 28.10 [re.results]/2 the class template +match_results "shall satisfy the requirements of a Sequence, [..], +except that only operations defined for const-qualified Sequences +are supported". +Comparing the provided operations from 28.10 [re.results]/3 with the +sequence/container tables 80 and 81 one recognizes the following +missing operations: +</p> + +<p> +1) The members +</p> + +<blockquote><pre>const_iterator rbegin() const; +const_iterator rend() const; +</pre></blockquote> + +<p> +should exists because 23.1/10 demands these for containers +(all sequences are containers) which support bidirectional +iterators. Aren't these supported by match_result? This is not +explicitely expressed, but it's somewhat implied by two arguments: +</p> +<p> +(a) Several typedefs delegate to +<tt>iterator_traits<BidirectionalIterator></tt>. +</p> +<p> +(b) The existence of <tt>const_reference operator[](size_type n) const</tt> +implies even random-access iteration. +I also suggest, that <tt>match_result</tt> should explicitly mention, +which minimum iterator category is supported and if this does +not include random-access the existence of <tt>operator[]</tt> is +somewhat questionable. +</p> +<p> +2) The new "convenience" members +</p> +<blockquote><pre>const_iterator cbegin() const; +const_iterator cend() const; +const_iterator crbegin() const; +const_iterator crend() const; +</pre></blockquote> +<p> +should be added according to tables 80/81. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results] +para 3: +</p> + +<blockquote><pre>const_iterator cbegin() const; +const_iterator cend() const; +</pre></blockquote> + +<p> +In section 28.10.3 [re.results.acc] change: +</p> + +<blockquote> +<pre>const_iterator begin() const; +<ins>const_iterator cbegin() const;</ins> +</pre> +<blockquote> +<p> +-7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>. +</p> +</blockquote> + +<pre>const_iterator end() const; +<ins>const_iterator cend() const;</ins> +</pre> +<blockquote> +<p> +-8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>. +</p> +</blockquote> +</blockquote> + + + +<p><i>[ +Kona (2007): Voted to adopt proposed wording in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a> +except removing the entry in the table container requirements. Moved to Review. +]</i></p> + + +<p><i>[ +Bellevue: Proposed wording now in the WP. +]</i></p> + + + + + +<hr> +<h3><a name="647"></a>647. Inconsistent regex_search params</h3> +<p><b>Section:</b> 28.11.3 [re.alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +28.11.3 [re.alg.search]/5 declares +</p> + +<blockquote><pre>template <class iterator, class charT, class traits> +bool regex_search(iterator first, iterator last, + const basic_regex<charT, traits>& e, + regex_constants::match_flag_type flags = + regex_constants::match_default); +</pre></blockquote> + +<p> +where it's not explained, which iterator category +the parameter iterator belongs to. This is inconsistent +to the preceding declaration in the synopsis section +28.4 [re.syn], which says: +</p> + +<blockquote><pre>template <class BidirectionalIterator, class charT, class traits> +bool regex_search(BidirectionalIterator first, BidirectionalIterator last, + const basic_regex<charT, traits>& e, + regex_constants::match_flag_type flags = + regex_constants::match_default); +</pre></blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with +"BidirectionalIterator" +</p> + +<blockquote><pre>template <class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits> + bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last, + const basic_regex<charT, traits>& e, + regex_constants::match_flag_type flags = + regex_constants::match_default); +</pre> +<p> +-6- <i>Effects:</i> Behaves "as if" by constructing an object what of +type <tt>match_results<<del>iterator</del> +<ins>BidirectionalIterator</ins>></tt> and then returning the result +of <tt>regex_search(first, last, what, e, flags)</tt>. +</p> +</blockquote> + + +<p><b>Rationale:</b></p> +Applied to working paper while issue was still in New status. + + + + + +<hr> +<h3><a name="648"></a>648. regex_iterator c'tor needs clarification/editorial fix</h3> +<p><b>Section:</b> 28.12.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with: +</p> + +<blockquote> +<p> +<i>Effects:</i> Initializes begin and end to point to the beginning and the +end of the target sequence, sets pregex to &re, sets flags to f,[..] +</p></blockquote> + +<p> +There are two issues with this description: +</p> + +<ol> +<li> +The meaning of very first part of this quote is unclear, because +there is no target sequence provided, instead there are given two +parameters a and b, both of type BidirectionalIterator. The mentioned +part does not explain what a and b represent. +</li> +<li> +There does not exist any parameter f, but instead a parameter +m in the constructor declaration, so this is actually an editorial +fix. +</li> +</ol> + + +<p><b>Proposed resolution:</b></p> +<p> +In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by +</p> + +<blockquote><p> +<i>Effects:</i> Initializes <tt>begin</tt> and <tt>end</tt> to point to +the beginning and the end of the target sequence <ins>designated by the +iterator range <tt>[a, b)</tt></ins>, sets <tt>pregex</tt> to +<tt>&re</tt>, sets <tt>flags</tt> to <tt><del>f</del> +<ins>m</ins></tt>, then calls <tt>regex_search(begin, end, match, +*pregex, flags)</tt>. If this call returns <tt>false</tt> the +constructor sets <tt>*this</tt> to the end-of-sequence iterator. +</p></blockquote> + + + + + +<hr> +<h3><a name="649"></a>649. Several typos in regex_token_iterator constructors</h3> +<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration +and the following text shows some obvious typos: +</p> +<p> +1) The third constructor form is written as +</p> +<blockquote><pre>template <std::size_t N> + regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, + const regex_type& re, + const int (&submatches)[R], + regex_constants::match_flag_type m = + regex_constants::match_default); +</pre></blockquote> + +<p> +where the dimensions of submatches are specified by an +unknown value R, which should be N. +</p> +<p> +2) Paragraph 2 of the same section says in its last sentence: +</p> + +<blockquote><p> +The third constructor initializes the member <tt>subs</tt> to hold a +copy of the sequence of integer values pointed to by the iterator range +<tt>[&submatches, &submatches + R)</tt>. +</p></blockquote> + +<p> +where again R must be replaced by N. +</p> + +<p> +3) Paragraph 3 of the same section says in its first sentence: +</p> + +<blockquote><p> +Each constructor then sets <tt>N</tt> to <tt>0</tt>, and +<tt>position</tt> to <tt>position_iterator(a, b, re, f)</tt>. +</p></blockquote> + +<p> +where a non-existing parameter "f" is mentioned, which must be +replaced +by the parameter "m". +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 28.12.2.1 [re.tokiter.cnstr]/1: +</p> +<blockquote><pre>template <std::size_t N> + regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, + const regex_type& re, + const int (&submatches)[<del>R</del> <ins>N</ins>], + regex_constants::match_flag_type m = + regex_constants::match_default); +</pre></blockquote> + +<p> +Change 28.12.2.1 [re.tokiter.cnstr]/2: +</p> + +<blockquote><p> +<i>Effects:</i> The first constructor initializes the member +<tt>subs</tt> to hold the single value <tt>submatch</tt>. The second +constructor initializes the member <tt>subs</tt> to hold a copy of the +argument <tt>submatches</tt>. The third constructor initializes the +member <tt>subs</tt> to hold a copy of the sequence of integer values +pointed to by the iterator range <tt>[&submatches, &submatches + +<del>R</del> <ins>N</ins>)</tt>. +</p></blockquote> + +<p> +Change 28.12.2.1 [re.tokiter.cnstr]/3: +</p> + +<blockquote><p> +Each constructor then sets <tt>N</tt> to <tt>0</tt>, and +<tt>position</tt> to <tt>position_iterator(a, b, re, <del>f</del> +<ins>m</ins>)</tt>. If <tt>position</tt> is not an end-of-sequence +iterator the constructor sets <tt>result</tt> to the address of the +current match. Otherwise if any of the values stored in <tt>subs</tt> is +equal to <tt>-1</tt> the constructor sets <tt>*this</tt> to a suffix +iterator that points to the range <tt>[a, b)</tt>, otherwise the +constructor sets <tt>*this</tt> to an end-of-sequence iterator. +</p></blockquote> + + + + + + +<hr> +<h3><a name="653"></a>653. Library reserved names</h3> +<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-03-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +</p> +<blockquote> +<p> +1.2 [intro.refs] Normative references +</p> + +<p> +The following standards contain provisions which, through reference in +this text, constitute provisions of this Interna- tional Standard. At +the time of publication, the editions indicated were valid. All +standards are subject to revision, and parties to agreements based on +this International Standard are encouraged to investigate the +possibility of applying the most recent editions of the standards +indicated below. Members of IEC and ISO maintain registers of currently +valid International Standards. +</p> + +<ul> +<li>Ecma International, ECMAScript Language Specification, Standard +Ecma-262, third edition, 1999.</li> +<li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li> +<li>ISO/IEC 9899:1990, Programming languages - C</li> +<li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C +Integrity</li> +<li>ISO/IEC 9899:1999, Programming languages - C</li> +<li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li> +<li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li> +<li>ISO/IEC 9945:2003, Information Technology-Portable Operating System +Interface (POSIX)</li> +<li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet +Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual +Plane</li> +</ul> +</blockquote> + +<p> +I'm not sure how many of those reserve naming patterns that might affect +us, but I am equally sure I don't own a copy of any of these to check! +</p> +<p> +The point is to list the reserved naming patterns, rather than the +individual names themselves - although we may want to list C keywords +that are valid identifiers in C++ but likely to cause trouble in shared +headers (e.g. restrict) +</p> + +<p><i>[ +Kona (2007): Recommend NAD. No one has identified a specific defect, just the possibility of one. +]</i></p> + + +<p><i>[ +Post-Kona: Alisdair request Open. A good example of the problem was a +discussion of the system error proposal, where it was pointed out an all-caps +identifier starting with a capital E conflicted with reserved macro names for +both Posix and C. I had absolutely no idea of this rule, and suspect I was +not the only one in the room.<br> +<br> +Resolution will require someone with access to all the listed documents to +research their respective name reservation rules, or people with access to +specific documents add their rules to this issue until the list is complete. +]</i></p> + + +<p><i>[ +Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording. +Suggest a formal paper rather than a defect report is the correct way to proceed. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="656"></a>656. Typo in subtract_with_carry_engine declaration</h3> +<p><b>Section:</b> 26.4.2 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +26.4.2 [rand.synopsis] the header <tt><random></tt> synopsis +contains an unreasonable closing curly brace inside the +<tt>subtract_with_carry_engine</tt> declaration. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the current declaration in 26.4.2 [rand.synopsis] +</p> + +<blockquote><pre>template <class UIntType, size_t w<del>}</del>, size_t s, size_t r> +class subtract_with_carry_engine; +</pre></blockquote> + + +<p><i>[ +Pete: Recommends editorial. +]</i></p> + + + + + +<hr> +<h3><a name="657"></a>657. unclear requirement about header inclusion</h3> +<p><b>Section:</b> 17.4.2.1 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2007-03-14</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +17.4.2.1 [using.headers] states: +</p> + +<blockquote><p> +A translation unit shall include a header only outside of any +external declaration or definition, [...] +</p></blockquote> + +<p> +I see three problems with this requirement: +</p> + +<ol type="a"> +<li><p>The C++ standard doesn't define what an "external declaration" or +an "external definition" are (incidentally the C99 standard does, and +has a sentence very similar to the above regarding header inclusion). +</p><p> +I think the intent is that the #include directive shall lexically +appear outside *any* declaration; instead, when the issue was pointed +out on comp.std.c++ at least one poster interpreted "external +declaration" as "declaration of an identifier with external linkage". +If this were the correct interpretation, then the two inclusions below +would be legal: +</p> +<blockquote><pre> // at global scope + static void f() + { +# include <cstddef> + } + + static void g() + { +# include <stddef.h> + } +</pre></blockquote> +<p> +(note that while the first example is unlikely to compile correctly, +the second one may well do) +</p></li> + +<li><p>as the sentence stands, violations will require a diagnostic; is +this the intent? It was pointed out on comp.std.c++ (by several +posters) that at least one way to ensure a diagnostic exists: +</p> +<blockquote><p> + [If there is an actual file for each header,] one simple way + to implement this would be to insert a reserved identifier + such as __begin_header at the start of each standard header. + This reserved identifier would be ignored for all other + purposes, except that, at the appropriate point in phase 7, if + it is found inside an external definition, a diagnostic is + generated. There's many other similar ways to achieve the same + effect. + </p> +<p> --James Kuyper, on comp.std.c++ +</p></blockquote></li> + +<li><p>is the term "header" meant to be limited to standard headers? +Clause 17 is all about the library, but still the general question is +interesting and affects one of the points in the explicit namespaces +proposal (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html">n1691</a>): +</p> +<blockquote><p> + Those seeking to conveniently enable argument-dependent + lookups for all operators within an explicit namespace + could easily create a header file that does so: +</p><pre> namespace mymath:: + { + #include "using_ops.hpp" + } +</pre></blockquote> +</li> +</ol> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + +<p><b>Rationale:</b></p> +We believe that the existing language does not cause any real confusion +and any new formulation of the rules that we could come up with are +unlikely to be better than what's already in the standard. + + + + + +<hr> +<h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3> +<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-19</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The header <tt><functional></tt> synopsis in 20.6 [function.objects] +contains the following two free comparison operator templates +for the <tt>function</tt> class template +</p> + +<blockquote><pre>template<class Function1, class Function2> +void operator==(const function<Function1>&, const function<Function2>&); +template<class Function1, class Function2> +void operator!=(const function<Function1>&, const function<Function2>&); +</pre></blockquote> + +<p> +which are nowhere described. I assume that they are relicts before the +corresponding two private and undefined member templates in the function +template (see 20.6.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free +function templates should be removed, because using an undefined entity +would lead to an ODR violation of the user. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Remove the above mentioned two function templates from +the header <tt><functional></tt> synopsis (20.6 [function.objects]) +</p> + +<blockquote><pre><del>template<class Function1, class Function2> +void operator==(const function<Function1>&, const function<Function2>&); +template<class Function1, class Function2> +void operator!=(const function<Function1>&, const function<Function2>&);</del> +</pre></blockquote> + + + +<p><b>Rationale:</b></p> +Fixed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a> +Standard Library Applications for Deleted Functions. + + + + + +<hr> +<h3><a name="662"></a>662. Inconsistent handling of incorrectly-placed thousands separators</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#NAD">NAD</a> + <b>Submitter:</b> Cosmin Truta <b>Date:</b> 2007-04-05</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +From Section 22.2.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied +that the value read from a stream must be stored +even if the placement of thousands separators does not conform to the +<code>grouping()</code> specification from the <code>numpunct</code> facet. +Since incorrectly-placed thousands separators are flagged as an extraction +failure (by the means of <code>failbit</code>), we believe it is better not +to store the value. A consistent strategy, in which any kind of extraction +failure leaves the input item intact, is conceptually cleaner, is able to avoid +corner-case traps, and is also more understandable from the programmer's point +of view. +</p> +<p> +Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i> +by B. Stroustrup (Section D.4.2.3, pg. 897): +</p> +<blockquote><p> +<i>"If a value of the desired type could not be read, failbit is set in r. +[...] An input operator will use r to determine how to set the state of its +stream. If no error was encountered, the value read is assigned through v; +otherwise, v is left unchanged."</i> +</p></blockquote> +<p> +This statement implies that <code>rdstate()</code> alone is sufficient to +determine whether an extracted value is to be assigned to the input item +<i>val</i> passed to <code>do_get</code>. However, this is in disagreement +with the current C++ Standard. The above-mentioned assumption is true in all +cases, except when there are mismatches in digit grouping. In the latter case, +the parsed value is assigned to <i>val</i>, and, at the same time, <i>err</i> +is assigned to <code>ios_base::failbit</code> (essentially "lying" about the +success of the operation). Is this intentional? The current behavior raises +both consistency and usability concerns. +</p> +<p> +Although digit grouping is outside the scope of <code>scanf</code> (on which +the virtual methods of <code>num_get</code> are based), handling of grouping +should be consistent with the overall behavior of scanf. The specification of +<code>scanf</code> makes a distinction between input failures and matching +failures, and yet both kinds of failures have no effect on the input items +passed to <code>scanf</code>. A mismatch in digit grouping logically falls in +the category of matching failures, and it would be more consistent, and less +surprising to the user, to leave the input item intact whenever a failure is +being signaled. +</p> +<p> +The extraction of <code>bool</code> is another example outside the scope of +<code>scanf</code>, and yet consistent, even in the event of a successful +extraction of a <code>long</code> but a failed conversion from +<code>long</code> to <code>bool</code>. +</p> +<p> +Inconsistency is further aggravated by the fact that, when failbit is set, +subsequent extraction operations are no-ops until <code>failbit</code> is +explicitly cleared. Assuming that there is no explicit handling of +<code>rdstate()</code> (as in <code>cin>>i>>j</code>) it is +counter-intuitive to be able to extract an integer with mismatched digit +grouping, but to be unable to extract another, properly-formatted integer +that immediately follows. +</p> +<p> +Moreover, setting <code>failbit</code>, and selectively assigning a value to +the input item, raises usability problems. Either the strategy of +<code>scanf</code> (when there is no extracted value in case of failure), or +the strategy of the <code>strtol</code> family (when there is always an +extracted value, and there are well-defined defaults in case of a failure) are +easy to understand and easy to use. On the other hand, if <code>failbit</code> +alone cannot consistently make a difference between a failed extraction, and a +successful but not-quite-correct extraction whose output happens to be the same +as the previous value, the programmer must resort to implementation tricks. +Consider the following example: +</p> +<pre> int i = old_i; + cin >> i; + if (cin.fail()) + // can the value of i be trusted? + // what does it mean if i == old_i? + // ... +</pre> +<p> +Last but not least, the current behvaior is not only confusing to the casual +reader, but it has also been confusing to some book authors. Besides +Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by +Langer and Kreft) are describing the same mistaken assumption. Although books +are not to be used instead of the standard reference, the readers of these +books, as well as the people who are generally familiar to <code>scanf</code>, +are even more likely to misinterpret the standard, and expect the input items +to remain intact when a failure occurs. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p> +Change 22.2.2.1.2 [facet.num.get.virtuals]: +</p> + +<blockquote> +<p> +<b>Stage 3:</b> The result of stage 2 processing can be one of +</p> +<ul> +<li>A sequence of <code>chars</code> has been accumulated in stage 2 that is converted (according to the rules of <code>scanf</code>) to a value of the type of <code><i>val</i></code>. <del>This value is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</del></li> + +<li>The sequence of <code>chars</code> accumulated in stage 2 would have caused <code>scanf</code> to report an input failure. <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.</li> +</ul> +<p> +<ins>In the first case,</ins> <del>D</del><ins>d</ins>igit grouping is checked. That is, the positions of discarded separators is examined for consistency with <code>use_facet<numpunct<charT> >(<i>loc</i>).grouping()</code>. If they are not consistent then <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>. <ins>Otherwise, the value that was converted in stage 2 is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</ins> +</p> +</blockquote> + + +<p><b>Rationale:</b></p> +post-Toronto: Changed from New to NAD at the request of the author. The preferred solution of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a> +makes this resolution obsolete. + + + + + +<hr> +<h3><a name="663"></a>663. Complexity Requirements</h3> +<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +17.3.1.3 [structure.specifications] para 5 says +</p> + +<blockquote><p> +-5- Complexity requirements specified in the library +clauses are upper bounds, and implementations that provide better +complexity guarantees satisfy the requirements. +</p></blockquote> + +<p> +The following +objection has been raised: +</p> + +<blockquote><p> +The library clauses suggest general +guidelines regarding complexity, but we have been unable to discover +any absolute hard-and-fast formulae for these requirements. Unless +or until the Library group standardizes specific hard-and-fast +formulae, we regard all the complexity requirements as subject to a +"fudge factor" without any intrinsic upper bound. +</p></blockquote> + +<p> +[Plum ref +_23213Y31 etc] +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + +<p><b>Rationale:</b></p> +Kona (2007): No specific instances of underspecification have been +identified, and big-O notation always involves constant factors. + + + + + +<hr> +<h3><a name="683"></a>683. regex_token_iterator summary error</h3> +<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> + <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +28.12.2 [re.tokiter], p3 says: +</p> +<blockquote> +<p> +After it is constructed, the iterator finds and stores a value +<tt>match_results<BidirectionalIterator></tt> position and sets the +internal count <tt>N</tt> to zero. +</p> +</blockquote> + +<p> +Should read: +</p> + +<blockquote> +<p> +After it is constructed, the iterator finds and stores a value +<tt><del>match_results</del><ins>regex_iterator</ins><BidirectionalIterator<ins>, charT, traits</ins>></tt> +position and sets the internal count <tt>N</tt> to zero. +</p> +</blockquote> + +<p><i>[ +John adds: +]</i></p> + + +<blockquote><p> +Yep, looks like a typo/administrative fix to me. +</p></blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3> +<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 28.4 [re.syn] of N2284, two template functions +are declared here: +</p> +<blockquote><pre>// 28.10, class template match_results: + <<i>snip</i>> +// match_results comparisons + template <class BidirectionalIterator, class Allocator> + bool operator== (const match_results<BidirectionalIterator, Allocator>& m1, + const match_results<BidirectionalIterator, Allocator>& m2); + template <class BidirectionalIterator, class Allocator> + bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1, + const match_results<BidirectionalIterator, Allocator>& m2); + +// 28.10.6, match_results swap: +</pre></blockquote> + +<p> +But the details of these two bool operator functions (i.e., which members of +<tt>match_results</tt> should be used in comparison) are not described in any +following sections. +</p> + +<p><i>[ +John adds: +]</i></p> + + +<blockquote><p> +That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if +the two objects refer to the same match - ie if one object was constructed as a +copy of the other. +</p></blockquote> + +<p><i>[ +Kona (2007): Bill and Pete to add minor wording to that proposed in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add a new section after 28.10.6 [re.results.swap], which reads: +</p> +<p> +28.10.7 match_results non-member functions. +</p> + +<blockquote> +<pre>template<class BidirectionalIterator, class Allocator> + bool operator==(const match_results<BidirectionalIterator, Allocator>& m1, + const match_results<BidirectionalIterator, Allocator>& m2); +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match. +</p> +</blockquote> +</blockquote> + +<blockquote> +<pre>template<class BidirectionalIterator, class Allocator> + bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1, + const match_results<BidirectionalIterator, Allocator>& m2); +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>!(m1 == m2)</tt>. +</p> +</blockquote> +</blockquote> + +<blockquote> +<pre>template<class BidirectionalIterator, class Allocator> + void swap(match_results<BidirectionalIterator, Allocator>& m1, + match_results<BidirectionalIterator, Allocator>& m2); +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>m1.swap(m2)</tt>. +</p> +</blockquote> +</blockquote> + + +<p><i>[ +Bellevue: Proposed wording now in WP. +]</i></p> + + + + + +<hr> +<h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3> +<p><b>Section:</b> 20.7.11.2.4 [unique.ptr.single.observers], 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#NAD">NAD</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-06-14</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in +five places. In three of those places (20.6.15.2.3 [func.wrap.func.cap], function capacity +for example) the returned value is constrained to disallow +unintended conversions to int. The standardese is +</p> +<blockquote><p> +The return type shall not be convertible to <tt>int</tt>. +</p></blockquote> +<p> +This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Close as NAD. Accepting paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a> +makes it irrelevant. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>() +const</tt> +of 20.7.11.2.4 [unique.ptr.single.observers] paragraph 11 and +20.7.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence: +</p> +<blockquote><p> +The return type shall not be convertible to <tt>int</tt>. +</p></blockquote> + + +<p><i>[ +Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue. +]</i></p> + + + + + +<hr> +<h3><a name="690"></a>690. abs(long long) should return long long</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-06-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Quoting the latest draft (n2135), 26.7 [c.math]: +</p> + +<blockquote> +<p> +The added signatures are: +</p> +<blockquote><pre>long abs(long); // labs() +long abs(long long); // llabs() +</pre></blockquote> +</blockquote> +<p> +Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.7 [c.math]: +</p> +<blockquote><pre><ins>long </ins>long abs(long long); // llabs() +</pre></blockquote> + + +<p><b>Rationale:</b></p> +Had already been fixed in the WP by the time the LWG reviewed this. + + + + + +<hr> +<h3><a name="697"></a>697. New <tt><system_error></tt> header leads to name clashes</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#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The most recent state of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a> +as well as the current draft +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a> +(section 19.4 [syserr], p.2) proposes a +new +enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of +the enumerators has the name <tt>invalid_argument</tt>, or fully qualified: +<tt>std::invalid_argument</tt>. This name clashes with the exception type +<tt>std::invalid_argument</tt>, see 19.1 [std.exceptions]/p.3. This clash makes +e.g. the following snippet invalid: +</p> + +<blockquote><pre>#include <system_error> +#include <stdexcept> + +void foo() { throw std::invalid_argument("Don't call us - we call you!"); } +</pre></blockquote> + +<p> +I propose that this enumeration type (and probably the remaining parts +of +<tt><system_error></tt> as well) should be moved into one additional inner +namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes +due +to the great number of members that <tt>std::posix_errno</tt> already contains +(Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a> +been rejected?). A further clash <em>candidate</em> seems to be +<tt>std::protocol_error</tt> +(a reasonable name for an exception related to a std network library, +I guess). +</p> + +<p> +Another possible resolution would rely on the proposed strongly typed +enums, +as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>. +But maybe the forbidden implicit conversion to integral types would +make +these enumerators less attractive in this special case? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm#Issue7">issue 7 of N2422</a>. +</p> + + + + + + +<hr> +<h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></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#NAD">NAD</a> + <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-07-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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +From the Toronto Core wiki: +</p> + +<p> +What do you mean by "null pointer constant"? How do you guarantee that +<tt>exception_ptr() == 1</tt> doesn't work? Do you even want to prevent that? +What's the semantics? What about <tt>void *p = 0; exception_ptr() == p</tt>? +Maybe disallow those in the interface, but how do you do that with +portable C++? Could specify just "make it work". +</p> + +<p> +Peter's response: +</p> + +<p> +null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it +work", can be implemented as assignment operator taking a unique pointer +to member, as in the unspecified bool type idiom. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool. +</p> +<p> +Even simpler now with nullptr_t. +</p> +<p> +NAD Rationale : null pointer constant is a perfectly defined term, and +while API is clearly implementable there is no need to spell out +implementation details. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3> +<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been +changed to <tt>const T&</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of +the section 26.5.2.3 [valarray.access] are now +incompletely +specified, because many requirements and guarantees should now also +apply to the const overload. Most notably, the address and reference +guarantees should be extended to the const overload case. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.5.2.3 [valarray.access]: +</p> + +<blockquote> +<p> +-1- <del>When applied to a constant array, the subscript operator returns a +reference to the corresponding element of the array. When applied to a +non-constant array, t</del><ins>T</ins>he subscript operator returns a +reference to the corresponding element of the array. +</p> + +<p> +-3- The expression <tt>&a[i+j] == &a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt> +and <tt>size_t j</tt> such that <tt>i+j</tt> is less +than the length of the <del>non-constant</del> array <tt>a</tt>. +</p> + +<p> +-4- Likewise, the expression <tt>&a[i] != &b[j]</tt> evaluates +as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and +<tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that +<tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less +than the length of <tt>b</tt>. This property indicates an absence of +aliasing and may be used to advantage by optimizing +compilers.<sup>281)</sup> +</p> + +<p> +-5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until +the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime +of that array ends, whichever happens first. +</p> + +</blockquote> + + + + + + +<hr> +<h3><a name="725"></a>725. Optional sequence container requirements column label</h3> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> + <b>Submitter:</b> David Abrahams <b>Date:</b> 2007-09-16</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Table 90: (Optional sequence container operations) states the +"assertion note pre/post-condition" of <tt>operator[]</tt> to be +</p> + +<blockquote><pre>*(a.begin() + n) +</pre></blockquote> + +<p> +Surely that's meant to be "operational semantics?" +</p> + + + +<p><b>Proposed resolution:</b></p> +<blockquote> +<table border="1"> +<caption>Table 90: Optional sequence container operations</caption> +<tbody><tr> +<th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th> +</tr> +</tbody></table> +</blockquote> + + + + + + +<hr> +<h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3> +<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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.req.eng">issues</a> in [rand.req.eng].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any +arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently +used for seeding the state of the engine. The requirement stated as "Creates an engine with +initial state determined by <tt>static_cast<X::result_type>(s)</tt>" forces random number engines +to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion +of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits +of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems +to be inappropriate for many modern random number generators, in particular F2-linear or +cryptographic ones, which operate on an internal bit array that in principle is independent of the +type of numbers returned. +</p> + +<p> +<b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an +engine with initial state determined by <tt>static_cast<UintType>(s)</tt>, where <tt>UintType</tt> is an +implementation specific unsigned integer type." +</p> + +<p> +Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types. +</p> + +<p> +Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified. +</p> + +<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>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> + + +<blockquote> +<p> +In reply to the discussion in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +regarding this issue: +</p> +<p> +The descriptions of all engines and engine adaptors given in sections +26.4.3 [rand.eng] and 26.4.4 [rand.adapt] already specify the concrete +types of the integer arguments for seeding. Hence, relaxing the general +requirement in 26.4.1.3 [rand.req.eng] would not affect portability and +reproducibility of the standard library. Furthermore, it is not clear to +me what exactly the guarantee "with initial state determined by +<tt>static_cast<X::result_type>(s)</tt>" is useful for. On the other hand, +relaxing the requirement would allow developers to implement other +random number engines that do not have to cast all arithmetic seed +arguments to their result_types. +</p> +</blockquote> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Propose close NAD for the reasons given in N2424. +</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 further discussion. +</p> + +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> + + +<blockquote> +<p> +Change row 3 of table 105 "Random number engine requirements" in 26.4.1.3 [rand.req.eng]/3 +</p> + +<blockquote> +Creates an engine with initial state determined by +<tt><del>static_cast<X::result_type>(</del>s<del>)</del></tt> +</blockquote> + +<p> +Similarly, change 26.4.1.4 [rand.req.adapt]/3 e) +</p> + +<blockquote> +When <tt>X::X</tt> is invoked with <del>an <tt>X::result_type</tt></del> value <tt>s</tt> +<ins>of arithmetic type (3.9.1)</ins>, ... +</blockquote> + +</blockquote> + + + + + + +<hr> +<h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3> +<p><b>Section:</b> 26.4.1.4 [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base +engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is +qualified as constant, this procedure will ef fectively initialize all base engines with the same seed +(though the resulting state might still dif fer to a certain degree if the engines are of different types). +It is not clear whether this mode of operation is in general appropriate, hence -- as far as the +stated requirements are of general nature and not just specific to the engine adaptors provided by +the library -- it might be better to leave the behaviour unspecified, since the current definition of +<tt>seed_seq</tt> does not allow for a generally satisfying specification. +</p> + +<p> +<b>Posssible resolution:</b> [As above] +</p> + +<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> +Close NAD for the reasons given in N2424. +</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="731"></a>731. proposal for a customizable <tt>seed_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#NAD">NAD</a> + <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The proper way to seed random number engines seems to be the most frequently +discussed issue of the 26.4 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather +general and probably sufficient for most situations, it is unlikely to be optimal in every case (one +problem was pointed out in point T5 above). In some situations it might, for instance, be better to +seed the state with a cryptographic generator. +</p> +<p> +In my opinion this is a pretty strong argument for extending the standard with a simple facility to +customize the seeding procedure. This could, for example, be done with the following minimal +changes: +</p> + +<p> +<b>Possible resolution:</b> +</p> + +<ol type="a"> +<li> +Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the +exact behaviour of the constructors and the randomize method are left unspecified and where the +const qualification for randomize is removed. Classes implementing this interface are additionally +required to specialize the traits class in c). +</li> +<li> +Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface. +</li> +<li> +<p> +Supplement the <tt>seed_seq</tt> with a traits class +</p> +<blockquote><pre>template <typename T> +struct is_seed_seq { static const bool value = false; } +</pre></blockquote> +<p>and the specialization</p> +<blockquote><pre>template <> +struct is_seed_seq<seed_seq> { static const bool value = true; } +</pre></blockquote> +<p>which users can supplement with further specializations.</p> +</li> +<li> +Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and +modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation +could be done using the SFINAE technique). +</li> +</ol> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +See N2424. Close NAD but note that "conceptizing" the library may cause +this problem to be solved by that route. +</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="733"></a>733. Comment on [rand.req.dist]/9</h3> +<p><b>Section:</b> 26.4.1.5 [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The requirement "P shall have a declaration of the form <tt>typedef X distribution_- +type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient, +because the child of a distribution class in general will not satisfy this requirement. In my opinion +the benefits of having a typedef in the parameter class pointing back to the distribution class are +not worth the hassle this requirement causes. [In my code base I never made use of the nested +typedef but on several occasions could have profited from being able to use simple inheritance for +the implementation of a distribution class.] +</p> + +<p> +<b>Proposed resolution:</b> I propose to drop this requirement. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements. +</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="735"></a>735. Unfortunate naming</h3> +<p><b>Section:</b> 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt> +is very unfortunate. In virtually every internet reference, book and software implementation +this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993) +Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926, +Mathematica and Matlab. +</p> + +<p> +Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual. +The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead. +</p> + +<p> +Choosing unusual names for the parameters causes confusion among users and makes the +interface unnecessarily inconvenient to use. +</p> + +<p> +<b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters +to <tt>n</tt> and <tt>r</tt>. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +In N2424. NAD It has been around for a while. It is hardly universal, +there is prior art, and this would confuse people. +</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="736"></a>736. Comment on [rand.dist.samp.discrete]</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#NAD">NAD</a> + <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<ol type="a"> +<li> +The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt> +to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to +divide each probability by the sum of all probabilities, as the sum will in practice almost never be +exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to +compute the standardized probabilities at all and could instead work with the non-standardized +probabilities and the sum. If there was no standardization the user would just get back the +probabilities that were previously supplied to the distribution object, which to me seems to be the +more obvious solution. +</li> +<li> +The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given +probabilities is larger than the maximum number representable by the IntType. +</li> +</ol> + +<p> +<b>Possible resolution:</b> I propose to change the specification such that the non-standardized +probabilities need to be returned and that an additional requirement is included for the number +of probabilities to be smaller than the maximum of IntType. +</p> + +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> + + +<blockquote> +<p> +In reply to the discussion in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +of this issue: +</p> +<p> +Rescaled floating-point parameter vectors can not be expected to compare +equal because of the limited precision of floating-point numbers. +My proposal would at least guarantee that a parameter +vector (of type double) passed into the distribution would compare equal +with the one returned by the <tt>probabilities()</tt> method. Furthermore, I do +not understand why "the changed requirement would lead to a significant +increase in the amount of state in the distribution object". A typical +implementation's state would increase by exactly one number: the sum of +all probabilities. The textual representation for serialization would +not need to grow at all. Finally, the proposed replacement "<tt>0 < n <= +numeric_limits<IntType>::max() + 1</tt>" makes the implementation +unnecessarily complicated, "<tt>0 < n <= numeric_limits<IntType>::max()</tt>" +would be better. +</p> +</blockquote> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +In N2424. We agree with the observation and the proposed resolution to +part b). We recommend the wording n > 0 be replaced with 0 < n +numeric_limits::max() + 1. However, we disagree with part a), as it +would interfere with the definition of parameters' equality. Further, +the changed requirement would lead to a significant increase in the +amount of state of the distribution object. +</p> + +<p> +As it stands now, it is convenient, and the changes proposed make it +much less so. +</p> + +<p> +NAD. Part a the current behavior is desirable. Part b, any constructor +can fail, but the rules under which it can fail do not need to be listed +here. +</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.5.1 [rand.dist.samp.discrete]: +</p> + +<p> +Proposed wording a): +</p> + +<blockquote> +<p> +Changae in para. 2 +</p> + +<blockquote> +Constructs a <tt>discrete_distribution</tt> object with <tt>n=1</tt> and <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt> +</blockquote> + +<p> +and change in para. 5 +</p> + +<blockquote> +<i>Returns:</i> A <tt>vector<double></tt> whose <tt>size</tt> member returns <tt>n</tt> and whose +<tt>operator[]</tt> member returns <del><tt>p<sub>k</sub></tt></del> +<ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins> +when invoked with argument <tt>k</tt> for <tt>k = 0, +..., n-1</tt> +</blockquote> + +</blockquote> + +<p> +Proposed wording b): +</p> + +<blockquote> +<p> +Change in para. 3: +</p> + +<blockquote> +If <tt>firstW == lastW</tt>, let the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist +of the single value <tt>w<sub>0</sub> = 1</tt>. Otherwise, <tt>[firstW,lastW)</tt> shall form a +sequence <tt>w</tt> of length <tt>n <del>> 0</del></tt> +<ins>such that <tt>0 < n <= numeric_limits<IntType>::max()</tt>,</ins> +and <tt>*firstW</tt> shall yield a value <tt>w<sub>0</sub></tt> +convertible to <tt>double</tt>. [<i>Note:</i> The values <tt>w<sub>k</sub></tt> are commonly known +as the weights . <i>-- end note</i>] +</blockquote> + +</blockquote> + +</blockquote> + + + + + +<hr> +<h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</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#NAD">NAD</a> + <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<ol type="a"> +<li> +The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies +to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>. +</li> +<li> +<p> +The design of the constructor +</p> +<blockquote><pre>template <class InputIteratorB, class InputIteratorW> +piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, + InputIteratorW firstW); +</pre></blockquote> +<p> +is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see +any performance or convenience reasons that would justify the risks inherent in such a function +interface, in particular the risk that input error might go unnoticed. +</p> +</li> +</ol> + +<p> +<b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface. +</p> + +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> + +<blockquote> +In reply to the discussion in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +I'd like to make the same comments as for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>. +</blockquote> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD. +</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.5.2 [rand.dist.samp.pconst]: +</p> + +<p> +Proposed wording a) +</p> + +<blockquote> +<p> +Change in para. 2 +</p> +<blockquote> +Constructs a <tt>piecewise_constant_distribution</tt> object with <tt>n = 1</tt>, <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>, +<tt>b<sub>0</sub> = 0</tt>, and <tt>b<sub>1</sub> = 1</tt> +</blockquote> + +<p> +and change in para. 5 +</p> + +<blockquote> +A <tt>vector<result_type></tt> whose <tt>size</tt> member returns <tt>n</tt> and whose <tt>operator[]</tt> +member returns <del><tt>p<sub>k</sub></tt></del> +<ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins> +when invoked with argument <tt>k</tt> for <tt>k = 0, ..., n-1</tt> +</blockquote> + +</blockquote> + +<p> +Proposed wording b) +</p> + +<blockquote> +<p> +Change both occurrences of +</p> + +<blockquote> +"piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB, + InputIteratorW firstW<ins>, InputIteratorW lastW</ins>) +</blockquote> + +<p> +and change in para. 3 +</p> + +<blockquote> +<del>the length of the sequence <tt>w</tt> starting from <tt>firstW</tt> shall be at least <tt>n</tt>, +<tt>*firstW</tt> shall return a value <tt>w<sub>0</sub></tt> that is convertible to <tt>double</tt>, and any +<tt>w<sub>k</sub></tt> for <tt>k >= n</tt> shall be ignored by the distribution</del> +<ins><tt>[firstW, lastW)</tt> shall form a sequence <tt>w</tt> of length <tt>n</tt> whose leading element +<tt>w<sub>0</sub></tt> shall be convertible to <tt>double</tt></ins> +</blockquote> + +</blockquote> + + +</blockquote> + + + + + + +<hr> +<h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3> +<p><b>Section:</b> 26.4.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class +exposition should have type <tt>size_t</tt>, too. +</p> + + +<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="739"></a>739. Defect in [rand.util.canonical]/3</h3> +<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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.util.canonical">issues</a> in [rand.util.canonical].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2 +R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in +general) be computed at compile time. As this function template is performance critical, I propose +to replace ceil(b/log2 R) with ceil(b/floor(log2 R)). +</p> + +<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> +In N2424. Close NAD as described there. +</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="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3> +<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The following issue was raised by Alf P. Steinbach in c.l.c++.mod: +</p> + +<p> +According to the recent draft N2369, both the header memory synopsis +of 20.7 [memory] and 20.7.12.2.11 [util.smartptr.getdeleter] declare: +</p> + +<blockquote><pre>template<class D, class T> D* get_deleter(shared_ptr<T> const& p); +</pre></blockquote> + +<p> +This allows to retrieve the pointer to a mutable deleter of a <tt>const +shared_ptr</tt> (if that owns one) and therefore contradicts the usual +philosophy that associated functors are either read-only (e.g. +<tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect +the mutability of the owner (as seen for the both overloads of +<tt>unique_ptr::get_deleter</tt>). +Even the next similar counter-part of <tt>get_deleter</tt> - the two +overloads of <tt>function::target</tt> in the class template function +synopsis 20.6.15.2 [func.wrap.func] or in 20.6.15.2.5 [func.wrap.func.targ] - do +properly mirror the const-state of the owner. +</p> + +<b>Possible proposed resolutions:</b> + +<p> +Replace the declarations of <tt>get_deleter</tt> in the header <tt><memory></tt> +synopsis of 20.7 [memory] and in 20.7.12.2.11 [util.smartptr.getdeleter] by one of the +following alternatives (A) or (B): +</p> + +<ol type="A"> +<li> +Provide <b>only</b> the immutable variant. This would reflect the +current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or +<tt>map::value_comp</tt>. + +<blockquote><pre>template<class D, class T> const D* get_deleter(shared_ptr<T> const& p); +</pre></blockquote> +</li> +<li> +Just remove the function. +</li> +</ol> + +<p> +Alberto Ganesh Barbati adds: +</p> + +<ol start="3" type="A"> +<li> +<p> +Replace it with two functions: +</p> +<blockquote><pre>template <class D, class T> D get_deleter(shared_ptr<T> const&); +template <class D, class T> bool has_deleter(shared_ptr<T> const&); +</pre></blockquote> + +<p> +The first one would throw if <tt>D</tt> is the wrong type, while the latter would +never throw. This approach would reflect the current praxis of +<tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as +<tt>container::get_allocator()</tt> do. +</p> +</li> +</ol> + +<p> +Peter Dimov adds: +</p> + +<blockquote> +<p> +My favorite option is "not a defect". A, B and C break useful code. +</p> +</blockquote> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Concern this is similar to confusing "pointer to const" with "a constant pointer". +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="745"></a>745. copy_exception API slices.</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#NAD">NAD</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#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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It could be I did not understand the design rationale, but I thought +copy_exception would produce an exception_ptr to the most-derived (dynamic) +type of the passed exception. Instead it slices, which appears to be less +useful, and a likely source of FAQ questions in the future. +</p> +<p> +(Peter Dimov suggests NAD) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +How could this be implemented in a way that the dynamic type is cloned? +</p> +<p> +The feature is designed to create an exception_ptr from an object whose +static type is identical to the dynamic type and thus there is no +slicing involved. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</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#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I am trying to decide is a pure virtual function is a <i>necessary</i> as well as +sufficient requirement to be classified as abstract? +</p> +<p> +For instance, is the following (non-polymorphic) type considered abstract? +</p> +<blockquote><pre>struct abstract { +protected: + abstract(){} + abstract( abstract const & ) {} + ~abstract() {} +}; +</pre></blockquote> +<p> +(Suggested that this may be NAD, with an editorial fix-up from Pete on the +core wording to make clear that abstract requires a pure virtual function) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD. +</p> + + + + + +<hr> +<h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></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#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-10-15</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +14882-2003, [lib.uninitialized.copy] is currently written as follows: +</p> + +<blockquote> +<pre>template <class InputIterator, class ForwardIterator> + ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>, + ForwardIterator <i>result</i>); +</pre> +<blockquote> +<p> +-1- <i>Effects:</i> +</p> +<blockquote><pre>for (; first != last; ++result, ++first) + new (static_cast<void*>(&*result)) + typename iterator_traits<ForwardIterator>::value_type(*first); +</pre></blockquote> +<p> +-2- <i>Returns:</i> <tt><i>result</i></tt> +</p> +</blockquote> +</blockquote> + +<p> +similarily for N2369, and its corresponding section +20.7.10.1 [uninitialized.copy]. +</p> + +<p> +It's not clear to me what the return clause is supposed to mean, I see +two +possible interpretations: +</p> + +<ol type="a"> +<li> +The notion of <tt><i>result</i></tt> is supposed to mean the value given by the +function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for +<tt><i>result</i></tt>]. +This seems somewhat implied by recognizing that both the function +parameter +and the name used in the clause do have the same italic font. +</li> +<li> +The notion of "result" is supposed to mean the value of <tt><i>result</i></tt> +after the +preceding effects clause. This is in fact what all implementations I +checked +do (and which is probably it's intend, because it matches the +specification of <tt>std::copy</tt>). +</li> +</ol> + +<p> +The problem is: I see nothing in the standard which grants that this +interpretation +is correct, specifically [lib.structure.specifications] or +17.3.1.3 [structure.specifications] +resp. do not clarify which "look-up" rules apply for names found in +the elements +of the detailed specifications - Do they relate to the corresponding +synopsis or +to the effects clause (or possibly other elements)? Fortunately most +detailed +descriptions are unambigious in this regard, e.g. this problem does +not apply +for <tt>std::copy</tt>. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the wording of the return clause to say (20.7.10.1 [uninitialized.copy]): +</p> + +<blockquote> +<p> +-2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins> +</p> +</blockquote> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Resolution: NAD editorial -- project editor to decide if change is +worthwhile. Concern is that there are many other places this might +occur. +</blockquote> + + + + +<hr> +<h3><a name="756"></a>756. Container adaptors push</h3> +<p><b>Section:</b> 23.2.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-10-31</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +After n2369 we have a single <tt>push_back</tt> overload in the sequence containers, +of the "emplace" type. At variance with that, still in n2461, we have +two separate overloads, the C++03 one + one taking an rvalue reference +in the container adaptors. Therefore, simply from a consistency point of +view, I was wondering whether the container adaptors should be aligned +with the specifications of the sequence container themselves: thus have +a single <tt>push</tt> along the lines: +</p> + +<blockquote><pre>template<typename... _Args> +void +push(_Args&&... __args) + { c.push_back(std::forward<_Args>(__args)...); } +</pre></blockquote> + +<p><i>[ +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a> +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 23.2.5.1.1 [queue.defn]: +</p> + +<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> +<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> +<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> +</pre></blockquote> + +<p> +Change 23.2.5.2 [priority.queue]: +</p> + +<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> +<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> +<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> +</pre></blockquote> + +<p> +Change 23.2.5.2.2 [priqueue.members]: +</p> + +<blockquote> +<pre><del>void push(const value_type& x);</del> +</pre> +<blockquote> +<p> +<del><i>Effects:</i></del> +</p> +<blockquote><pre><del>c.push_back(x);</del> +<del>push_heap(c.begin(), c.end(), comp);</del> +</pre></blockquote> +</blockquote> + +<pre><ins>template<class... Args></ins> void push(<del>value_type</del> <ins>Args</ins>&&<ins>...</ins> <del>x</del> <ins>args</ins>); +</pre> +<blockquote> +<p> +<i>Effects:</i> +</p> +<blockquote><pre>c.push_back(std::<del>move</del><ins>forward<Args></ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>); +push_heap(c.begin(), c.end(), comp); +</pre></blockquote> +</blockquote> +</blockquote> + +<p> +Change 23.2.5.3.1 [stack.defn]: +</p> + +<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> +<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> +<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> +</pre></blockquote> + + + +<p><b>Rationale:</b></p> +<p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>. +</p> + + + + + +<hr> +<h3><a name="757"></a>757. Typo in the synopsis of vector</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#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-04</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the synopsis 23.2.6 [vector], there is the signature: +</p> + +<blockquote><pre>void insert(const_iterator position, size_type n, T&& x); +</pre></blockquote> + +<p> +instead of: +</p> + +<blockquote><pre>iterator insert(const_iterator position, T&& x); +</pre></blockquote> + +<p> +23.2.6.4 [vector.modifiers] is fine. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 23.2.6 [vector]: +</p> + +<blockquote><pre>iterator insert(const_iterator position, const T& x); +<ins>iterator insert(const_iterator position, T&& x);</ins> +void insert(const_iterator position, size_type n, const T& x); +<del>void insert(const_iterator position, size_type n, T&& x);</del> +</pre></blockquote> + + + + + +<hr> +<h3><a name="763"></a>763. Renaming <tt>emplace()</tt> overloads</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-04</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The associative containers provide 2 overloads of <tt>emplace()</tt>: +</p> + +<blockquote><pre>template <class... Args> pair<iterator, bool> emplace(Args&&... args); +template <class... Args> iterator emplace(const_iterator position, Args&&... args); +</pre></blockquote> + +<p> +This is a problem if you mean the first overload while passing +a <tt>const_iterator</tt> as first argument. +</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> +</blockquote> +<p> +This can be disambiguated by passing "begin" as the first argument in +the case when the non-default choice is desired. We believe that desire +will be rare. +</p> +<p> +Resolution: Change state to NAD. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Rename one of the two overloads. +For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>... +</p> + + + + + +<hr> +<h3><a name="764"></a>764. <tt>equal_range</tt> on unordered containers should return a <tt>pair</tt> of <tt>local_iterators</tt></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#NAD">NAD</a> + <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-29</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> + A major attribute of the unordered containers is that iterating +though them inside a bucket is very fast while iterating between buckets +can be much slower. If an unordered container has a low load factor, +iterating between the last iterator in one bucket and the next iterator, +which is in another bucket, is <tt>O(bucket_count())</tt> which may be much +larger than <tt>O(size())</tt>. +</p> +<p> + If <tt>b</tt> is an non-const unordered container of type <tt>B</tt> and <tt>k</tt> is an +object of it's <tt>key_type</tt>, then <tt>b.equal_range(k)</tt> currently returns +<tt>pair<B::iterator, B::iterator></tt>. Consider the following code: +</p> + +<blockquote><pre>B::iterator lb, ub; +tie(lb, ub) = b.equal_range(k); +for (B::iterator it = lb; it != ub; ++it) { + // Do something with *it +} +</pre></blockquote> + +<p> +If <tt>b.equal_range(k)</tt> returns a non-empty range (i.e. <tt>b</tt> contains at least +on element whose key is equivalent to <tt>k</tt>), then every iterator in the +half-open range <tt>[lb, ub)</tt> will be in the same bucket, but <tt>ub</tt> will likely +either be in a different bucket or be equal to <tt>b.end()</tt>. In either case, +iterating between <tt>ub - 1</tt> and <tt>ub</tt> could take a much longer time than +iterating through the rest of the range. +</p> +<p> +If instead of returning <tt>pair<iterator, iterator></tt>, <tt>equal_range</tt> were to +return <tt>pair<local_iterator, local_iterator></tt>, then <tt>ub</tt> (which, like <tt>lb</tt>, +would now be a <tt>local_iterator</tt>) could be guaranteed to always be in the +same bucket as <tt>lb</tt>. In the cases where currently <tt>ub</tt> is equal to <tt>b.end()</tt> +or is in a different bucket, <tt>ub</tt> would be equal to <tt>b.end(b.bucket(key))</tt>. + This would make iterating between <tt>lb</tt> and <tt>ub</tt> much faster, as every +iteration would be constant time. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +The proposed resolution breaks consistency with other container types +for dubious benefit, and iterators are already constant time. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the entry for <tt>equal_range</tt> in Table 93 (23.1.5 [unord.req]) as follows: +</p> +<table border="1"> +<tbody><tr> +<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th> +</tr> + +<tr> +<td><tt>b.equal_range(k)</tt></td> +<td><tt>pair<<ins>local_</ins>iterator,<ins>local_</ins>iterator>; pair<const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator></tt> for <tt>const b</tt>.</td> +<td>Returns a range containing all elements with keys equivalent to <tt>k</tt>. Returns <tt>make_pair(b.end(<ins>b.bucket(key)</ins>),b.end(<ins>b.bucket(key)</ins>))</tt> if no such elements exist.</td> +<td>Average case Θ<tt>(b.count(k))</tt>. Worst case Θ<tt>(b.size())</tt>. </td> +</tr> +</tbody></table> + + + + + +<hr> +<h3><a name="767"></a>767. Forwarding and backward compatibility</h3> +<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-28</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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Playing with g++'s C++0X mode, I noticed that the following +code, which used to compile: +</p> + +<blockquote><pre>#include <vector> + +int main() +{ + std::vector<char *> v; + v.push_back(0); +} +</pre></blockquote> + +<p> +now fails with the following error message: +</p> + +<blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member +function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, +_Args&& ...) [with _Args = int, _Tp = char*]': +.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void +std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with +_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]' +test.cpp:6: instantiated from here +.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid +conversion from 'int' to 'char*' +</blockquote> + +<p> +As far as I know, g++ follows the current draft here. +</p> +<p> +Does the committee really intend to break compatibility for such cases? +</p> + +<p><i>[ +Sylvain adds: +]</i></p> + + +<blockquote> +<p> +I just noticed that <tt>std::pair</tt> has the same issue. +The following now fails with GCC's -std=c++0x mode: +</p> + +<blockquote><pre>#include <utility> + +int main() +{ + std::pair<char *, char *> p (0,0); +} +</pre></blockquote> + +<p> +I have not made any general audit for such problems elsewhere. +</p> +</blockquote> + +<p><i>[ +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a> +]</i></p> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Motivation is to handle the old-style int-zero-valued NULL pointers. +Problem: this solution requires concepts in some cases, which some users +will be slow to adopt. Some discussion of alternatives involving +prohibiting variadic forms and additional library-implementation +complexity. +</p> +<p> +Discussion of "perfect world" solutions, the only such solution put +forward being to retroactively prohibit use of the integer zero for a +NULL pointer. This approach was deemed unacceptable given the large +bodies of pre-existing code that do use integer zero for a NULL pointer. +</p> +<p> +Another approach is to change the member names. Yet another approach is +to forbid the extension in absence of concepts. +</p> +<p> +Resolution: These issues (<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>, <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-closed.html#763">763</a>) will be subsumed into a +paper to be produced by Alan Talbot in time for review at the 2008 +meeting in France. Once this paper is produced, these issues will be +moved to NAD. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]: +</p> + +<blockquote> +<table border="1"> +<tbody><tr> +<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th> +</tr> + +<tr> +<td> +<tt>a.push_front(t)</tt> +</td> +<td> +<tt>void</tt> +</td> +<td> +<tt>a.insert(a.begin(), t)</tt><br> +<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>. +</td> +<td> +<tt>list, deque</tt> +</td> +</tr> + +<tr> +<td> +<tt>a.push_front(rv)</tt> +</td> +<td> +<tt>void</tt> +</td> +<td> +<tt>a.insert(a.begin(), rv)</tt><br> +<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>. +</td> +<td> +<tt>list, deque</tt> +</td> +</tr> + +<tr> +<td> +<tt>a.push_back(t)</tt> +</td> +<td> +<tt>void</tt> +</td> +<td> +<tt>a.insert(a.end(), t)</tt><br> +<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>. +</td> +<td> +<tt>list, deque, vector, basic_string</tt> +</td> +</tr> + +<tr> +<td> +<tt>a.push_back(rv)</tt> +</td> +<td> +<tt>void</tt> +</td> +<td> +<tt>a.insert(a.end(), rv)</tt><br> +<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>. +</td> +<td> +<tt>list, deque, vector, basic_string</tt> +</td> +</tr> + +</tbody></table> +</blockquote> + +<p> +Change the synopsis in 23.2.2 [deque]: +</p> + +<blockquote><pre><ins>void push_front(const T& x);</ins> +<ins>void push_front(T&& x);</ins> +<ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + +<p> +Change 23.2.2.3 [deque.modifiers]: +</p> + +<blockquote><pre><ins>void push_front(const T& x);</ins> +<ins>void push_front(T&& x);</ins> +<ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + +<p> +Change the synopsis in 23.2.4 [list]: +</p> + +<blockquote><pre><ins>void push_front(const T& x);</ins> +<ins>void push_front(T&& x);</ins> +<ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + +<p> +Change 23.2.4.3 [list.modifiers]: +</p> + +<blockquote><pre><ins>void push_front(const T& x);</ins> +<ins>void push_front(T&& x);</ins> +<ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + +<p> +Change the synopsis in 23.2.6 [vector]: +</p> + +<blockquote><pre><ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + +<p> +Change 23.2.6.4 [vector.modifiers]: +</p> + +<blockquote><pre><ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + + + + +<p><b>Rationale:</b></p> +<p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>. +</p> + +<p> +If there is still an issue with pair, Howard should submit another issue. +</p> + + + + + +<hr> +<h3><a name="773"></a>773. issues with random</h3> +<p><b>Section:</b> 26.4.8.1 [rand.dist.uni] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-01-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<ol> +<li> +26.4.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> constructor has changed the default +max constructor parameter from 9 (in TR1) to <tt>max()</tt>. The value +is arbitrary at best and shouldn't be lightly changed because +it breaks backward compatibility. +</li> + +<li> +26.4.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> has a parameter <tt>param</tt> that you can +provide on construction or <tt>operator()</tt>, set, and get. But there +is not even a hint of what this might be for. +</li> + +<li> +26.4.8.1.2 [rand.dist.uni.real] <tt>uniform_real</tt>. Same issue as #2. +</li> +</ol> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +NAD. Withdrawn. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="784"></a>784. unique_lock::release</h3> +<p><b>Section:</b> 30.3.3.2.3 [thread.lock.unique.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Constantine Sapuntzakis <b>Date:</b> 2008-02-02</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>unique_lock::release</tt> will probably lead to many mistakes where people +call <tt>release</tt> instead of <tt>unlock</tt>. I just coded such a mistake using the +boost pre-1.35 threads library last week. +</p> + +<p> +In many threading libraries, a call with <tt>release</tt> in it unlocks the +lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore). +</p> + +<p> +I don't call <tt>unique_lock::lock</tt> much at all, so I don't get to see the +symmetry between <tt>::lock</tt> and <tt>::unlock</tt>. I usually use the constructor to +lock the mutex. So I'm left to remember whether to call <tt>release</tt> or +<tt>unlock</tt> during the few times I need to release the mutex before the scope +ends. If I get it wrong, the compiler doesn't warn me. +</p> + +<p> +An alternative name for release may be <tt>disown</tt>. +</p> + +<p> +This might be a rare case where usability is hurt by consistency with +the rest of the C++ standard (e.g. <tt>std::auto_ptr::release</tt>). +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Change a name from release to disown. However prior art uses the release +name. Compatibility with prior art is more important that any possible +benefit such a change might make. We do not see the benefit for +changing. NAD +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 30.3.3.2 [thread.lock.unique]: +</p> + +<blockquote><pre>template <class Mutex> +class unique_lock +{ +public: + ... + mutex_type* <del>release</del> <ins>disown</ins>(); + ... +}; +</pre></blockquote> + +<p> +Change 30.3.3.2.3 [thread.lock.unique.mod]: +</p> + +<blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>(); +</pre></blockquote> + + + + + +<hr> +<h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3> +<p><b>Section:</b> X [datetime.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Date:</b> 2008-02-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The draft C++0x thread library requires that the time points of type +<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated +Universal Time (UTC) (section X [datetime.system]). This can lead to +surprising behavior when a library user performs a duration-based wait, +such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the +problem may be found in the +<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a> +section in POSIX, but in summary: +</p> + +<ul> +<li> +Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX +equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times +to address the problem of spurious wakeups. +</li> + +<li> +The typical use of the timed wait operations is to perform a relative +wait. This may be achieved by first calculating an absolute time as the +sum of the current time and the desired duration. In fact, the C++0x +thread library includes duration-based overloads of +<tt>condition_variable::timed_wait()</tt> that behave as if by calling the +corresponding absolute time overload with a time point value of +<tt>get_system_time() + rel_time</tt>. +</li> + +<li> +A UTC clock may be affected by changes to the system time, such as +synchronization with an external source, leap seconds, or manual changes +to the clock. +</li> + +<li> +Should the clock change during a timed wait operation, the actual +duration of the wait will not be the expected length. For example, a +user may intend a timed wait of one second duration but, due to an +adjustment of the system clock backwards by a minute, the wait instead +takes 61 seconds. +</li> +</ul> + +<p> +POSIX solves the problem by introducing a new monotonic clock, which is +unaffected by changes to the system time. When a condition variable is +initialized, the user may specify whether the monotonic clock is to be +used. (It is worth noting that on POSIX systems it is not possible to +use <tt>condition_variable::native_handle()</tt> to access this facility, since +the desired clock type must be specified during construction of the +condition variable object.) +</p> + +<p> +In the context of the C++0x thread library, there are added dimensions +to the problem due to the need to support platforms other than POSIX: +</p> + +<ul> +<li> +Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock. +</li> + +<li> +Some environments do not have a monotonic clock, but do have a UTC clock. +</li> + +<li> +The Microsoft Windows API's synchronization functions use relative +timeouts based on an implied monotonic clock. A program that switches +from the Windows API to the C++0x thread library will now find itself +susceptible to clock changes. +</li> +</ul> + +<p> +One possible minimal solution: +</p> + +<ul> +<li> +Strike normative references to UTC and an epoch based on 1970-01-01. +</li> + +<li> +Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt> +implementation-defined (i.e standard library implementors may choose the +appropriate underlying clock based on the capabilities of the target +platform). +</li> + +<li> +Add a non-normative note encouraging use of a monotonic clock. +</li> + +<li> +Remove <tt>system_time::seconds_since_epoch()</tt>. +</li> + +<li> +Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns += 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>. +</li> +</ul> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + +<p><b>Rationale:</b></p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>. + + + + + +<hr> +<h3><a name="790"></a>790. <tt>xor_combine::seed</tt> not specified</h3> +<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>xor_combine::seed(result_type)</tt> and <tt>seed(seed_seq&)</tt> don't say what +happens to each of the sub-engine seeds. (Should probably do the same +to both, unlike TR1.) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Overcome by the previous proposal. NAD mooted by resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="791"></a>791. <tt>piecewise_constant_distribution::densities</tt> has wrong name</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#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>piecewise_constant_distribution::densities()</tt> should be <tt>probabilities()</tt>, +just like <tt>discrete_distribution</tt>. (There's no real use for weights divided +by areas.) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Fermilab does not agree with this summary. As defined in the equation in +26.4.8.5.2/4, the quantities are indeed probability densities not +probabilities. Because we view this distribution as a parameterization +of a *probability density function*, we prefer to work in terms of +probability densities. +</p> + +<p> +We don't think this should be changed. +</p> + +<p> +If there is a technical argument about why the implementation dealing +with these values can't be as efficient as one dealing with +probabilities, we might reconsider. We don't care about this one member +function being somewhat more or less efficient; we care about the size +of the distribution object and the speed of the calls to generate +variates. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Change synopsis in 26.4.8.5.2 [rand.dist.samp.pconst]: +</p> + +<blockquote><pre>template <class RealType = double> +class piecewise_constant_distribution +{ +public: + ... + vector<double> <del>densities</del> <ins>probabilities</ins>() const; + ... +}; +</pre></blockquote> + +<p> +Change 26.4.8.5.2 [rand.dist.samp.pconst]/6: +</p> + +<blockquote><pre>vector<double> <del>densities</del> <ins>probabilities</ins>() const; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="795"></a>795. <tt>general_pdf_distribution</tt> should be dropped</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#Dup">Dup</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</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#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a></p> +<p><b>Discussion:</b></p> +<p> +<tt>general_pdf_distribution</tt> should be dropped. (It's a research topic in +adaptive numerical integration.) +</p> + +<p><i>[ +Stephan Tolksdorf notes: +]</i></p> + + +<blockquote> +This appears to be a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + + +<hr> +<h3><a name="796"></a>796. <tt>ranlux48_base</tt> returns wrong value</h3> +<p><b>Section:</b> 26.4.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The 10,000<sup>th</sup> value returned by <tt>ranlux48_base</tt> is supposed to be +61839128582725. We get 192113843633948. (Note that the underlying +generator was changed in Kona.) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Submitter withdraws defect. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.4.5 [rand.predef]/p5: +</p> + +<blockquote> +<pre>typedef subtract_with_carry_engine<uint_fast64_t, 48, 5, 12> + ranlux48_base; +</pre> +<blockquote> +<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed +object of type <tt>ranlux48_base</tt> shall produce the value +<del>61839128582725</del> <ins>192113843633948</ins>. +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="797"></a>797. <tt>ranlux48</tt> returns wrong value</h3> +<p><b>Section:</b> 26.4.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The 10,000<sup>th</sup> value returned by <tt>ranlux48</tt> is supposed to be +249142670248501. We get 88229545517833. (Note that this depends +on <tt>ranlux48_base</tt>.) +</p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Submitter withdraws defect. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.4.5 [rand.predef]/p6: +</p> + +<blockquote> +<pre>typedef discard_block_engine<ranlux48_base, 389, 11> + ranlux48 +</pre> +<blockquote> +<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed +object of type <tt>ranlux48</tt> shall produce the value +<del>249142670248501</del> <ins>88229545517833</ins>. +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="799"></a>799. [tr.rand.eng.mers] and [rand.eng.mers]</h3> +<p><b>Section:</b> 26.4.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +TR1 5.1.4.2 [tr.rand.eng.mers](10) requires that <tt>operator==</tt> for the <tt>mersenne_twister</tt> +returns <tt>true</tt> if and only if the states of two <tt>mersenne_twisters</tt>, +consisting each of <tt>n</tt> integers between <tt>0</tt> and <tt>2<sup>w</sup> - 1</tt>, are completely +equal. This is a contradiction with TR1 5.1.1 [tr.rand.req](3) because the given +definition of the state also includes the lower <tt>r</tt> bits of <tt>x(i-n)</tt>, which +will never be used to generate a random number. If two <tt>mersenne_twister</tt>s +only differ in the lower bits of <tt>x(i-n)</tt> they will not compare equal, +although they will produce an identical sequence of random numbers. +</p> + +<p> +26.4.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour +of <tt>operator==</tt> but uses a similar definition of the state and, just like +TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a +<tt>mersenne_twister_engine</tt> to consist of <tt>X<sub>i-n</sub></tt> to <tt>X<sub>i-1</sub></tt>, including the +lower bits of <tt>X<sub>i-n</sub></tt>. This leads to two problems: First, the +unsuspecting implementer is likely to erroneously compare the lower <tt>r</tt> +bits of <tt>X<sub>i-n</sub></tt> in <tt>operator==</tt>. Second, if only the lower <tt>r</tt> bits differ, +two <tt>mersenne_twister_engine</tt>s will compare equal (if correctly +implemented) but have different textual representations, which +conceptually is a bit ugly. +</p> + +<p> +I propose that a paragraph or footnote is added to 26.4.3.2 [rand.eng.mers] which +clarifies that the lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> are not to be compared in +<tt>operator==</tt> and <tt>operator!=</tt>. It would only be consequent if furthermore +the specification for the textual respresentation was changed to +<tt>X<sub>i-n</sub> bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub>, ..., X<sub>i-1</sub></tt> or +something similar. +</p> + +<p> +These changes would likely have no practical effect, but would allow an +implementation that does the right thing to be standard-conformant. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Fermi Lab has no objection to the proposed change. However it feels that +more time is needed to check the details, which would suggest a change +to REVIEW. +</p> +<p> +Bill feels that this is NAD, not enough practical importance to abandon +the simple definition of equality, and someone would have to do a lot +more study to ensure that all cases are covered for a very small +payback. The submitter admits that "These changes would likely have no +practical effect,", and according to Plum's razor this means that it is +not worth the effort! +</p> +<p> +Revisted: Agree that the fact that there is no practical difference means that no change can be justified. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +In 26.4.3.2 [rand.eng.mers]: +</p> + +<blockquote> +<p> +Insert at the end of para 2.: +</p> + +<blockquote> +[<i>Note:</i> The lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> do not influence +the state transition and hence should not be compared when comparing two +<tt>mersenne_twister_engine</tt> objects. <i>-- end note</i>] +</blockquote> + +<p> +In para 5. change: +</p> + +<blockquote> +The textual representation of <tt>x<sub>i</sub></tt> consists of the values of +<tt>X<sub>i-n</sub> <ins>bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub></ins>, +..., X<sub>i-1</sub></tt>, in that order. +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="802"></a>802. <tt>knuth_b</tt> returns wrong value</h3> +<p><b>Section:</b> 26.4.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The 10,000<sup>th</sup> value returned by <tt>knuth_b</tt> is supposed to be +1112339016. We get 2126698284. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.4.5 [rand.predef]/p8: +</p> + +<blockquote> +<pre>typedef shuffle_order_engine<minstd_rand0, 256> + knuth_b; +</pre> +<blockquote> +<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed +object of type <tt>knuth_b</tt> shall produce the value +<del>1112339016</del> <ins>2126698284</ins>. +</blockquote> +</blockquote> + + +<p><i>[ +Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD. +]</i></p> + + + + + +<hr> +<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3> +<p><b>Section:</b> 22.2.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-07</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the spirit of <tt>printf vs iostream</tt>... +</p> + +<p> +POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the +implication is that in the absence of <tt>'</tt> no grouping characters are +inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert +grouping characters. Can this be considered a defect worth fixing for +C++0x? Maybe <tt>ios_base</tt> needs an additional flag? +</p> + +<p><i>[ +Pablo Halpern: +]</i></p> + + +<blockquote> +I'm not sure it constitutes a defect, but I would be in favor of adding +another flag (and corresponding manipulator). +</blockquote> + +<p><i>[ +Martin Sebor: +]</i></p> + + +<blockquote> +I don't know if it qualifies as a defect but I agree that there +should be an easy way to control whether the thousands separator +should or shouldn't be inserted. A new flag would be in line with +the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or +<tt>showbase</tt>). +</blockquote> + +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +This is not a part of C99. LWG suggests submitting a paper may be appropriate. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="831"></a>831. wrong type for not_eof()</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#NAD%20Editorial">NAD Editorial</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.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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> + In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function + is using an argument of type <i>e</i> which denotes an object of + type <code>X::int_type</code>. However, the specializations in + 21.1.3 [char.traits.specializations] all use <code>char_type</code>. + This would effectively mean that the argument type actually can't + represent EOF in the first place. I'm pretty sure that the type used + to be <code>int_type</code> which is quite obviously the only sensible + argument. +</p> +<p> + This issue is close to being editorial. I suspect that the proposal + changing this section to include the specializations for <code>char16_t</code> + and <code>char32_t</code> accidentally used the wrong type. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> + 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 + [char.traits.specializations.wchar_t] correct the + argument type from <code>char_type</code> to <code>int_type</code>. +</p> + + +<p><b>Rationale:</b></p> +Already fixed in WP. + + + + + +<hr> +<h3><a name="840"></a>840. <tt>pair</tt> default template argument</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#NAD">NAD</a> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-05-23</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I have one issue with <tt>std::pair</tt>. Well, it might just be a very annoying +historical accident, but why is there no default template argument for +the second template argument? This is so annoying when the type in +question is looong and hard to write (type deduction with <tt>auto</tt> won't +help those cases where we use it as a return or argument type). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 20.2 [utility] to read: +</p> + +<blockquote><pre>template <class T1, class T2 <ins>= T1</ins>> struct pair; +</pre></blockquote> + +<p> +Change 20.2.3 [pairs] to read: +</p> + +<blockquote><pre>namespace std { + template <class T1, class T2 <ins>= T1</ins>> + struct pair { + typedef T1 first_type; + typedef T2 second_type; + ... +</pre></blockquote> + + +<p><b>Rationale:</b></p> +<tt>std::pair</tt> is a heterogeneous container. + + + + + +</body></html>
\ No newline at end of file diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-defects.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-defects.html new file mode 100644 index 000000000..5951a9821 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-defects.html @@ -0,0 +1,29778 @@ +<!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 Defect Report 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">N2728=08-0238</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 Defect Report 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-active.html">Library Active Issues 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>This document contains only library issues which have been closed + by the Library Working Group (LWG) after being found to be defects + in the standard. That is, issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>, + <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a>. See the + <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects. See the + <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> for active issues and more information. The + introductory material in that document also applies to this + document.</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>Defect Reports</h2> +<hr> +<h3><a name="1"></a>1. C library linkage editing oversight</h3> +<p><b>Section:</b> 17.4.2.2 [using.linkage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The change specified in the proposed resolution below did not make +it into the Standard. This change was accepted in principle at the +London meeting, and the exact wording below was accepted at the +Morristown meeting.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 17.4.2.2 [using.linkage] paragraph 2 +from:</p> + +<blockquote> + <p>It is unspecified whether a name from the Standard C library + declared with external linkage has either extern "C" or + extern "C++" linkage.</p> +</blockquote> + +<p>to:</p> + +<blockquote> + <p>Whether a name from the Standard C library declared with external + linkage has extern "C" or extern "C++" linkage + is implementation defined. It is recommended that an implementation + use extern "C++" linkage for this purpose.</p> +</blockquote> + + + + + +<hr> +<h3><a name="3"></a>3. Atexit registration during atexit() call is not described</h3> +<p><b>Section:</b> 18.4 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 1997-12-12</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>We appear not to have covered all the possibilities of + exit processing with respect to +atexit registration. <br> +<br> +Example 1: (C and C++)</p> + +<pre> #include <stdlib.h> + void f1() { } + void f2() { atexit(f1); } + + int main() + { + atexit(f2); // the only use of f2 + return 0; // for C compatibility + }</pre> + +<p>At program exit, f2 gets called due to its registration in +main. Running f2 causes f1 to be newly registered during the exit +processing. Is this a valid program? If so, what are its +semantics?</p> + +<p> +Interestingly, neither the C standard, nor the C++ draft standard nor +the forthcoming C9X Committee Draft says directly whether you can +register a function with atexit during exit processing.</p> + +<p> +All 3 standards say that functions are run in reverse order of their +registration. Since f1 is registered last, it ought to be run first, +but by the time it is registered, it is too late to be first.</p> + +<p>If the program is valid, the standards are self-contradictory about +its semantics.</p> + +<p>Example 2: (C++ only)</p> + +<pre> + void F() { static T t; } // type T has a destructor + + int main() + { + atexit(F); // the only use of F + } +</pre> + +<p>Function F registered with atexit has a local static variable t, +and F is called for the first time during exit processing. A local +static object is initialized the first time control flow passes +through its definition, and all static objects are destroyed during +exit processing. Is the code valid? If so, what are its semantics?</p> + +<p> +Section 18.3 "Start and termination" says that if a function +F is registered with atexit before a static object t is initialized, F +will not be called until after t's destructor completes.</p> + +<p> +In example 2, function F is registered with atexit before its local +static object O could possibly be initialized. On that basis, it must +not be called by exit processing until after O's destructor +completes. But the destructor cannot be run until after F is called, +since otherwise the object could not be constructed in the first +place.</p> + +<p>If the program is valid, the standard is self-contradictory about +its semantics.</p> + +<p>I plan to submit Example 1 as a public comment on the C9X CD, with +a recommendation that the results be undefined. (Alternative: make it +unspecified. I don't think it is worthwhile to specify the case where +f1 itself registers additional functions, each of which registers +still more functions.)</p> + +<p>I think we should resolve the situation in the whatever way the C +committee decides. </p> + +<p>For Example 2, I recommend we declare the results undefined.</p> + +<p><i>[See reflector message lib-6500 for further discussion.]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p>Change section 18.3/8 from:</p> +<blockquote><p> + First, objects with static storage duration are destroyed and + functions registered by calling atexit are called. Objects with + static storage duration are destroyed in the reverse order of the + completion of their constructor. (Automatic objects are not + destroyed as a result of calling exit().) Functions registered with + atexit are called in the reverse order of their registration. A + function registered with atexit before an object obj1 of static + storage duration is initialized will not be called until obj1's + destruction has completed. A function registered with atexit after + an object obj2 of static storage duration is initialized will be + called before obj2's destruction starts. +</p></blockquote> +<p>to:</p> +<blockquote><p> + First, objects with static storage duration are destroyed and + functions registered by calling atexit are called. Non-local objects + with static storage duration are destroyed in the reverse order of + the completion of their constructor. (Automatic objects are not + destroyed as a result of calling exit().) Functions registered with + atexit are called in the reverse order of their registration, except + that a function is called after any previously registered functions + that had already been called at the time it was registered. A + function registered with atexit before a non-local object obj1 of + static storage duration is initialized will not be called until + obj1's destruction has completed. A function registered with atexit + after a non-local object obj2 of static storage duration is + initialized will be called before obj2's destruction starts. A local + static object obj3 is destroyed at the same time it would be if a + function calling the obj3 destructor were registered with atexit at + the completion of the obj3 constructor. +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis +supporting to the proposed resolution.</p> + + + + + +<hr> +<h3><a name="5"></a>5. String::compare specification questionable</h3> +<p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Jack Reeves <b>Date:</b> 1997-12-11</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#87">87</a></p> +<p><b>Discussion:</b></p> +<p>At the very end of the basic_string class definition is the signature: int +compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the +following text this is defined as: returns +basic_string<charT,traits,Allocator>(*this,pos1,n1).compare( +basic_string<charT,traits,Allocator>(s,n2); </p> + +<p>Since the constructor basic_string(const charT* s, size_type n, const Allocator& a += Allocator()) clearly requires that s != NULL and n < npos and further states that it +throws length_error if n == npos, it appears the compare() signature above should always +throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some +null terminated character array. </p> + +<p>This appears to be a typo since the obvious intent is to allow either the call above or +something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p> + +<p>This would imply that what was really intended was two signatures int compare(size_type +pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const +charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace the compare signature in 21.3 [basic.string] +(at the very end of the basic_string synopsis) which reads:</p> + +<blockquote> + <p><tt>int compare(size_type pos1, size_type n1,<br> + const charT* s, + size_type n2 = npos) const;</tt></p> +</blockquote> + +<p>with:</p> + +<blockquote> + <p><tt>int compare(size_type pos1, size_type n1,<br> + const charT* s) const;<br> + int compare(size_type pos1, size_type n1,<br> + const charT* s, + size_type n2) const;</tt></p> +</blockquote> + +<p>Replace the portion of 21.3.6.8 [string::swap] +paragraphs 5 and 6 which read:</p> + +<blockquote> + <p><tt>int compare(size_type pos, size_type n1,<br> + charT * s, size_type n2 + = npos) const;<br> + </tt>Returns:<tt><br> + basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br> + + basic_string<charT,traits,Allocator>( s, n2))</tt></p> +</blockquote> + +<p>with:</p> + +<blockquote> + <p><tt>int compare(size_type pos, size_type n1,<br> + const charT * s) const;<br> + </tt>Returns:<tt><br> + basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br> + + basic_string<charT,traits,Allocator>( s ))<br> + <br> + int compare(size_type pos, size_type n1,<br> + const charT * s, + size_type n2) const;<br> + </tt>Returns:<tt><br> + basic_string<charT,traits,Allocator>(*this, pos, n1).compare(<br> + + basic_string<charT,traits,Allocator>( s, n2))</tt></p> +</blockquote> + +<p>Editors please note that in addition to splitting the signature, the third argument +becomes const, matching the existing synopsis.</p> + + +<p><b>Rationale:</b></p> +<p>While the LWG dislikes adding signatures, this is a clear defect in +the Standard which must be fixed. The same problem was also +identified in issues 7 (item 5) and 87.</p> + + + + + +<hr> +<h3><a name="7"></a>7. String clause minor problems</h3> +<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>(1) In 21.3.6.4 [string::insert], the description of template +<class InputIterator> insert(iterator, InputIterator, +InputIterator) makes no sense. It refers to a member function that +doesn't exist. It also talks about the return value of a void +function. </p> + +<p>(2) Several versions of basic_string::replace don't appear in the +class synopsis. </p> + +<p>(3) basic_string::push_back appears in the synopsis, but is never +described elsewhere. In the synopsis its argument is const charT, +which doesn't makes much sense; it should probably be charT, or +possible const charT&. </p> + +<p>(4) basic_string::pop_back is missing. </p> + +<p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2 += npos) make no sense. First, it's const charT* in the synopsis and +charT* in the description. Second, given what it says in RETURNS, +leaving out the final argument will always result in an exception +getting thrown. This is paragraphs 5 and 6 of +21.3.6.8 [string::swap]</p> + +<p>(6) In table 37, in section 21.1.1 [char.traits.require], +there's a note for X::move(s, p, n). It says "Copies correctly +even where p is in [s, s+n)". This is correct as far as it goes, +but it doesn't go far enough; it should also guarantee that the copy +is correct even where s in in [p, p+n). These are two orthogonal +guarantees, and neither one follows from the other. Both guarantees +are necessary if X::move is supposed to have the same sort of +semantics as memmove (which was clearly the intent), and both +guarantees are necessary if X::move is actually supposed to be +useful. </p> + + +<p><b>Proposed resolution:</b></p> +<p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br> +<br> + EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br> +<br> +ITEM 2: Not a defect; the Standard is clear.. There are ten versions of replace() in +the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br> +<br> +ITEM 3: Change the declaration of push_back in the string synopsis (21.3, +[lib.basic.string]) from:</p> + +<p> void push_back(const charT)<br> +<br> +to<br> +<br> + void push_back(charT)<br> +<br> +Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br> +<br> + void basic_string::push_back(charT c);<br> + EFFECTS: Equivalent to append(static_cast<size_type>(1), c);<br> +<br> +ITEM 4: Not a defect. The omission appears to have been deliberate.<br> +<br> +ITEM 5: Duplicate; see issue 5 (and 87).<br> +<br> +ITEM 6: In table 37, Replace:<br> +<br> + "Copies correctly even where p is in [s, s+n)."<br> +<br> +with:<br> +<br> + "Copies correctly even where the ranges [p, p+n) and [s, +s+n) overlap."</p> + + + + + +<hr> +<h3><a name="8"></a>8. Locale::global lacks guarantee</h3> +<p><b>Section:</b> 22.1.1.5 [locale.statics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-24</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>It appears there's an important guarantee missing from clause +22. We're told that invoking locale::global(L) sets the C locale if L +has a name. However, we're not told whether or not invoking +setlocale(s) sets the global C++ locale. </p> + +<p>The intent, I think, is that it should not, but I can't find any +such words anywhere. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Add a sentence at the end of 22.1.1.5 [locale.statics], +paragraph 2: </p> + +<blockquote> + <p>No library function other than <tt>locale::global()</tt> shall affect + the value returned by <tt>locale()</tt>. </p> + +</blockquote> + + + + + +<hr> +<h3><a name="9"></a>9. Operator new(0) calls should not yield the same pointer</h3> +<p><b>Section:</b> 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-01-04</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that +section 3.7.3.1 of CD2 seems to allow for the possibility that all +calls to operator new(0) yield the same pointer, an implementation +technique specifically prohibited by ARM 5.3.3.Was this prohibition +really lifted? Does the FDIS agree with CD2 in the regard? [Issues +list maintainer's note: the IS is the same.]</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the last paragraph of 3.7.3 from:</p> +<blockquote> + <p>Any allocation and/or deallocation functions defined in a C++ program shall + conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p> +</blockquote> +<p>to:</p> +<blockquote> + <p>Any allocation and/or deallocation functions defined in a C++ program, + including the default versions in the library, shall conform to the semantics + specified in 3.7.3.1 and 3.7.3.2.</p> +</blockquote> +<p>Change 3.7.3.1/2, next-to-last sentence, from :</p> +<blockquote> + <p>If the size of the space requested is zero, the value returned shall not be + a null pointer value (4.10).</p> +</blockquote> +<p>to:</p> +<blockquote> + <p>Even if the size of the space requested is zero, the request can fail. If + the request succeeds, the value returned shall be a non-null pointer value + (4.10) p0 different from any previously returned value p1, unless that value + p1 was since passed to an operator delete.</p> +</blockquote> +<p>5.3.4/7 currently reads:</p> +<blockquote> + <p>When the value of the expression in a direct-new-declarator is zero, the + allocation function is called to allocate an array with no elements. The + pointer returned by the new-expression is non-null. [Note: If the library + allocation function is called, the pointer returned is distinct from the + pointer to any other object.]</p> +</blockquote> +<p>Retain the first sentence, and delete the remainder.</p> +<p>18.5.1 currently has no text. Add the following:</p> +<blockquote> + <p>Except where otherwise specified, the provisions of 3.7.3 apply to the + library versions of operator new and operator delete.</p> +</blockquote> +<p>To 18.5.1.3, add the following text:</p> +<blockquote> + <p>The provisions of 3.7.3 do not apply to these reserved placement forms of + operator new and operator delete.</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis +supporting to the proposed resolution.</p> + + + + + +<hr> +<h3><a name="11"></a>11. Bitset minor problems</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#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is +not documented in 23.3.5.2. </p> + +<p>(2) The class synopsis only gives a single signature for bitset<>::operator[], +reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded +on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p> + +<p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before +trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should +go in the Effects clause.</p> + + +<p><b>Proposed resolution:</b></p> +<p>ITEMS 1 AND 2:<br> +<br> +In the bitset synopsis (23.3.5 [template.bitset]), +replace the member function <br> +<br> +<tt> reference operator[](size_t pos);<br> +</tt><br> +with the two member functions<br> +<br> +<tt> bool operator[](size_t pos) const; <br> + reference operator[](size_t pos); <br> +</tt><br> +Add the following text at the end of 23.3.5.2 [bitset.members], +immediately after paragraph 45:</p> + +<blockquote> + <p><tt>bool operator[](size_t pos) const;</tt><br> + Requires: pos is valid<br> + Throws: nothing<br> + Returns: <tt>test(pos)</tt><br> + <br> + <tt>bitset<N>::reference operator[](size_t pos);</tt> <br> + Requires: pos is valid<br> + Throws: nothing<br> + Returns: An object of type <tt>bitset<N>::reference</tt> such that <tt>(*this)[pos] + == this->test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this->set(pos, + val);</tt></p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>The LWG believes Item 3 is not a defect. "Formatted +input" implies the desired semantics. See 27.6.1.2 [istream.formatted]. +</p> + + + + + +<hr> +<h3><a name="13"></a>13. Eos refuses to die</h3> +<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> William M. Miller <b>Date:</b> 1998-03-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 27.6.1.2.3, there is a reference to "eos", which is +the only one in the whole draft (at least using Acrobat search), so +it's undefined. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.6.1.2.3 [istream::extractors], replace "eos" with +"charT()"</p> + + + + + +<hr> +<h3><a name="14"></a>14. Locale::combine should be const</h3> +<p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>locale::combine is the only member function of locale (other than constructors and +destructor) that is not const. There is no reason for it not to be const, and good reasons +why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1 +paragraph 6: "An instance of a locale is immutable." </p> + +<p>History: this member function originally was a constructor. it happened that the +interface it specified had no corresponding language syntax, so it was changed to a member +function. As constructors are never const, there was no "const" in the interface +which was transformed into member "combine". It should have been added at that +time, but the omission was not noticed. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.1.1 [locale] and also in 22.1.1.3 [locale.members], add +"const" to the declaration of member combine: </p> +<blockquote> + <pre>template <class Facet> locale combine(const locale& other) const; </pre> +</blockquote> + + + + + +<hr> +<h3><a name="15"></a>15. Locale::name requirement inconsistent</h3> +<p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>locale::name() is described as returning a string that can be passed to a locale +constructor, but there is no matching constructor. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.1.1.3 [locale.members], paragraph 5, replace +"<tt>locale(name())</tt>" with +"<tt>locale(name().c_str())</tt>". +</p> + + + + + +<hr> +<h3><a name="16"></a>16. Bad ctype_byname<char> decl</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#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The new virtual members ctype_byname<char>::do_widen and do_narrow did not get +edited in properly. Instead, the member do_widen appears four times, with wrong argument +lists. </p> + + +<p><b>Proposed resolution:</b></p> +<p>The correct declarations for the overloaded members +<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied +from 22.2.1.3 [facet.ctype.special].</p> + + + + + +<hr> +<h3><a name="17"></a>17. Bad bool parsing</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#TC">TC</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>This section describes the process of parsing a text boolean value from the input +stream. It does not say it recognizes either of the sequences "true" or +"false" and returns the corresponding bool value; instead, it says it recognizes +only one of those sequences, and chooses which according to the received value of a +reference argument intended for returning the result, and reports an error if the other +sequence is found. (!) Furthermore, it claims to get the names from the ctype<> +facet rather than the numpunct<> facet, and it examines the "boolalpha" +flag wrongly; it doesn't define the value "loc"; and finally, it computes +wrongly whether to use numeric or "alpha" parsing.<br> +<br> +I believe the correct algorithm is "as if": </p> + +<pre> // in, err, val, and str are arguments. + err = 0; + const numpunct<charT>& np = use_facet<numpunct<charT> >(str.getloc()); + const string_type t = np.truename(), f = np.falsename(); + bool tm = true, fm = true; + size_t pos = 0; + while (tm && pos < t.size() || fm && pos < f.size()) { + if (in == end) { err = str.eofbit; } + bool matched = false; + if (tm && pos < t.size()) { + if (!err && t[pos] == *in) matched = true; + else tm = false; + } + if (fm && pos < f.size()) { + if (!err && f[pos] == *in) matched = true; + else fm = false; + } + if (matched) { ++in; ++pos; } + if (pos > t.size()) tm = false; + if (pos > f.size()) fm = false; + } + if (tm == fm || pos == 0) { err |= str.failbit; } + else { val = tm; } + return in;</pre> + +<p>Notice this works reasonably when the candidate strings are both empty, or equal, or +when one is a substring of the other. The proposed text below captures the logic of the +code above.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14, +change "&&" to "&".</p> + +<p>Then, replace paragraphs 15 and 16 as follows:</p> + +<blockquote> + + <p>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> >(str.getloc())</tt>. + Successive characters in the range <tt>[in,end)</tt> (see + [lib.sequence.reqmts]) are obtained and matched against + corresponding positions in the target sequences only as necessary to + identify a unique match. The input iterator <tt>in</tt> is + compared to <tt>end</tt> only when necessary to obtain a + character. If and only if a target sequence is uniquely matched, + <tt>val</tt> is set to the corresponding value.</p> + +</blockquote> + +<blockquote> + <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character + successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to + <tt>str.eofbit</tt> if, when seeking another character to match, it is found that + <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to + <tt>(str.failbit|str.eofbit)</tt>if + the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets + <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields + <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields + <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets + <tt>true</tt>:"1" + and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt> + and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields + <tt>err==str.failbit</tt>. --end example]</p> +</blockquote> + + + + + +<hr> +<h3><a name="18"></a>18. Get(...bool&) omitted</h3> +<p><b>Section:</b> 22.2.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In the list of num_get<> non-virtual members on page 22-23, the member +that parses bool values was omitted from the list of definitions of non-virtual +members, though it is listed in the class definition and the corresponding +virtual is listed everywhere appropriate. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Add at the beginning of 22.2.2.1.1 [facet.num.get.members] +another get member for bool&, copied from the entry in +22.2.2.1 [locale.num.get].</p> + + + + + +<hr> +<h3><a name="19"></a>19. "Noconv" definition too vague</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#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#10">10</a></p> +<p><b>Discussion:</b></p> +<p> +In the definitions of codecvt<>::do_out and do_in, they are +specified to return noconv if "no conversion is +needed". This definition is too vague, and does not say +normatively what is done with the buffers. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the entry for noconv in the table under paragraph 4 in section +22.2.1.4.2 [locale.codecvt.virtuals] to read: +</p> +<blockquote> + <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type, + and input sequence is identical to converted sequence.</p> +</blockquote> +<p>Change the Note in paragraph 2 to normative text as follows:</p> +<blockquote> + <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the + same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>. + <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is + unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p> +</blockquote> + + + + + +<hr> +<h3><a name="20"></a>20. Thousands_sep returns wrong type</h3> +<p><b>Section:</b> 22.2.3.1.2 [facet.numpunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The synopsis for numpunct<>::do_thousands_sep, and the +definition of numpunct<>::thousands_sep which calls it, specify +that it returns a value of type char_type. Here it is erroneously +described as returning a "string_type". </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change +"string_type" to "char_type". </p> + + + + + +<hr> +<h3><a name="21"></a>21. Codecvt_byname<> instantiations</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#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In the second table in the section, captioned "Required +instantiations", the instantiations for codecvt_byname<> +have been omitted. These are necessary to allow users to construct a +locale by name from facets. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Add in 22.1.1.1.1 [locale.category] to the table captioned +"Required instantiations", in the category "ctype" +the lines </p> + +<blockquote> + <pre>codecvt_byname<char,char,mbstate_t>, +codecvt_byname<wchar_t,char,mbstate_t> </pre> +</blockquote> + + + + + +<hr> +<h3><a name="22"></a>22. Member open vs. flags</h3> +<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The description of basic_istream<>::open leaves unanswered questions about how it +responds to or changes flags in the error status for the stream. A strict reading +indicates that it ignores the bits and does not change them, which confuses users who do +not expect eofbit and failbit to remain set after a successful open. There are three +reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit +and eofbit on call to open(). </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.8.1.9 [ifstream.members] paragraph 3, <i>and</i> in 27.8.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote: +</p> + +<blockquote> + <p>A successful open does not change the error state.</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>This may seem surprising to some users, but it's just an instance +of a general rule: error flags are never cleared by the +implementation. The only way error flags are are ever cleared is if +the user explicitly clears them by hand.</p> + +<p>The LWG believed that preserving this general rule was +important enough so that an exception shouldn't be made just for this +one case. The resolution of this issue clarifies what the LWG +believes to have been the original intent.</p> + + + + + + +<hr> +<h3><a name="24"></a>24. "do_convert" doesn't exist</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#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#72">72</a></p> +<p><b>Discussion:</b></p> +<p>The description of codecvt<>::do_out and do_in mentions a +symbol "do_convert" which is not defined in the +standard. This is a leftover from an edit, and should be "do_in +and do_out". </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.1.4 [locale.codecvt], paragraph 3, change +"do_convert" to "do_in or do_out". Also, in 22.2.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in +or do_out". </p> + + + + + +<hr> +<h3><a name="25"></a>25. String operator<< uses width() value wrong</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#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#67">67</a></p> +<p><b>Discussion:</b></p> +<p>In the description of operator<< applied to strings, the standard says that uses +the smaller of os.width() and str.size(), to pad "as described in stage 3" +elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 21.3.8.9 [string.io] paragraph 4 from:<br> +<br> + "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>; +..."<br> +<br> +to: <br> +<br> + "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>; +..."</p> + + + + + +<hr> +<h3><a name="26"></a>26. Bad sentry example</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#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In paragraph 6, the code in the example: </p> + +<pre> template <class charT, class traits = char_traits<charT> > + basic_istream<charT,traits>::sentry( + basic_istream<charT,traits>& is, bool noskipws = false) { + ... + int_type c; + typedef ctype<charT> ctype_type; + const ctype_type& ctype = use_facet<ctype_type>(is.getloc()); + while ((c = is.rdbuf()->snextc()) != traits::eof()) { + if (ctype.is(ctype.space,c)==0) { + is.rdbuf()->sputbackc (c); + break; + } + } + ... + }</pre> + +<p>fails to demonstrate correct use of the facilities described. In +particular, it fails to use traits operators, and specifies incorrect +semantics. (E.g. it specifies skipping over the first character in the +sequence without examining it.) </p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove the example above from 27.6.1.1.3 [istream::sentry] +paragraph 6.</p> + + +<p><b>Rationale:</b></p> +<p>The originally proposed replacement code for the example was not +correct. The LWG tried in Kona and again in Tokyo to correct it +without success. In Tokyo, an implementor reported that actual working +code ran over one page in length and was quite complicated. The LWG +decided that it would be counter-productive to include such a lengthy +example, which might well still contain errors.</p> + + + + + +<hr> +<h3><a name="27"></a>27. String::erase(range) yields wrong iterator</h3> +<p><b>Section:</b> 21.3.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The string::erase(iterator first, iterator last) is specified to return an element one +place beyond the next element after the last one erased. E.g. for the string +"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e', +while 'd' has not been erased. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 21.3.6.5 [string::erase], paragraph 10, change: </p> + +<blockquote> + <p>Returns: an iterator which points to the element immediately following _last_ prior to + the element being erased. </p> +</blockquote> + +<p>to read </p> + +<blockquote> + <p>Returns: an iterator which points to the element pointed to by _last_ prior to the + other elements being erased. </p> +</blockquote> + + + + + +<hr> +<h3><a name="28"></a>28. Ctype<char>is ambiguous</h3> +<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#236">236</a></p> +<p><b>Discussion:</b></p> +<p>The description of the vector form of ctype<char>::is can be interpreted to mean +something very different from what was intended. Paragraph 4 says </p> + +<blockquote> + <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to + table()[(unsigned char)*p]. </p> +</blockquote> + +<p>This is intended to copy the value indexed from table()[] into the place identified in +vec[]. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 22.2.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p> + +<blockquote> + <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low] + the value table()[(unsigned char)*p]. </p> +</blockquote> + + + + + +<hr> +<h3><a name="29"></a>29. Ios_base::init doesn't exist</h3> +<p><b>Section:</b> 27.3.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Sections 27.3.1 [narrow.stream.objects] and 27.3.2 [wide.stream.objects] mention +a function ios_base::init, which is not defined. Probably they mean +basic_ios<>::init, defined in 27.4.4.1 [basic.ios.cons], +paragraph 3. </p> + + +<p><b>Proposed resolution:</b></p> +<p>[R12: modified to include paragraph 5.]</p> + +<p>In 27.3.1 [narrow.stream.objects] paragraph 2 and 5, change </p> + +<blockquote> + <p>ios_base::init </p> +</blockquote> + +<p>to </p> + +<blockquote> + <p>basic_ios<char>::init </p> +</blockquote> + +<p>Also, make a similar change in 27.3.2 [wide.stream.objects] except it +should read </p> + +<blockquote> + <p>basic_ios<wchar_t>::init </p> +</blockquote> + + + + + +<hr> +<h3><a name="30"></a>30. Wrong header for LC_*</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#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>, +where they are in fact defined elsewhere to appear in <clocale>. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.1.1.1.1 [locale.category], paragraph 2, change +"<cctype>" to read "<clocale>". </p> + + + + + +<hr> +<h3><a name="31"></a>31. Immutable locale values</h3> +<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#378">378</a></p> +<p><b>Discussion:</b></p> +<p>Paragraph 6, says "An instance of <tt>locale</tt> is +<i>immutable</i>; once a facet reference is obtained from it, +...". This has caused some confusion, because locale variables +are manifestly assignable. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.1.1 [locale] replace paragraph 6</p> + +<blockquote> + <p>An instance of <tt>locale</tt> is immutable; once a facet + reference is obtained from it, that reference remains usable as long + as the locale value itself exists.</p> +</blockquote> + +<p>with</p> + +<blockquote> + <p>Once a facet reference is obtained from a locale object by + calling use_facet<>, that reference remains usable, and the + results from member functions of it may be cached and re-used, as + long as some locale object refers to that facet.</p> +</blockquote> + + + + + +<hr> +<h3><a name="32"></a>32. Pbackfail description inconsistent</h3> +<p><b>Section:</b> 27.5.2.4.4 [streambuf.virt.pback] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The description of the required state before calling virtual member +basic_streambuf<>::pbackfail requirements is inconsistent with the conditions +described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it. +Specifically, the latter says it calls pbackfail if: </p> + +<p> traits::eq(c,gptr()[-1]) is false </p> + +<p>where pbackfail claims to require: </p> + +<p> traits::eq(*gptr(),traits::to_char_type(c)) returns false </p> + +<p>It appears that the pbackfail description is wrong. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.5.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p> + +<blockquote> + <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p> +</blockquote> + +<p>to </p> + +<blockquote> + <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>" + </p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>Note deliberate reordering of arguments for clarity in addition to the correction of +the argument value.</p> + + + + + +<hr> +<h3><a name="33"></a>33. Codecvt<> mentions from_type</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#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#43">43</a></p> +<p><b>Discussion:</b></p> +<p>In the table defining the results from do_out and do_in, the specification for the +result <i>error</i> says </p> + +<blockquote> + <p>encountered a from_type character it could not convert </p> +</blockquote> + +<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or +an internT for do_out. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition +in the table for the case of _error_ with </p> + +<blockquote> + <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p> +</blockquote> + + + + + +<hr> +<h3><a name="34"></a>34. True/falsename() not in ctype<></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#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In paragraph 19, Effects:, members truename() and falsename are used from facet +ctype<charT>, but it has no such members. Note that this is also a problem in +22.2.2.1.2, addressed in (4). </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects: +clause for member put(...., bool), replace the initialization of the +string_type value s as follows: </p> + +<blockquote> + <pre>const numpunct& np = use_facet<numpunct<charT> >(loc); +string_type s = val ? np.truename() : np.falsename(); </pre> +</blockquote> + + + + + +<hr> +<h3><a name="35"></a>35. No manipulator unitbuf in synopsis</h3> +<p><b>Section:</b> 27.4 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 27.4.5.1 [fmtflags.manip], we have a definition for a manipulator +named "unitbuf". Unlike other manipulators, it's not listed +in synopsis. Similarly for "nounitbuf". </p> + + +<p><b>Proposed resolution:</b></p> +<p>Add to the synopsis for <ios> in 27.4 [iostreams.base], after +the entry for "nouppercase", the prototypes: </p> + +<blockquote> + <pre>ios_base& unitbuf(ios_base& str); +ios_base& nounitbuf(ios_base& str); </pre> +</blockquote> + + + + + +<hr> +<h3><a name="36"></a>36. Iword & pword storage lifetime omitted</h3> +<p><b>Section:</b> 27.4.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is +specified badly, so that an implementation which only keeps the last value stored appears +to conform. In particular, it says: </p> + +<p>The reference returned may become invalid after another call to the object's iword +member with a different index ... </p> + +<p>This is not idle speculation; at least one implementation was done this way. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Add in 27.4.2.5 [ios.base.storage], in both paragraph 2 and also in +paragraph 4, replace the sentence: </p> + +<blockquote> + <p>The reference returned may become invalid after another call to the object's iword + [pword] member with a different index, after a call to its copyfmt member, or when the + object is destroyed. </p> +</blockquote> + +<p>with: </p> + +<blockquote> + <p>The reference returned is invalid after any other operations on the object. However, + the value of the storage referred to is retained, so that until the next call to copyfmt, + calling iword [pword] with the same index yields another reference to the same value. </p> +</blockquote> + +<p>substituting "iword" or "pword" as appropriate. </p> + + + + + +<hr> +<h3><a name="37"></a>37. Leftover "global" reference</h3> +<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In the overview of locale semantics, paragraph 4, is the sentence </p> + +<blockquote> + <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws + the standard exception bad_cast. </p> +</blockquote> + +<p>This is not supported by the definition of use_facet<>, and represents semantics +from an old draft. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.1.1 [locale], paragraph 4, delete the parenthesized +expression </p> + +<blockquote> + <p>(or, failing that, in the global locale) </p> +</blockquote> + + + + + +<hr> +<h3><a name="38"></a>38. Facet definition incomplete</h3> +<p><b>Section:</b> 22.1.2 [locale.global.templates] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>It has been noticed by Esa Pulkkinen that the definition of +"facet" is incomplete. In particular, a class derived from +another facet, but which does not define a member <i>id</i>, cannot +safely serve as the argument <i>F</i> to use_facet<F>(loc), +because there is no guarantee that a reference to the facet instance +stored in <i>loc</i> is safely convertible to <i>F</i>. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In the definition of std::use_facet<>(), replace the text in paragraph 1 which +reads: </p> + +<blockquote> + <p>Get a reference to a facet of a locale. </p> +</blockquote> + +<p>with: </p> + +<blockquote> + <p>Requires: <tt>Facet</tt> is a facet class whose definition + contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 [locale.facet]. </p> +</blockquote> + +<p><i>[ +Kona: strike as overspecification the text "(not inherits)" +from the original resolution, which read "... whose definition +contains (not inherits) the public static member +<tt>id</tt>..." +]</i></p> + + + + + + + +<hr> +<h3><a name="39"></a>39. istreambuf_iterator<>::operator++(int) definition garbled</h3> +<p><b>Section:</b> 24.5.3.4 [istreambuf.iterator::op++] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Following the definition of istreambuf_iterator<>::operator++(int) in paragraph +3, the standard contains three lines of garbage text left over from a previous edit. </p> + +<blockquote> + <pre>istreambuf_iterator<charT,traits> tmp = *this; +sbuf_->sbumpc(); +return(tmp); </pre> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>In 24.5.3.4 [istreambuf.iterator::op++], delete the three lines of code at the +end of paragraph 3. </p> + + + + + +<hr> +<h3><a name="40"></a>40. Meaningless normative paragraph in examples</h3> +<p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Paragraph 3 of the locale examples is a description of part of an +implementation technique that has lost its referent, and doesn't mean +anything. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Delete 22.2.8 [facets.examples] paragraph 3 which begins "This +initialization/identification system depends...", or (at the +editor's option) replace it with a place-holder to keep the paragraph +numbering the same. </p> + + + + + +<hr> +<h3><a name="41"></a>41. Ios_base needs clear(), exceptions()</h3> +<p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#157">157</a></p> +<p><b>Discussion:</b></p> +<p>The description of ios_base::iword() and pword() in 27.4.2.4 [ios.members.static], say that if they fail, they "set badbit, +which may throw an exception". However, ios_base offers no +interface to set or to test badbit; those interfaces are defined in +basic_ios<>. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the description in 27.4.2.5 [ios.base.storage] in +paragraph 2, and also in paragraph 4, as follows. Replace</p> + +<blockquote> + <p>If the function fails it sets badbit, which may throw an exception.</p> +</blockquote> + +<p>with</p> + +<blockquote> + <p>If the function fails, and <tt>*this</tt> is a base sub-object of + a <tt>basic_ios<></tt> object or sub-object, the effect is + equivalent to calling <tt>basic_ios<>::setstate(badbit)</tt> + on the derived object (which may throw <tt>failure</tt>).</p> +</blockquote> + +<p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to +setstate(badbit).]</i></p> + + + + + + + +<hr> +<h3><a name="42"></a>42. String ctors specify wrong default allocator</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#TC">TC</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#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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The basic_string<> copy constructor: </p> + +<pre>basic_string(const basic_string& str, size_type pos = 0, + size_type n = npos, const Allocator& a = Allocator()); </pre> + +<p>specifies an Allocator argument default value that is +counter-intuitive. The natural choice for a the allocator to copy from +is str.get_allocator(). Though this cannot be expressed in +default-argument notation, overloading suffices. </p> + +<p>Alternatively, the other containers in Clause 23 (deque, list, +vector) do not have this form of constructor, so it is inconsistent, +and an evident source of confusion, for basic_string<> to have +it, so it might better be removed. </p> + + +<p><b>Proposed resolution:</b></p> +<p> In 21.3 [basic.string], replace the declaration of the copy +constructor as follows: </p> + +<blockquote> + <pre>basic_string(const basic_string& str); +basic_string(const basic_string& str, size_type pos, size_type n = npos, + const Allocator& a = Allocator());</pre> +</blockquote> + +<p>In 21.3.1 [string.require], replace the copy constructor declaration +as above. Add to paragraph 5, Effects:</p> + +<blockquote> + <p>In the first form, the Allocator value used is copied from + <tt>str.get_allocator()</tt>.</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>The LWG believes the constructor is actually broken, rather than +just an unfortunate design choice.</p> + +<p>The LWG considered two other possible resolutions:</p> + +<p>A. In 21.3 [basic.string], replace the declaration of the copy +constructor as follows:</p> + +<blockquote> + <pre>basic_string(const basic_string& str, size_type pos = 0, + size_type n = npos); +basic_string(const basic_string& str, size_type pos, + size_type n, const Allocator& a); </pre> +</blockquote> + +<p>In 21.3.1 [string.require], replace the copy constructor declaration +as above. Add to paragraph 5, Effects: </p> + +<blockquote> + <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the + value <tt>str.get_allocator()</tt>. </p> +</blockquote> + +<p>B. In 21.3 [basic.string], and also in 21.3.1 [string.require], replace +the declaration of the copy constructor as follows: </p> + +<blockquote> + <pre>basic_string(const basic_string& str, size_type pos = 0, + size_type n = npos); </pre> +</blockquote> + +<p>The proposed resolution reflects the original intent of the LWG. It +was also noted by Pete Becker that this fix "will cause +a small amount of existing code to now work correctly."</p> + +<p><i>[ +Kona: issue editing snafu fixed - the proposed resolution now correctly +reflects the LWG consensus. +]</i></p> + + + + + + +<hr> +<h3><a name="44"></a>44. Iostreams use operator== on int_type values</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#WP">WP</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Many of the specifications for iostreams specify that character +values or their int_type equivalents are compared using operators == +or !=, though in other places traits::eq() or traits::eq_int_type is +specified to be used throughout. This is an inconsistency; we should +change uses of == and != to use the traits members instead. </p> + + +<p><b>Proposed resolution:</b></p> + +<p><i>[Pre-Kona: Dietmar supplied wording]</i></p> + + +<p>List of changes to clause 27:</p> +<ol> +<li> + In lib.basic.ios.members paragraph 13 (postcondition clause for + 'fill(cT)') change + +<blockquote><pre> fillch == fill() +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(fillch, fill()) +</pre></blockquote> + + +</li> +<li> + In lib.istream.unformatted paragraph 7 (effects clause for + 'get(cT,streamsize,cT)'), third bullet, change + +<blockquote><pre> c == delim for the next available input character c +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(c, delim) for the next available input character c +</pre></blockquote> + +</li> +<li> + In lib.istream.unformatted paragraph 12 (effects clause for + 'get(basic_streambuf<cT,Tr>&,cT)'), third bullet, change + +<blockquote><pre> c == delim for the next available input character c +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(c, delim) for the next available input character c +</pre></blockquote> + +</li> +<li> + In lib.istream.unformatted paragraph 17 (effects clause for + 'getline(cT,streamsize,cT)'), second bullet, change + +<blockquote><pre> c == delim for the next available input character c +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(c, delim) for the next available input character c + </pre></blockquote> + +</li> +<li> + In lib.istream.unformatted paragraph 24 (effects clause for + 'ignore(int,int_type)'), second bullet, change + +<blockquote><pre> c == delim for the next available input character c +</pre></blockquote> + + to + +<blockquote><pre> traits::eq_int_type(c, delim) for the next available input + character c +</pre></blockquote> + +</li> +<li> + In lib.istream.unformatted paragraph 25 (notes clause for + 'ignore(int,int_type)'), second bullet, change + +<blockquote><pre> The last condition will never occur if delim == traits::eof() +</pre></blockquote> + + to + +<blockquote><pre> The last condition will never occur if + traits::eq_int_type(delim, traits::eof()). +</pre></blockquote> + +</li> +<li> + In lib.istream.sentry paragraph 6 (example implementation for the + sentry constructor) change + +<blockquote><pre> while ((c = is.rdbuf()->snextc()) != traits::eof()) { +</pre></blockquote> + + to + +<blockquote><pre> while (!traits::eq_int_type(c = is.rdbuf()->snextc(), traits::eof())) { +</pre></blockquote> + +</li> +</ol> + +<p>List of changes to Chapter 21:</p> + +<ol> +<li> + In lib.string::find paragraph 1 (effects clause for find()), + second bullet, change + +<blockquote><pre> at(xpos+I) == str.at(I) for all elements ... +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ... +</pre></blockquote> + +</li> +<li> + In lib.string::rfind paragraph 1 (effects clause for rfind()), + second bullet, change + +<blockquote><pre> at(xpos+I) == str.at(I) for all elements ... +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ... +</pre></blockquote> + +</li> +<li> + In lib.string::find.first.of paragraph 1 (effects clause for + find_first_of()), second bullet, change + +<blockquote><pre> at(xpos+I) == str.at(I) for all elements ... +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ... +</pre></blockquote> + +</li> +<li> + In lib.string::find.last.of paragraph 1 (effects clause for + find_last_of()), second bullet, change + +<blockquote><pre> at(xpos+I) == str.at(I) for all elements ... +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ... +</pre></blockquote> + +</li> +<li> + In lib.string::find.first.not.of paragraph 1 (effects clause for + find_first_not_of()), second bullet, change + +<blockquote><pre> at(xpos+I) == str.at(I) for all elements ... +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ... +</pre></blockquote> +</li> + +<li> + In lib.string::find.last.not.of paragraph 1 (effects clause for + find_last_not_of()), second bullet, change + +<blockquote><pre> at(xpos+I) == str.at(I) for all elements ... +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ... +</pre></blockquote> +</li> + +<li> + In lib.string.ios paragraph 5 (effects clause for getline()), + second bullet, change + +<blockquote><pre> c == delim for the next available input character c +</pre></blockquote> + + to + +<blockquote><pre> traits::eq(c, delim) for the next available input character c +</pre></blockquote> +</li> + +</ol> + +<p>Notes:</p> +<ul> +<li> + Fixing this issue highlights another sloppyness in + lib.istream.unformatted paragraph 24: this clause mentions a "character" + which is then compared to an 'int_type' (see item 5. in the list + below). It is not clear whether this requires explicit words and + if so what these words are supposed to be. A similar issue exists, + BTW, for operator*() of istreambuf_iterator which returns the result + of sgetc() as a character type (see lib.istreambuf.iterator::op* + paragraph 1), and for operator++() of istreambuf_iterator which + passes the result of sbumpc() to a constructor taking a char_type + (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the + assignment operator ostreambuf_iterator passes a char_type to a function + taking an int_type (see lib.ostreambuf.iter.ops paragraph 1). +</li> +<li> + It is inconsistent to use comparisons using the traits functions in + Chapter 27 while not using them in Chapter 21, especially as some + of the inconsistent uses actually involve streams (eg. getline() on + streams). To avoid leaving this issue open still longer due to this + inconsistency (it is open since 1998), a list of changes to Chapter + 21 is below. +</li> +<li> + In Chapter 24 there are several places with statements like "the end + of stream is reached (streambuf_type::sgetc() returns traits::eof())" + (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops + paragraph 5). It is unclear whether these should be clarified to use + traits::eq_int_type() for detecting traits::eof(). +</li> +</ul> + + + + + + +<hr> +<h3><a name="46"></a>46. Minor Annex D errors</h3> +<p><b>Section:</b> D.7 [depr.str.strstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p><p>See lib-6522 and edit-814.</p> + +<p><b>Proposed resolution:</b></p> +<p>Change D.7.1 [depr.strstreambuf] (since streambuf is a typedef of +basic_streambuf<char>) from:</p> + +<pre> virtual streambuf<char>* setbuf(char* s, streamsize n);</pre> + +<p>to:</p> + +<pre> virtual streambuf* setbuf(char* s, streamsize n);</pre> + +<p>In D.7.4 [depr.strstream] insert the semicolon now missing after +int_type:</p> + +<pre> namespace std { + class strstream + : public basic_iostream<char> { + public: + // Types + typedef char char_type; + typedef typename char_traits<char>::int_type int_type + typedef typename char_traits<char>::pos_type pos_type;</pre> + + + + + +<hr> +<h3><a name="47"></a>47. Imbue() and getloc() Returns clauses swapped</h3> +<p><b>Section:</b> 27.4.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That +section has two RETURNS clauses, and they make no sense as +stated. They make perfect sense, though, if you swap them. Am I +correct in thinking that paragraphs 2 and 4 just got mixed up by +accident?</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.4.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p> + + + + + +<hr> +<h3><a name="48"></a>48. Use of non-existent exception constructor</h3> +<p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.4.2.1.1, paragraph 2, says that class failure initializes the +base class, exception, with exception(msg). Class exception (see +18.6.1) has no such constructor.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace 27.4.2.1.1 [ios::failure], paragraph 2, with</p> + +<blockquote> + <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p> +</blockquote> + + + + + +<hr> +<h3><a name="49"></a>49. Underspecification of ios_base::sync_with_stdio</h3> +<p><b>Section:</b> 27.4.2.4 [ios.members.static] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Two problems</p> + +<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f) +returns. Does it return f, or does it return the previous +synchronization state? My guess is the latter, but the standard +doesn't say so.</p> + +<p>(2) 27.4.2.4 doesn't say what it means for streams to be +synchronized with stdio. Again, of course, I can make some +guesses. (And I'm unhappy about the performance implications of those +guesses, but that's another matter.)</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the following sentence in 27.4.2.4 [ios.members.static] +returns clause from:</p> + +<blockquote> + <p><tt>true</tt> if the standard iostream objects (27.3) are + synchronized and otherwise returns <tt>false</tt>.</p> +</blockquote> + +<p>to:</p> + +<blockquote> + <p><tt>true</tt> if the previous state of the standard iostream + objects (27.3) was synchronized and otherwise returns + <tt>false</tt>.</p> +</blockquote> + +<p>Add the following immediately after 27.4.2.4 [ios.members.static], +paragraph 2:</p> + +<blockquote> +<p>When a standard iostream object str is <i>synchronized</i> with a +standard stdio stream f, the effect of inserting a character c by</p> +<pre> fputc(f, c); +</pre> + +<p>is the same as the effect of</p> +<pre> str.rdbuf()->sputc(c); +</pre> + +<p>for any sequence of characters; the effect of extracting a +character c by</p> +<pre> c = fgetc(f); +</pre> + +<p>is the same as the effect of:</p> +<pre> c = str.rdbuf()->sbumpc(c); +</pre> + +<p>for any sequences of characters; and the effect of pushing +back a character c by</p> +<pre> ungetc(c, f); +</pre> + +<p>is the same as the effect of</p> +<pre> str.rdbuf()->sputbackc(c); +</pre> + +<p>for any sequence of characters. [<i>Footnote</i>: This implies +that operations on a standard iostream object can be mixed arbitrarily +with operations on the corresponding stdio stream. In practical +terms, synchronization usually means that a standard iostream object +and a standard stdio object share a buffer. <i>--End Footnote</i>]</p> +</blockquote> + +<p><i>[pre-Copenhagen: PJP and Matt contributed the definition +of "synchronization"]</i></p> + + +<p><i>[post-Copenhagen: proposed resolution was revised slightly: +text was added in the non-normative footnote to say that operations +on the two streams can be mixed arbitrarily.]</i></p> + + + + + + +<hr> +<h3><a name="50"></a>50. Copy constructor and assignment operator of ios_base</h3> +<p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>As written, ios_base has a copy constructor and an assignment +operator. (Nothing in the standard says it doesn't have one, and all +classes have copy constructors and assignment operators unless you +take specific steps to avoid them.) However, nothing in 27.4.2 says +what the copy constructor and assignment operator do. </p> + +<p>My guess is that this was an oversight, that ios_base is, like +basic_ios, not supposed to have a copy constructor or an assignment +operator.</p> + +<p> +Jerry Schwarz comments: Yes, its an oversight, but in the opposite +sense to what you're suggesting. At one point there was a definite +intention that you could copy ios_base. It's an easy way to save the +entire state of a stream for future use. As you note, to carry out +that intention would have required a explicit description of the +semantics (e.g. what happens to the iarray and parray stuff). +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.4.2 [ios.base], class ios_base, specify the copy +constructor and operator= members as being private.</p> + + +<p><b>Rationale:</b></p> +<p>The LWG believes the difficulty of specifying correct semantics +outweighs any benefit of allowing ios_base objects to be copyable.</p> + + + + + +<hr> +<h3><a name="51"></a>51. Requirement to not invalidate iterators missing</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#TC">TC</a> + <b>Submitter:</b> David Vandevoorde <b>Date:</b> 1998-06-23</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The std::sort algorithm can in general only sort a given sequence +by moving around values. The list<>::sort() member on the other +hand could move around values or just update internal pointers. Either +method can leave iterators into the list<> dereferencable, but +they would point to different things. </p> + +<p>Does the FDIS mandate anywhere which method should be used for +list<>::sort()?</p> + +<p>Matt Austern comments:</p> + +<p>I think you've found an omission in the standard. </p> + +<p>The library working group discussed this point, and there was +supposed to be a general requirement saying that list, set, map, +multiset, and multimap may not invalidate iterators, or change the +values that iterators point to, except when an operation does it +explicitly. So, for example, insert() doesn't invalidate any iterators +and erase() and remove() only invalidate iterators pointing to the +elements that are being erased. </p> + +<p>I looked for that general requirement in the FDIS, and, while I +found a limited form of it for the sorted associative containers, I +didn't find it for list. It looks like it just got omitted. </p> + +<p>The intention, though, is that list<>::sort does not +invalidate any iterators and does not change the values that any +iterator points to. There would be no reason to have the member +function otherwise.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add a new paragraph at the end of 23.1:</p> + +<blockquote> + <p>Unless otherwise specified (either explicitly or by defining a function in terms of + other functions), invoking a container member function or passing a container as an + argument to a library function shall not invalidate iterators to, or change the values of, + objects within that container. </p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>This was US issue CD2-23-011; it was accepted in London but the +change was not made due to an editing oversight. The wording in the +proposed resolution below is somewhat updated from CD2-23-011, +particularly the addition of the phrase "or change the values +of"</p> + + + + + +<hr> +<h3><a name="52"></a>52. Small I/O problems</h3> +<p><b>Section:</b> 27.4.3.2 [fpos.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>First, 27.4.4.1 [basic.ios.cons], table 89. This is pretty obvious: +it should be titled "basic_ios<>() effects", not +"ios_base() effects". </p> + +<p>[The second item is a duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#6">6</a> for +resolution.]</p> + +<p>Second, 27.4.3.2 [fpos.operations] table 88 . There are a couple +different things wrong with it, some of which I've already discussed +with Jerry, but the most obvious mechanical sort of error is that it +uses expressions like P(i) and p(i), without ever defining what sort +of thing "i" is. +</p> + +<p>(The other problem is that it requires support for streampos +arithmetic. This is impossible on some systems, i.e. ones where file +position is a complicated structure rather than just a number. Jerry +tells me that the intention was to require syntactic support for +streampos arithmetic, but that it wasn't actually supposed to do +anything meaningful except on platforms, like Unix, where genuine +arithmetic is possible.) </p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 27.4.4.1 [basic.ios.cons] table 89 title from +"ios_base() effects" to "basic_ios<>() +effects". </p> + + + + + +<hr> +<h3><a name="53"></a>53. Basic_ios destructor unspecified</h3> +<p><b>Section:</b> 27.4.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>There's nothing in 27.4.4 saying what basic_ios's destructor does. +The important question is whether basic_ios::~basic_ios() destroys +rdbuf().</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add after 27.4.4.1 [basic.ios.cons] paragraph 2:</p> + +<blockquote> + <p><tt>virtual ~basic_ios();</tt></p> + <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>The LWG reviewed the additional question of whether or not +<tt>rdbuf(0)</tt> may set <tt>badbit</tt>. The answer is +clearly yes; it may be set via <tt>clear()</tt>. See 27.4.4.2 [basic.ios.members], paragraph 6. This issue was reviewed at length +by the LWG, which removed from the original proposed resolution a +footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set +<tt>badbit</tt>".</p> + + + + + +<hr> +<h3><a name="54"></a>54. Basic_streambuf's destructor</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#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-25</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The class synopsis for basic_streambuf shows a (virtual) +destructor, but the standard doesn't say what that destructor does. My +assumption is that it does nothing, but the standard should say so +explicitly. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Add after 27.5.2.1 [streambuf.cons] paragraph 2:</p> + +<blockquote> + <p><tt>virtual ~basic_streambuf();</tt></p> + <p><b>Effects</b>: None.</p> +</blockquote> + + + + + +<hr> +<h3><a name="55"></a>55. Invalid stream position is undefined</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#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-26</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Several member functions in clause 27 are defined in certain +circumstances to return an "invalid stream position", a term +that is defined nowhere in the standard. Two places (27.5.2.4.2, +paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to +a definition in _lib.iostreams.definitions_, a nonexistent +section. </p> + +<p>I suspect that the invalid stream position is just supposed to be +pos_type(-1). Probably best to say explicitly in (for example) +27.5.2.4.2 that the return value is pos_type(-1), rather than to use +the term "invalid stream position", define that term +somewhere, and then put in a cross-reference. </p> + +<p>The phrase "invalid stream position" appears ten times in +the C++ Standard. In seven places it refers to a return value, and it +should be changed. In three places it refers to an argument, and it +should not be changed. Here are the three places where "invalid +stream position" should not be changed:</p> + +<blockquote> + <p>27.7.1.4 [stringbuf.virtuals], paragraph 14<br> + 27.8.1.5 [filebuf.virtuals], paragraph 14<br> + D.7.1.3 [depr.strstreambuf.virtuals], paragraph 17 + </p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an +object of class pos_type that stores an invalid stream position +(_lib.iostreams.definitions_)" to "Returns +<tt>pos_type(off_type(-1))</tt>". +</p> + +<p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns +an object of class pos_type that stores an invalid stream +position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p> + +<p>In 27.7.1.4 [stringbuf.virtuals], paragraph 13, change "the object +stores an invalid stream position" to "the return value is +<tt>pos_type(off_type(-1))</tt>". </p> + +<p>In 27.8.1.5 [filebuf.virtuals], paragraph 13, change "returns an +invalid stream position (27.4.3)" to "returns +<tt>pos_type(off_type(-1))</tt>" </p> + +<p>In 27.8.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise +returns an invalid stream position (_lib.iostreams.definitions_)" +to "Otherwise returns <tt>pos_type(off_type(-1))</tt>" +</p> + +<p>In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 15, change "the object +stores an invalid stream position" to "the return value is +<tt>pos_type(off_type(-1))</tt>" </p> + +<p>In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 18, change "the object +stores an invalid stream position" to "the return value is +<tt>pos_type(off_type(-1))</tt>"</p> + + + + + +<hr> +<h3><a name="56"></a>56. Showmanyc's return type</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#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-29</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The class summary for basic_streambuf<>, in 27.5.2, says that +showmanyc has return type int. However, 27.5.2.4.3 says that its +return type is streamsize. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Change <tt>showmanyc</tt>'s return type in the +27.5.2 [streambuf] class summary to <tt>streamsize</tt>.</p> + + + + + +<hr> +<h3><a name="57"></a>57. Mistake in char_traits</h3> +<p><b>Section:</b> 21.1.3.4 [char.traits.specializations.wchar.t] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>21.1.3.2, paragraph 3, says "The types streampos and +wstreampos may be different if the implementation supports no shift +encoding in narrow-oriented iostreams but supports one or more shift +encodings in wide-oriented streams". </p> + +<p>That's wrong: the two are the same type. The <iosfwd> summary +in 27.2 says that streampos and wstreampos are, respectively, synonyms +for fpos<char_traits<char>::state_type> and +fpos<char_traits<wchar_t>::state_type>, and, flipping back +to clause 21, we see in 21.1.3.1 and 21.1.3.2 that +char_traits<char>::state_type and +char_traits<wchar_t>::state_type must both be mbstate_t. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove the sentence in 21.1.3.4 [char.traits.specializations.wchar.t] paragraph 3 which +begins "The types streampos and wstreampos may be +different..." . </p> + + + + + +<hr> +<h3><a name="59"></a>59. Ambiguity in specification of gbump</h3> +<p><b>Section:</b> 27.5.2.3.2 [streambuf.get.area] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-28</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the +next pointer for the input sequence by n." </p> + +<p>The straightforward interpretation is that it is just gptr() += +n. An alternative interpretation, though, is that it behaves as if it +calls sbumpc n times. (The issue, of course, is whether it might ever +call underflow.) There is a similar ambiguity in the case of +pbump. </p> + +<p>(The "classic" AT&T implementation used the +former interpretation.)</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 27.5.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:</p> + +<blockquote> + <p>Effects: Advances the next pointer for the input sequence by n.</p> +</blockquote> + +<p>to:</p> + +<blockquote> + <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p> +</blockquote> + +<p>Make the same change to 27.5.2.3.3 [streambuf.put.area] paragraph 4 pbump +effects.</p> + + + + + +<hr> +<h3><a name="60"></a>60. What is a formatted input function?</h3> +<p><b>Section:</b> 27.6.1.2.1 [istream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#163">163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a></p> +<p><b>Discussion:</b></p> +<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all +formatted input functions. Some of the functions defined in section +27.6.1.2 explicitly say that those requirements apply ("Behaves +like a formatted input member (as described in 27.6.1.2.1)"), but +others don't. The question: is 27.6.1.2.1 supposed to apply to +everything in 27.6.1.2, or only to those member functions that +explicitly say "behaves like a formatted input member"? Or +to put it differently: are we to assume that everything that appears +in a section called "Formatted input functions" really is a +formatted input function? I assume that 27.6.1.2.1 is intended to +apply to the arithmetic extractors (27.6.1.2.2), but I assume that it +is not intended to apply to extractors like </p> + +<pre> basic_istream& operator>>(basic_istream& (*pf)(basic_istream&));</pre> + +<p>and </p> + +<pre> basic_istream& operator>>(basic_streammbuf*);</pre> + +<p>There is a similar ambiguity for unformatted input, formatted output, and unformatted +output. </p> + +<p>Comments from Judy Ward: It seems like the problem is that the +basic_istream and basic_ostream operator <<()'s that are used +for the manipulators and streambuf* are in the wrong section and +should have their own separate section or be modified to make it clear +that the "Common requirements" listed in section 27.6.1.2.1 +(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not +apply to them. </p> + +<p>Additional comments from Dietmar Kühl: It appears to be somewhat +nonsensical to consider the functions defined in 27.6.1.2.3 +[istream::extractors] paragraphs 1 to 5 to be "Formatted input +function" but since these functions are defined in a section +labeled "Formatted input functions" it is unclear to me +whether these operators are considered formatted input functions which +have to conform to the "common requirements" from 27.6.1.2.1 +[istream.formatted.reqmts]: If this is the case, all manipulators, not +just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is +set (... but setting <tt>noskipws</tt> using the manipulator syntax +would also skip whitespace :-)</p> <p>It is not clear which functions +are to be considered unformatted input functions. As written, it seems +that all functions in 27.6.1.3 [istream.unformatted] are unformatted input +functions. However, it does not really make much sense to construct a +sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is +unclear what happens to the <tt>gcount()</tt> if +eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or +<tt>sync()</tt> is called: These functions don't extract characters, +some of them even "unextract" a character. Should this still +be reflected in <tt>gcount()</tt>? Of course, it could be read as if +after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> +(the last unformatted input function, <tt>gcount()</tt>, didn't +extract any character) and after a call to <tt>putback()</tt> +<tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input +function <tt>putback()</tt> did "extract" back into the +stream). Correspondingly for <tt>unget()</tt>. Is this what is +intended? If so, this should be clarified. Otherwise, a corresponding +clarification should be used.</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1. +Change the beginning of the second sentence from "The conversion +occurs" to "These extractors behave as formatted input functions (as +described in 27.6.1.2.1). After a sentry object is constructed, +the conversion occurs" +</p> + +<p> +In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1. +Add an effects clause. "Effects: None. This extractor does +not behave as a formatted input function (as described in +27.6.1.2.1). +</p> + +<p> +In 27.6.1.2.3, [lib.istream::extractors], paragraph 2. Change the +effects clause to "Effects: Calls pf(*this). This extractor does not +behave as a formatted input function (as described in 27.6.1.2.1). +</p> + +<p> +In 27.6.1.2.3, [lib.istream::extractors], paragraph 4. Change the +effects clause to "Effects: Calls pf(*this). This extractor does not +behave as a formatted input function (as described in 27.6.1.2.1). +</p> + +<p> +In 27.6.1.2.3, [lib.istream::extractors], paragraph 12. Change the +first two sentences from "If sb is null, calls setstate(failbit), +which may throw ios_base::failure (27.4.4.3). Extracts characters +from *this..." to "Behaves as a formatted input function (as described +in 27.6.1.2.1). If sb is null, calls setstate(failbit), which may +throw ios_base::failure (27.4.4.3). After a sentry object is +constructed, extracts characters from *this...". +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], before paragraph 2. Add an +effects clause. "Effects: none. This member function does not behave +as an unformatted input function (as described in 27.6.1.3, paragraph 1)." +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 3. Change the +beginning of the first sentence of the effects clause from "Extracts a +character" to "Behaves as an unformatted input function (as described +in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a +character" +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the +beginning of the first sentence of the effects clause from "Extracts a +character" to "Behaves as an unformatted input function (as described +in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a +character" +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 7. Change the +beginning of the first sentence of the effects clause from "Extracts +characters" to "Behaves as an unformatted input function (as described +in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts +characters" +</p> + +<p> +[No change needed in paragraph 10, because it refers to paragraph 7.] +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 12. Change the +beginning of the first sentence of the effects clause from "Extracts +characters" to "Behaves as an unformatted input function (as described +in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts +characters" +</p> + +<p> +[No change needed in paragraph 15.] +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 17. Change the +beginning of the first sentence of the effects clause from "Extracts +characters" to "Behaves as an unformatted input function (as described +in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts +characters" +</p> + +<p> +[No change needed in paragraph 23.] +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 24. Change the +beginning of the first sentence of the effects clause from "Extracts +characters" to "Behaves as an unformatted input function (as described +in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts +characters" +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], before paragraph 27. Add an +Effects clause: "Effects: Behaves as an unformatted input function (as +described in 27.6.1.3, paragraph 1). After constructing a sentry +object, reads but does not extract the current input character." +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 28. Change the +first sentence of the Effects clause from "If !good() calls" to +Behaves as an unformatted input function (as described in 27.6.1.3, +paragraph 1). After constructing a sentry object, if !good() calls" +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 30. Change the +first sentence of the Effects clause from "If !good() calls" to +"Behaves as an unformatted input function (as described in 27.6.1.3, +paragraph 1). After constructing a sentry object, if !good() calls" +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 32. Change the +first sentence of the Effects clause from "If !good() calls..." to +"Behaves as an unformatted input function (as described in 27.6.1.3, +paragraph 1). After constructing a sentry object, if !good() +calls..." Add a new sentence to the end of the Effects clause: +"[Note: this function extracts no characters, so the value returned +by the next call to gcount() is 0.]" +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 34. Change the +first sentence of the Effects clause from "If !good() calls" to +"Behaves as an unformatted input function (as described in 27.6.1.3, +paragraph 1). After constructing a sentry object, if !good() calls". +Add a new sentence to the end of the Effects clause: "[Note: this +function extracts no characters, so the value returned by the next +call to gcount() is 0.]" +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 36. Change the +first sentence of the Effects clause from "If !rdbuf() is" to "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 rdbuf() is" +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], before paragraph 37. Add an +Effects clause: "Effects: 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()." Change the first sentence of +paragraph 37 from "if fail()" to "after constructing a sentry object, +if fail()". +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 38. Change the +first sentence of the Effects clause from "If fail()" to "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() +</p> + +<p> +In 27.6.1.3, [lib.istream.unformatted], paragraph 40. Change the +first sentence of the Effects clause from "If fail()" to "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() +</p> + +<p> +In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1. Change +the beginning of the third sentence from "The formatting conversion" +to "These extractors behave as formatted output functions (as +described in 27.6.2.5.1). After the sentry object is constructed, the +conversion occurs". +</p> + +<p> +In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1. Add an +effects clause: "Effects: None. Does not behave as a formatted output +function (as described in 27.6.2.5.1).". +</p> + +<p> +In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2. Change the +effects clause to "Effects: calls pf(*this). This extractor does not +behave as a formatted output function (as described in 27.6.2.5.1).". +</p> + +<p> +In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4. Change the +effects clause to "Effects: calls pf(*this). This extractor does not +behave as a formatted output function (as described in 27.6.2.5.1).". +</p> + +<p> +In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6. Change the first +sentence from "If sb" to "Behaves as a formatted output function (as +described in 27.6.2.5.1). After the sentry object is constructed, if +sb". +</p> + +<p> +In 27.6.2.6 [lib.ostream.unformatted], paragraph 2. Change the first +sentence from "Inserts the character" to "Behaves as an unformatted +output function (as described in 27.6.2.6, paragraph 1). After +constructing a sentry object, inserts the character". +</p> + +<p> +In 27.6.2.6 [lib.ostream.unformatted], paragraph 5. Change the first +sentence from "Obtains characters" to "Behaves as an unformatted +output function (as described in 27.6.2.6, paragraph 1). After +constructing a sentry object, obtains characters". +</p> + +<p> +In 27.6.2.6 [lib.ostream.unformatted], paragraph 7. Add a new +sentence at the end of the paragraph: "Does not behave as an +unformatted output function (as described in 27.6.2.6, paragraph 1)." +</p> + + +<p><b>Rationale:</b></p> +<p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60, +by Judy Ward and Matt Austern. This proposed resolution is section +VI of that paper.</p> + + + + + +<hr> +<h3><a name="61"></a>61. Ambiguity in iostreams exception policy</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#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The introduction to the section on unformatted input (27.6.1.3) +says that every unformatted input function catches all exceptions that +were thrown during input, sets badbit, and then conditionally rethrows +the exception. That seems clear enough. Several of the specific +functions, however, such as get() and read(), are documented in some +circumstances as setting eofbit and/or failbit. (The standard notes, +correctly, that setting eofbit or failbit can sometimes result in an +exception being thrown.) The question: if one of these functions +throws an exception triggered by setting failbit, is this an exception +"thrown during input" and hence covered by 27.6.1.3, or does +27.6.1.3 only refer to a limited class of exceptions? Just to make +this concrete, suppose you have the following snippet. </p> + +<pre> + char buffer[N]; + istream is; + ... + is.exceptions(istream::failbit); // Throw on failbit but not on badbit. + is.read(buffer, N);</pre> + +<p>Now suppose we reach EOF before we've read N characters. What +iostate bits can we expect to be set, and what exception (if any) will +be thrown? </p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 27.6.1.3, paragraph 1, after the sentence that begins +"If an exception is thrown...", add the following +parenthetical comment: "(Exceptions thrown from +<tt>basic_ios<>::clear()</tt> are not caught or rethrown.)" +</p> + + +<p><b>Rationale:</b></p> +<p>The LWG looked to two alternative wordings, and choose the proposed +resolution as better standardese.</p> + + + + + +<hr> +<h3><a name="62"></a>62. <tt>Sync</tt>'s return value</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#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it +"calls rdbuf()->pubsync() and, if that function returns -1 +... returns traits::eof()." </p> + +<p>That looks suspicious, because traits::eof() is of type +traits::int_type while the return type of sync() is int. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.6.1.3 [istream.unformatted], paragraph 36, change "returns +<tt>traits::eof()</tt>" to "returns <tt>-1</tt>". +</p> + + + + + +<hr> +<h3><a name="63"></a>63. Exception-handling policy for unformatted output</h3> +<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Clause 27 details an exception-handling policy for formatted input, +unformatted input, and formatted output. It says nothing for +unformatted output (27.6.2.6). 27.6.2.6 should either include the same +kind of exception-handling policy as in the other three places, or +else it should have a footnote saying that the omission is +deliberate. </p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 27.6.2.6, paragraph 1, replace the last sentence ("In any +case, the unformatted output function ends by destroying the sentry +object, then returning the value specified for the formatted output +function.") with the following text: +</p> +<blockquote><p> +If an exception is thrown during output, then <tt>ios::badbit</tt> is +turned on [Footnote: without causing an <tt>ios::failure</tt> to be +thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() & +badbit) != 0</tt> then the exception is rethrown. In any case, the +unformatted output function ends by destroying the sentry object, +then, if no exception was thrown, returning the value specified for +the formatted output function. +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p> +This exception-handling policy is consistent with that of formatted +input, unformatted input, and formatted output. +</p> + + + + + +<hr> +<h3><a name="64"></a>64. Exception handling in <tt>basic_istream::operator>>(basic_streambuf*)</tt></h3> +<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two +different ways, depending on whether the second sentence is read as an +elaboration of the first. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace 27.6.1.2.3 [istream::extractors], paragraph 13, which begins +"If the function inserts no characters ..." with:</p> + +<blockquote> + <p>If the function inserts no characters, it calls + <tt>setstate(failbit)</tt>, which may throw + <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters + because it caught an exception thrown while extracting characters + from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt> + (27.4.4.3), then the caught exception is rethrown. </p> +</blockquote> + + + + + +<hr> +<h3><a name="66"></a>66. Strstreambuf::setbuf</h3> +<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf +"Performs an operation that is defined separately for each class +derived from strstreambuf". This is obviously an incorrect +cut-and-paste from basic_streambuf. There are no classes derived from +strstreambuf. </p> + + +<p><b>Proposed resolution:</b></p> +<p>D.7.1.3 [depr.strstreambuf.virtuals], paragraph 19, replace the setbuf effects +clause which currently says "Performs an operation that is +defined separately for each class derived from strstreambuf" +with:</p> + +<blockquote> + <p><b>Effects</b>: implementation defined, except that + <tt>setbuf(0,0)</tt> has no effect.</p> +</blockquote> + + + + + +<hr> +<h3><a name="68"></a>68. Extractors for char* should store null at end</h3> +<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-07-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Extractors for char* (27.6.1.2.3) do not store a null character +after the extracted character sequence whereas the unformatted +functions like get() do. Why is this?</p> + +<p>Comment from Jerry Schwarz: There is apparently an editing +glitch. You'll notice that the last item of the list of what stops +extraction doesn't make any sense. It was supposed to be the line that +said a null is stored.</p> + + +<p><b>Proposed resolution:</b></p> +<p>27.6.1.2.3 [istream::extractors], paragraph 7, change the last list +item from:</p> + +<blockquote><p> + A null byte (<tt>charT()</tt>) in the next position, which may be + the first position if no characters were extracted. +</p></blockquote> + +<p>to become a new paragraph which reads:</p> + +<blockquote><p> + Operator>> then stores a null byte (<tt>charT()</tt>) in the + next position, which may be the first position if no characters were + extracted. +</p></blockquote> + + + + + +<hr> +<h3><a name="69"></a>69. Must elements of a vector be contiguous?</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#TC">TC</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1998-07-29</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The issue is this: Must the elements of a vector be in contiguous memory?</p> + +<p>(Please note that this is entirely separate from the question of +whether a vector iterator is required to be a pointer; the answer to +that question is clearly "no," as it would rule out +debugging implementations)</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add the following text to the end of 23.2.6 [vector], +paragraph 1. </p> + +<blockquote> + <p>The elements of a vector are stored contiguously, meaning that if + v is a <tt>vector<T, Allocator></tt> where T is some type + other than <tt>bool</tt>, then it obeys the identity <tt>&v[n] + == &v[0] + n</tt> for all <tt>0 <= n < v.size()</tt>.</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>The LWG feels that as a practical matter the answer is clearly +"yes". There was considerable discussion as to the best way +to express the concept of "contiguous", which is not +directly defined in the standard. Discussion included:</p> + +<ul> + <li>An operational definition similar to the above proposed resolution is + already used for valarray (26.5.2.3 [valarray.access]).</li> + <li>There is no need to explicitly consider a user-defined operator& + because elements must be copyconstructible (23.1 [container.requirements] para 3) + and copyconstructible (20.1.1 [utility.arg.requirements]) specifies + requirements for operator&.</li> + <li>There is no issue of one-past-the-end because of language rules.</li> +</ul> + + + + + +<hr> +<h3><a name="70"></a>70. Uncaught_exception() missing throw() specification</h3> +<p><b>Section:</b> 18.7 [support.exception], 18.7.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-08-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p> + +<p>uncaught_exception() doesn't have a throw specification.</p> + +<p>It is intentional ? Does it means that one should be prepared to +handle exceptions thrown from uncaught_exception() ?</p> + +<p>uncaught_exception() is called in exception handling contexts where +exception safety is very important.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 15.5.3 [except.uncaught], paragraph 1, 18.7 [support.exception], +and 18.7.4 [uncaught], add "throw()" to uncaught_exception().</p> + + + + +<hr> +<h3><a name="71"></a>71. Do_get_monthname synopsis missing argument</h3> +<p><b>Section:</b> 22.2.5.1 [locale.time.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-13</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The locale facet member <tt>time_get<>::do_get_monthname</tt> +is described in 22.2.5.1.2 [locale.time.get.virtuals] with five arguments, +consistent with do_get_weekday and with its specified use by member +get_monthname. However, in the synopsis, it is specified instead with +four arguments. The missing argument is the "end" iterator +value.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.5.1 [locale.time.get], add an "end" argument to +the declaration of member do_monthname as follows:</p> + +<pre> virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&, + ios_base::iostate& err, tm* t) const;</pre> + + + + +<hr> +<h3><a name="74"></a>74. Garbled text for <tt>codecvt::do_max_length</tt></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#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-09-08</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns" +clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced +parentheses and a spurious <b>n</b>.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the +following:</p> + +<blockquote><p> + <b>Returns</b>: The maximum value that + <tt>do_length(state, from, from_end, 1)</tt> can return for any + valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value + <tt>state</tt>. The specialization <tt>codecvt<char, char, + mbstate_t>::do_max_length()</tt> returns 1. +</p></blockquote> + + + + +<hr> +<h3><a name="75"></a>75. Contradiction in <tt>codecvt::length</tt>'s argument types</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#TC">TC</a> + <b>Submitter:</b> Matt +Austern <b>Date:</b> 1998-09-18</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The class synopses for classes <tt>codecvt<></tt> (22.2.1.5) +and <tt>codecvt_byname<></tt> (22.2.1.6) say that the first +parameter of the member functions <tt>length</tt> and +<tt>do_length</tt> is of type <tt>const stateT&</tt>. The member +function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2, +paragraph 9) say that the type is <tt>stateT&</tt>. Either the +synopsis or the summary must be changed. </p> + +<p>If (as I believe) the member function descriptions are correct, +then we must also add text saying how <tt>do_length</tt> changes its +<tt>stateT</tt> argument. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.1.4 [locale.codecvt], and also in 22.2.1.5 [locale.codecvt.byname], +change the <tt>stateT</tt> argument type on both member +<tt>length()</tt> and member <tt>do_length()</tt> from </p> + +<blockquote> + <p><tt>const stateT&</tt></p> +</blockquote> + +<p>to</p> + +<blockquote> + <p><tt>stateT&</tt></p> +</blockquote> + +<p>In 22.2.1.4.2 [locale.codecvt.virtuals], add to the definition for member +<tt>do_length</tt> a paragraph:</p> + +<blockquote> + <p>Effects: The effect on the <tt>state</tt> argument is ``as if'' + it called <tt>do_in(state, from, from_end, from, to, to+max, + to)</tt> for <tt>to</tt> pointing to a buffer of at least + <tt>max</tt> elements.</p> +</blockquote> + + + + +<hr> +<h3><a name="76"></a>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</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#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-09-25</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>This issue concerns the requirements on classes derived from +<tt>codecvt</tt>, including user-defined classes. What are the +restrictions on the conversion from external characters +(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)? +Or, alternatively, what assumptions about <tt>codecvt</tt> facets can +the I/O library make? </p> + +<p>The question is whether it's possible to convert from internal +characters to external characters one internal character at a time, +and whether, given a valid sequence of external characters, it's +possible to pick off internal characters one at a time. Or, to put it +differently: given a sequence of external characters and the +corresponding sequence of internal characters, does a position in the +internal sequence correspond to some position in the external +sequence? </p> + +<p>To make this concrete, suppose that <tt>[first, last)</tt> is a +sequence of <i>M</i> external characters and that <tt>[ifirst, +ilast)</tt> is the corresponding sequence of <i>N</i> internal +characters, where <i>N > 1</i>. That is, <tt>my_encoding.in()</tt>, +applied to <tt>[first, last)</tt>, yields <tt>[ifirst, +ilast)</tt>. Now the question: does there necessarily exist a +subsequence of external characters, <tt>[first, last_1)</tt>, such +that the corresponding sequence of internal characters is the single +character <tt>*ifirst</tt>? +</p> + +<p>(What a "no" answer would mean is that +<tt>my_encoding</tt> translates sequences only as blocks. There's a +sequence of <i>M</i> external characters that maps to a sequence of +<i>N</i> internal characters, but that external sequence has no +subsequence that maps to <i>N-1</i> internal characters.) </p> + +<p>Some of the wording in the standard, such as the description of +<tt>codecvt::do_max_length</tt> (22.2.1.4.2 [locale.codecvt.virtuals], +paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be +possible to pick off internal characters one at a time from a sequence +of external characters. However, this is never explicitly stated one +way or the other. </p> + +<p>This issue seems (and is) quite technical, but it is important if +we expect users to provide their own encoding facets. This is an area +where the standard library calls user-supplied code, so a well-defined +set of requirements for the user-supplied code is crucial. Users must +be aware of the assumptions that the library makes. This issue affects +positioning operations on <tt>basic_filebuf</tt>, unbuffered input, +and several of <tt>codecvt</tt>'s member functions. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Add the following text as a new paragraph, following 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 2:</p> + +<blockquote> +<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt> +(27.8 [file.streams]) must have the property that if</p> +<pre> do_out(state, from, from_end, from_next, to, to_lim, to_next) +</pre> +<p>would return <tt>ok</tt>, where <tt>from != from_end</tt>, then </p> +<pre> do_out(state, from, from + 1, from_next, to, to_end, to_next) +</pre> +<p>must also return <tt>ok</tt>, and that if</p> +<pre> do_in(state, from, from_end, from_next, to, to_lim, to_next) +</pre> +<p>would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then</p> +<pre> do_in(state, from, from_end, from_next, to, to + 1, to_next) +</pre> +<p>must also return <tt>ok</tt>. [<i>Footnote:</i> Informally, this +means that <tt>basic_filebuf</tt> assumes that the mapping from +internal to external characters is 1 to N: a <tt>codecvt</tt> that is +used by <tt>basic_filebuf</tt> must be able to translate characters +one internal character at a time. <i>--End Footnote</i>]</p> +</blockquote> + +<p><i>[Redmond: Minor change in proposed resolution. Original +proposed resolution talked about "success", with a parenthetical +comment that success meant returning <tt>ok</tt>. New wording +removes all talk about "success", and just talks about the +return value.]</i></p> + + + + +<p><b>Rationale:</b></p> + + <p>The proposed resoluion says that conversions can be performed one + internal character at a time. This rules out some encodings that + would otherwise be legal. The alternative answer would mean there + would be some internal positions that do not correspond to any + external file position.</p> + <p> + An example of an encoding that this rules out is one where the + <tt>internT</tt> and <tt>externT</tt> are of the same type, and + where the internal sequence <tt>c1 c2</tt> corresponds to the + external sequence <tt>c2 c1</tt>. + </p> + <p>It was generally agreed that <tt>basic_filebuf</tt> relies + on this property: it was designed under the assumption that + the external-to-internal mapping is N-to-1, and it is not clear + that <tt>basic_filebuf</tt> is implementable without that + restriction. + </p> + <p> + The proposed resolution is expressed as a restriction on + <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather + than a blanket restriction on all <tt>codecvt</tt> facets, + because <tt>basic_filebuf</tt> is the only other part of the + library that uses <tt>codecvt</tt>. If a user wants to define + a <tt>codecvt</tt> facet that implements a more general N-to-M + mapping, there is no reason to prohibit it, so long as the user + does not expect <tt>basic_filebuf</tt> to be able to use it. + </p> + + + + + +<hr> +<h3><a name="78"></a>78. Typo: event_call_back</h3> +<p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>typo: event_call_back should be event_callback </p> + + +<p><b>Proposed resolution:</b></p> +<p>In the 27.4.2 [ios.base] synopsis change +"event_call_back" to "event_callback". </p> + + + + +<hr> +<h3><a name="79"></a>79. Inconsistent declaration of polar()</h3> +<p><b>Section:</b> 26.3.1 [complex.synopsis], 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.synopsis">issues</a> in [complex.synopsis].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 26.3.1 [complex.synopsis] polar is declared as follows:</p> +<pre> template<class T> complex<T> polar(const T&, const T&); </pre> + +<p>In 26.3.7 [complex.value.ops] it is declared as follows:</p> +<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre> + +<p>Thus whether the second parameter is optional is not clear. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 26.3.1 [complex.synopsis] change:</p> +<pre> template<class T> complex<T> polar(const T&, const T&);</pre> + +<p>to:</p> +<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre> + + + + + +<hr> +<h3><a name="80"></a>80. Global Operators of complex declared twice</h3> +<p><b>Section:</b> 26.3.1 [complex.synopsis], 26.3.2 [complex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.synopsis">issues</a> in [complex.synopsis].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for +class complex. This redundancy should be removed.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Reduce redundancy according to the general style of the standard. </p> + + + + +<hr> +<h3><a name="83"></a>83. String::npos vs. string::max_size()</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#TC">TC</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</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#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#89">89</a></p> +<p><b>Discussion:</b></p> +<p>Many string member functions throw if size is getting or exceeding +npos. However, I wonder why they don't throw if size is getting or +exceeding max_size() instead of npos. May be npos is known at compile +time, while max_size() is known at runtime. However, what happens if +size exceeds max_size() but not npos, then? It seems the standard +lacks some clarifications here.</p> + + +<p><b>Proposed resolution:</b></p> +<p>After 21.3 [basic.string] paragraph 4 ("The functions +described in this clause...") add a new paragraph:</p> + +<blockquote> + <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed + <tt> max_size()</tt> then + the operation throws <tt>length_error</tt>.</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>The LWG believes length_error is the correct exception to throw.</p> + + + + +<hr> +<h3><a name="86"></a>86. String constructors don't describe exceptions</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#TC">TC</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The constructor from a range:</p> + +<pre>template<class InputIterator> + basic_string(InputIterator begin, InputIterator end, + const Allocator& a = Allocator());</pre> + +<p>lacks a throws clause. However, I would expect that it throws +according to the other constructors if the numbers of characters in +the range equals npos (or exceeds max_size(), see above). </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 21.3.1 [string.require], Strike throws paragraphs for +constructors which say "Throws: length_error if n == +npos."</p> + + +<p><b>Rationale:</b></p> +<p>Throws clauses for length_error if n == npos are no longer needed +because they are subsumed by the general wording added by the +resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p> + + + + +<hr> +<h3><a name="90"></a>90. Incorrect description of operator >> for strings</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#TC">TC</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The effect of operator >> for strings contain the following item:</p> + +<p> <tt>isspace(c,getloc())</tt> is true for the next available input +character c.</p> + +<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 21.3.8.9 [string.io] paragraph 1 Effects clause replace:</p> + +<blockquote> + <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p> +</blockquote> + +<p>with:</p> + +<blockquote> + <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p> +</blockquote> + + + + + +<hr> +<h3><a name="91"></a>91. Description of operator>> and getline() for string<> might cause endless loop</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#WP">WP</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Operator >> and getline() for strings read until eof() +in the input stream is true. However, this might never happen, if the +stream can't read anymore without reaching EOF. So shouldn't it be +changed into that it reads until !good() ? </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 21.3.8.9 [string.io], paragraph 1, replace:</p> +<blockquote><p> +Effects: Begins by constructing a sentry object k as if k were +constructed by typename basic_istream<charT,traits>::sentry k( is). If +bool( k) is true, it calls str.erase() and then extracts characters +from is and appends them to str as if by calling str.append(1, c). If +is.width() is greater than zero, the maximum number n of characters +appended is is.width(); otherwise n is str.max_size(). Characters are +extracted and appended until any of the following occurs: +</p></blockquote> +<p>with:</p> +<blockquote><p> +Effects: Behaves as a formatted input function (27.6.1.2.1 +[istream.formatted.reqmts]). After constructing a sentry object, if the +sentry converts to true, calls str.erase() and then extracts +characters from is and appends them to str as if by calling +str.append(1,c). If is.width() is greater than zero, the maximum +number n of characters appended is is.width(); otherwise n is +str.max_size(). Characters are extracted and appended until any of the +following occurs: +</p></blockquote> + +<p>In 21.3.8.9 [string.io], paragraph 6, replace</p> +<blockquote><p> +Effects: Begins by constructing a sentry object k as if by typename +basic_istream<charT,traits>::sentry k( is, true). If bool( k) is true, +it calls str.erase() and then extracts characters from is and appends +them to str as if by calling str.append(1, c) until any of the +following occurs: +</p></blockquote> +<p>with:</p> +<blockquote><p>Effects: Behaves as an unformatted input function +(27.6.1.3 [istream.unformatted]), except that it does not affect the +value returned +by subsequent calls to basic_istream<>::gcount(). After +constructing a sentry object, if the sentry converts to true, calls +str.erase() and then extracts characters from is and appends them to +str as if by calling str.append(1,c) until any of the following +occurs: +</p></blockquote> + +<p><i>[Redmond: Made changes in proposed resolution. <tt>operator>></tt> +should be a formatted input function, not an unformatted input function. +<tt>getline</tt> should not be required to set <tt>gcount</tt>, since +there is no mechanism for <tt>gcount</tt> to be set except by one of +<tt>basic_istream</tt>'s member functions.]</i></p> + + +<p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The real issue here is whether or not these string input functions +get their characters from a streambuf, rather than by calling an +istream's member functions, a streambuf signals failure either by +returning eof or by throwing an exception; there are no other +possibilities. The proposed resolution makes it clear that these two +functions do get characters from a streambuf.</p> + + + + + +<hr> +<h3><a name="92"></a>92. Incomplete Algorithm Requirements</h3> +<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The standard does not state, how often a function object is copied, +called, or the order of calls inside an algorithm. This may lead to +surprising/buggy behavior. Consider the following example: </p> + +<pre>class Nth { // function object that returns true for the nth element + private: + int nth; // element to return true for + int count; // element counter + public: + Nth (int n) : nth(n), count(0) { + } + bool operator() (int) { + return ++count == nth; + } +}; +.... +// remove third element + list<int>::iterator pos; + pos = remove_if(coll.begin(),coll.end(), // range + Nth(3)), // remove criterion + coll.erase(pos,coll.end()); </pre> + +<p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This +happens because the usual implementation of the algorithm copies the +function object internally: </p> + +<pre>template <class ForwIter, class Predicate> +ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op) +{ + beg = find_if(beg, end, op); + if (beg == end) { + return beg; + } + else { + ForwIter next = beg; + return remove_copy_if(++next, end, beg, op); + } +} </pre> + +<p>The algorithm uses find_if() to find the first element that should +be removed. However, it then uses a copy of the passed function object +to process the resulting elements (if any). Here, Nth is used again +and removes also the sixth element. This behavior compromises the +advantage of function objects being able to have a state. Without any +cost it could be avoided (just implement it directly instead of +calling find_if()). </p> + + +<p><b>Proposed resolution:</b></p> + +<p>Add a new paragraph following 25 [algorithms] paragraph 8:</p> +<blockquote><p> +[Note: Unless otherwise specified, algorithms that take function +objects as arguments are permitted to copy those function objects +freely. Programmers for whom object identity is important should +consider using a wrapper class that points to a noncopied +implementation object, or some equivalent solution.] +</p></blockquote> + +<p><i>[Dublin: Pete Becker felt that this may not be a defect, +but rather something that programmers need to be educated about. +There was discussion of adding wording to the effect that the number +and order of calls to function objects, including predicates, not +affect the behavior of the function object.]</i></p> + + +<p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't +have a clear statement of "predicate" in the +standard. People including me seemed to think "a function +returning a Boolean value and being able to be called by an STL +algorithm or be used as sorting criterion or ... is a +predicate". But a predicate has more requirements: It should +never change its behavior due to a call or being copied. IMHO we have +to state this in the standard. If you like, see section 8.1.4 of my +library book for a detailed discussion.]</i></p> + + +<p><i>[Kona: Nico will provide wording to the effect that "unless +otherwise specified, the number of copies of and calls to function +objects by algorithms is unspecified". Consider placing in +25 [algorithms] after paragraph 9.]</i></p> + + +<p><i>[Santa Cruz: The standard doesn't currently guarantee that + functions object won't be copied, and what isn't forbidden is + allowed. It is believed (especially since implementations that were + written in concert with the standard do make copies of function + objects) that this was intentional. Thus, no normative change is + needed. What we should put in is a non-normative note suggesting to + programmers that if they want to guarantee the lack of copying they + should use something like the <tt>ref</tt> wrapper.]</i></p> + + +<p><i>[Oxford: Matt provided wording.]</i></p> + + + + + + + + +<hr> +<h3><a name="98"></a>98. Input iterator requirements are badly written</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#WP">WP</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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Table 72 in 24.1.1 [input.iterators] specifies semantics for +<tt>*r++</tt> of:</p> + +<p> <tt>{ T tmp = *r; ++r; return tmp; }</tt></p> + +<p>There are two problems with this. First, the return type is +specified to be "T", as opposed to something like "convertible to T". +This is too specific: we want to allow *r++ to return an lvalue.</p> + +<p>Second, writing the semantics in terms of code misleadingly +suggests that the effects *r++ should precisely replicate the behavior +of this code, including side effects. (Does this mean that *r++ +should invoke the copy constructor exactly as many times as the sample +code above would?) See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a> for a similar +problem.</p> + + + +<p><b>Proposed resolution:</b></p> +<p>In Table 72 in 24.1.1 [input.iterators], change the return type +for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p> + + +<p><b>Rationale:</b></p> +<p>This issue has two parts: the return type, and the number of times + the copy constructor is invoked.</p> + +<p>The LWG believes the the first part is a real issue. It's + inappropriate for the return type to be specified so much more + precisely for *r++ than it is for *r. In particular, if r is of + (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>, + but <tt>int&</tt>.</p> + +<p>The LWG does not believe that the number of times the copy + constructor is invoked is a real issue. This can vary in any case, + because of language rules on copy constructor elision. That's too + much to read into these semantics clauses.</p> + +<p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since + we're told (24.1/3) that forward iterators satisfy all the requirements + of input iterators, we can't impose any requirements in the Input + Iterator requirements table that forward iterators don't satisfy.</p> + + + + + +<hr> +<h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Set::iterator is described as implementation-defined with a +reference to the container requirement; the container requirement says +that const_iterator is an iterator pointing to const T and iterator an +iterator pointing to T.</p> + +<p>23.1.2 paragraph 2 implies that the keys should not be modified to +break the ordering of elements. But that is not clearly +specified. Especially considering that the current standard requires +that iterator for associative containers be different from +const_iterator. Set, for example, has the following: </p> + +<p><tt>typedef implementation defined iterator;<br> + // See _lib.container.requirements_</tt></p> + +<p>23.1 [container.requirements] actually requires that iterator type pointing +to T (table 65). Disallowing user modification of keys by changing the +standard to require an iterator for associative container to be the +same as const_iterator would be overkill since that will unnecessarily +significantly restrict the usage of associative container. A class to +be used as elements of set, for example, can no longer be modified +easily without either redesigning the class (using mutable on fields +that have nothing to do with ordering), or using const_cast, which +defeats requiring iterator to be const_iterator. The proposed solution +goes in line with trusting user knows what he is doing. </p> + +<p><b>Other Options Evaluated:</b> </p> + +<p>Option A. In 23.1.4 [associative.reqmts], paragraph 2, after +first sentence, and before "In addition,...", add one line: +</p> + +<blockquote> + <p>Modification of keys shall not change their strict weak ordering. </p> +</blockquote> + +<p>Option B. Add three new sentences to 23.1.4 [associative.reqmts]:</p> + +<blockquote> + <p>At the end of paragraph 5: "Keys in an associative container + are immutable." At the end of paragraph 6: "For + associative containers where the value type is the same as the key + type, both <tt>iterator</tt> and <tt>const_iterator</tt> are + constant iterators. It is unspecified whether or not + <tt>iterator</tt> and <tt>const_iterator</tt> are the same + type."</p> +</blockquote> + +<p>Option C. To 23.1.4 [associative.reqmts], paragraph 3, which +currently reads:</p> + +<blockquote> + <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the + comparison and not the operator== on keys. That is, two keys k1 and k2 in the same + container are considered to be equivalent if for the comparison object comp, comp(k1, k2) + == false && comp(k2, k1) == false.</p> +</blockquote> + +<p> add the following:</p> + +<blockquote> + <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same + value whenever it is evaluated. [Note: If k2 is removed from the container and later + reinserted, comp(k1, k2) must still return a consistent value but this value may be + different than it was the first time k1 and k2 were in the same container. This is + intended to allow usage like a string key that contains a filename, where comp compares + file contents; if k2 is removed, the file is changed, and the same k2 (filename) is + reinserted, comp(k1, k2) must again return a consistent value but this value may be + different than it was the previous time k2 was in the container.]</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p>Add the following to 23.1.4 [associative.reqmts] at +the indicated location:</p> + +<blockquote> + <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container, + calling comp(k1, k2) shall always return the same + value."</p> + <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p> + <p>At the end of paragraph 6: "For associative containers where the value type is the + same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant + iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt> + are the same type."</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>Several arguments were advanced for and against allowing set elements to be +mutable as long as the ordering was not effected. The argument which swayed the +LWG was one of safety; if elements were mutable, there would be no compile-time +way to detect of a simple user oversight which caused ordering to be +modified. There was a report that this had actually happened in practice, +and had been painful to diagnose. If users need to modify elements, +it is possible to use mutable members or const_cast.</p> + +<p>Simply requiring that keys be immutable is not sufficient, because the comparison +object may indirectly (via pointers) operate on values outside of the keys.</p> + +<p> +The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted +to be different types to allow for potential future work in which some +member functions might be overloaded between the two types. No such +member functions exist now, and the LWG believes that user functionality +will not be impaired by permitting the two types to be the same. A +function that operates on both iterator types can be defined for +<tt>const_iterator</tt> alone, and can rely on the automatic +conversion from <tt>iterator</tt> to <tt>const_iterator</tt>. +</p> + +<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p> + + + + + + +<hr> +<h3><a name="106"></a>106. Numeric library private members are implementation defined</h3> +<p><b>Section:</b> 26.5.5 [template.slice.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</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#template.slice.array">issues</a> in [template.slice.array].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>This is the only place in the whole standard where the implementation has to document +something private.</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Remove the comment which says "// remainder implementation defined" from: +</p> + +<ul> + <li>26.5.5 [template.slice.array]</li> + <li>26.5.7 [template.gslice.array]</li> + <li>26.5.8 [template.mask.array]</li> + <li>26.5.9 [template.indirect.array]</li> +</ul> + + + + + +<hr> +<h3><a name="108"></a>108. Lifetime of exception::what() return unspecified</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#TC">TC</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#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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of +exception::what() is left unspecified. This issue has implications +with exception safety of exception handling: some exceptions should +not throw bad_alloc.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add to 18.6.1 [type.info] paragraph 9 (exception::what notes +clause) the sentence:</p> + +<blockquote> + <p>The return value remains valid until the exception object from which it is obtained is + destroyed or a non-const member function of the exception object is called.</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>If an exception object has non-const members, they may be used +to set internal state that should affect the contents of the string +returned by <tt>what()</tt>. +</p> + + + + + +<hr> +<h3><a name="109"></a>109. Missing binders for non-const sequence elements</h3> +<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Bjarne Stroustrup <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#depr.lib.binders">issues</a> in [depr.lib.binders].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>There are no versions of binders that apply to non-const elements +of a sequence. This makes examples like for_each() using bind2nd() on +page 521 of "The C++ Programming Language (3rd)" +non-conforming. Suitable versions of the binders need to be added.</p> + +<p>Further discussion from Nico:</p> + +<p>What is probably meant here is shown in the following example:</p> + +<pre>class Elem { + public: + void print (int i) const { } + void modify (int i) { } +}; </pre> +<pre>int main() +{ + vector<Elem> coll(2); + for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::print),42)); // OK + for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::modify),42)); // ERROR +}</pre> + +<p>The error results from the fact that bind2nd() passes its first +argument (the argument of the sequence) as constant reference. See the +following typical implementation:</p> + +<blockquote> + <pre>template <class Operation> +class binder2nd + : public unary_function<typename Operation::first_argument_type, + typename Operation::result_type> { +protected: + Operation op; + typename Operation::second_argument_type value; +public: + binder2nd(const Operation& o, + const typename Operation::second_argument_type& v) + : op(o), value(v) {} </pre> + <pre> typename Operation::result_type + operator()(const typename Operation::first_argument_type& x) const { + return op(x, value); + } +};</pre> +</blockquote> + +<p>The solution is to overload operator () of bind2nd for non-constant arguments:</p> + +<blockquote> + <pre>template <class Operation> +class binder2nd + : public unary_function<typename Operation::first_argument_type, + typename Operation::result_type> { +protected: + Operation op; + typename Operation::second_argument_type value; +public: + binder2nd(const Operation& o, + const typename Operation::second_argument_type& v) + : op(o), value(v) {} </pre> + <pre> typename Operation::result_type + operator()(const typename Operation::first_argument_type& x) const { + return op(x, value); + } + typename Operation::result_type + operator()(typename Operation::first_argument_type& x) const { + return op(x, value); + } +};</pre> +</blockquote> + + +<p><b>Proposed resolution:</b></p> + +<p><b>Howard believes there is a flaw</b> in this resolution. +See c++std-lib-9127. We may need to reopen this issue.</p> + +<p>In D.8 [depr.lib.binders] in the declaration of binder1st after:</p> +<blockquote> + <p><tt>typename Operation::result_type<br> + operator()(const typename Operation::second_argument_type& x) const;</tt></p> +</blockquote> +<p>insert:</p> +<blockquote> + <p><tt>typename Operation::result_type<br> + operator()(typename Operation::second_argument_type& x) const;</tt></p> +</blockquote> +<p>In D.8 [depr.lib.binders] in the declaration of binder2nd after:</p> +<blockquote> + <p><tt>typename Operation::result_type<br> + operator()(const typename Operation::first_argument_type& x) const;</tt></p> +</blockquote> +<p>insert:</p> +<blockquote> + <p><tt>typename Operation::result_type<br> + operator()(typename Operation::first_argument_type& x) const;</tt></p> +</blockquote> + +<p><i>[Kona: The LWG discussed this at some length.It was agreed that +this is a mistake in the design, but there was no consensus on whether +it was a defect in the Standard. Straw vote: NAD - 5. Accept +proposed resolution - 3. Leave open - 6.]</i></p> + + +<p><i>[Copenhagen: It was generally agreed that this was a defect. +Strap poll: NAD - 0. Accept proposed resolution - 10. +Leave open - 1.]</i></p> + + + + + + + +<hr> +<h3><a name="110"></a>110. istreambuf_iterator::equal not const</h3> +<p><b>Section:</b> 24.5.3 [istreambuf.iterator], 24.5.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-10-15</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Member istreambuf_iterator<>::equal is not declared +"const", yet 24.5.3.6 [istreambuf.iterator::op==] says that operator==, +which is const, calls it. This is contradictory. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 24.5.3 [istreambuf.iterator] and also in 24.5.3.5 [istreambuf.iterator::equal], +replace:</p> + +<blockquote> + <pre>bool equal(istreambuf_iterator& b);</pre> +</blockquote> + +<p>with:</p> + +<blockquote> + <pre>bool equal(const istreambuf_iterator& b) const;</pre> +</blockquote> + + + + + +<hr> +<h3><a name="112"></a>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3> +<p><b>Section:</b> 24.5.4.1 [ostreambuf.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-10-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s +constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1) +reads "<i>s</i> is not null". However, <i>s</i> is a +reference, and references can't be null. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 24.5.4.1 [ostreambuf.iter.cons]:</p> + +<p>Move the current paragraph 1, which reads "Requires: s is not +null.", from the first constructor to the second constructor.</p> + +<p>Insert a new paragraph 1 Requires clause for the first constructor +reading:</p> + +<blockquote> + <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p> +</blockquote> + + + + + +<hr> +<h3><a name="114"></a>114. Placement forms example in error twice</h3> +<p><b>Section:</b> 18.5.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-28</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a></p> +<p><b>Discussion:</b></p> +<p>Section 18.5.1.3 contains the following example: </p> + +<pre>[Example: This can be useful for constructing an object at a known address: + char place[sizeof(Something)]; + Something* p = new (place) Something(); + -end example]</pre> + +<p>First code line: "place" need not have any special alignment, and the +following constructor could fail due to misaligned data.</p> + +<p>Second code line: Aren't the parens on Something() incorrect? [Dublin: the LWG +believes the () are correct.]</p> + +<p>Examples are not normative, but nevertheless should not show code that is invalid or +likely to fail.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace the first line of code in the example in +18.5.1.3 [new.delete.placement] with: +</p> + +<blockquote> + <pre>void* place = operator new(sizeof(Something));</pre> +</blockquote> + + + + + +<hr> +<h3><a name="115"></a>115. Typo in strstream constructors</h3> +<p><b>Section:</b> D.7.4.1 [depr.strstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-11-02</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>D.7.4.1 strstream constructors paragraph 2 says: </p> + +<blockquote> + <p>Effects: Constructs an object of class strstream, initializing the base class with + iostream(& sb) and initializing sb with one of the two constructors: </p> + <p>- If mode&app==0, then s shall designate the first element of an array of n + elements. The constructor is strstreambuf(s, n, s). </p> + <p>- If mode&app==0, then s shall designate the first element of an array of n + elements that contains an NTBS whose first element is designated by s. The constructor is + strstreambuf(s, n, s+std::strlen(s)).</p> +</blockquote> + +<p>Notice the second condition is the same as the first. I think the second condition +should be "If mode&app==app", or "mode&app!=0", meaning that +the append bit is set.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In D.7.3.1 [depr.ostrstream.cons] paragraph 2 and D.7.4.1 [depr.strstream.cons] +paragraph 2, change the first condition to <tt>(mode&app)==0</tt> +and the second condition to <tt>(mode&app)!=0</tt>.</p> + + + + + +<hr> +<h3><a name="117"></a>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3> +<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The <b>effects</b> clause for numeric inserters says that +insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>, +<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned +int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, +<tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is +delegated to <tt>num_put</tt>, and that insertion is performed as if +through the following code fragment: </p> + +<pre>bool failed = use_facet< + num_put<charT,ostreambuf_iterator<charT,traits> > + >(getloc()).put(*this, *this, fill(), val). failed();</pre> + +<p>This doesn't work, because <tt>num_put<></tt>::put is only +overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned +long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const +void*</tt>. That is, the code fragment in the standard is incorrect +(it is diagnosed as ambiguous at compile time) for the types +<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned +int</tt>, and <tt>float</tt>. </p> + +<p>We must either add new member functions to <tt>num_put</tt>, or +else change the description in <tt>ostream</tt> so that it only calls +functions that are actually there. I prefer the latter. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace 27.6.2.5.2, paragraph 1 with the following: </p> + +<blockquote> +<p> +The classes num_get<> and num_put<> handle locale-dependent numeric +formatting and parsing. These inserter functions use the imbued +locale value to perform numeric formatting. When val is of type bool, +long, unsigned long, double, long double, or const void*, 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(); +</pre> + +<p> +When val is of type short the formatting conversion occurs as if it +performed the following code fragment: +</p> + +<pre>ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield; +bool failed = use_facet< + num_put<charT,ostreambuf_iterator<charT,traits> > + >(getloc()).put(*this, *this, fill(), + baseflags == ios_base::oct || baseflags == ios_base::hex + ? static_cast<long>(static_cast<unsigned short>(val)) + : static_cast<long>(val)). failed(); +</pre> + +<p> +When val is of type int the formatting conversion occurs as if it performed +the following code fragment: +</p> + +<pre>ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield; +bool failed = use_facet< + num_put<charT,ostreambuf_iterator<charT,traits> > + >(getloc()).put(*this, *this, fill(), + baseflags == ios_base::oct || baseflags == ios_base::hex + ? static_cast<long>(static_cast<unsigned int>(val)) + : static_cast<long>(val)). failed(); +</pre> + +<p> +When val is of type unsigned short or unsigned int 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(), static_cast<unsigned long>(val)). +failed(); +</pre> + +<p> +When val is of type float 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(), static_cast<double>(val)). +failed(); +</pre> + +</blockquote> + +<p><i>[post-Toronto: This differs from the previous proposed +resolution; PJP provided the new wording. The differences are in +signed short and int output.]</i></p> + + + +<p><b>Rationale:</b></p> +<p>The original proposed resolution was to cast int and short to long, +unsigned int and unsigned short to unsigned long, and float to double, +thus ensuring that we don't try to use nonexistent num_put<> +member functions. The current proposed resolution is more +complicated, but gives more expected results for hex and octal output +of signed short and signed int. (On a system with 16-bit short, for +example, printing short(-1) in hex format should yield 0xffff.)</p> + + + + + +<hr> +<h3><a name="118"></a>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</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#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, +<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>, +<tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2, +formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p> + +<pre>typedef num_get< charT,istreambuf_iterator<charT,traits> > numget; +iostate err = 0; +use_facet< numget >(loc).get(*this, 0, *this, err, val); +setstate(err);</pre> + +<p>According to section 22.2.2.1.1 [facet.num.get.members], however, +<tt>num_get<>::get()</tt> is only overloaded for the types +<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned +int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>, +<tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and +<tt>void*</tt>. Comparing the lists from the two sections, we find +that 27.6.1.2.2 is using a nonexistent function for types +<tt>short</tt> and <tt>int</tt>. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.6.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the +two lines (1st and 3rd) which read:</p> +<blockquote> + <pre>operator>>(short& val); +... +operator>>(int& val);</pre> +</blockquote> + +<p>And add the following at the end of that section (27.6.1.2.2) :</p> + +<blockquote> + <pre>operator>>(short& val);</pre> + <p>The conversion occurs as if performed by the following code fragment (using + the same notation as for the preceding code fragment):</p> + <pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget; + iostate err = 0; + long lval; + use_facet< numget >(loc).get(*this, 0, *this, err, lval); + if (err == 0 + && (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval)) + err = ios_base::failbit; + setstate(err);</pre> + <pre>operator>>(int& val);</pre> + <p>The conversion occurs as if performed by the following code fragment (using + the same notation as for the preceding code fragment):</p> + <pre> typedef num_get< charT,istreambuf_iterator<charT,traits> > numget; + iostate err = 0; + long lval; + use_facet< numget >(loc).get(*this, 0, *this, err, lval); + if (err == 0 + && (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval)) + err = ios_base::failbit; + setstate(err);</pre> +</blockquote> + +<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p> + + + + + + +<hr> +<h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3> +<p><b>Section:</b> 17.4.4.9 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Section 17.4.4.9 [res.on.exception.handling] states: </p> + +<p>"An implementation may strengthen the exception-specification +for a function by removing listed exceptions." </p> + +<p>The problem is that if an implementation is allowed to do this for +virtual functions, then a library user cannot write a class that +portably derives from that class. </p> + +<p>For example, this would not compile if ios_base::failure::~failure +had an empty exception specification: </p> + +<pre>#include <ios> +#include <string> + +class D : public std::ios_base::failure { +public: + D(const std::string&); + ~D(); // error - exception specification must be compatible with + // overridden virtual function ios_base::failure::~failure() +};</pre> + + +<p><b>Proposed resolution:</b></p> +<p>Change Section 17.4.4.9 [res.on.exception.handling] from:</p> + +<p> "may strengthen the +exception-specification for a function"</p> + +<p>to:</p> + +<p> "may strengthen the +exception-specification for a non-virtual function". </p> + + + + + +<hr> +<h3><a name="120"></a>120. Can an implementor add specializations?</h3> +<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>The original issue asked whether a library implementor could +specialize standard library templates for built-in types. (This was +an issue because users are permitted to explicitly instantiate +standard library templates.)</p> + +<p>Specializations are no longer a problem, because of the resolution +to core issue 259. Under the proposed resolution, it will be legal +for a translation unit to contain both a specialization and an +explicit instantiation of the same template, provided that the +specialization comes first. In such a case, the explicit +instantiation will be ignored. Further discussion of library issue +120 assumes that the core 259 resolution will be adopted.</p> + +<p>However, as noted in lib-7047, one piece of this issue still +remains: what happens if a standard library implementor explicitly +instantiates a standard library templates? It's illegal for a program +to contain two different explicit instantiations of the same template +for the same type in two different translation units (ODR violation), +and the core working group doesn't believe it is practical to relax +that restriction.</p> + +<p>The issue, then, is: are users allowed to explicitly instantiate +standard library templates for non-user defined types? The status quo +answer is 'yes'. Changing it to 'no' would give library implementors +more freedom.</p> + +<p>This is an issue because, for performance reasons, library +implementors often need to explicitly instantiate standard library +templates. (for example, std::basic_string<char>) Does giving +users freedom to explicitly instantiate standard library templates for +non-user defined types make it impossible or painfully difficult for +library implementors to do this?</p> + +<p>John Spicer suggests, in lib-8957, that library implementors have a +mechanism they can use for explicit instantiations that doesn't +prevent users from performing their own explicit instantiations: put +each explicit instantiation in its own object file. (Different +solutions might be necessary for Unix DSOs or MS-Windows DLLs.) On +some platforms, library implementors might not need to do anything +special: the "undefined behavior" that results from having two +different explicit instantiations might be harmless.</p> + + + +<p><b>Proposed resolution:</b></p> + <p>Append to 17.4.3.2 [reserved.names] paragraph 1: </p> + <blockquote><p> + A program may explicitly instantiate any templates in the standard + library only if the declaration depends on the name of a user-defined + type of external linkage and the instantiation meets the standard library + requirements for the original template. + </p></blockquote> + +<p><i>[Kona: changed the wording from "a user-defined name" to "the name of + a user-defined type"]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The LWG considered another possible resolution:</p> +<blockquote> + <p>In light of the resolution to core issue 259, no normative changes + in the library clauses are necessary. Add the following non-normative + note to the end of 17.4.3.2 [reserved.names] paragraph 1:</p> + <blockquote><p> + [<i>Note:</i> A program may explicitly instantiate standard library + templates, even when an explicit instantiation does not depend on + a user-defined name. <i>--end note</i>] + </p></blockquote> +</blockquote> + +<p>The LWG rejected this because it was believed that it would make + it unnecessarily difficult for library implementors to write + high-quality implementations. A program may not include an + explicit instantiation of the same template, for the same template + arguments, in two different translation units. If users are + allowed to provide explicit instantiations of Standard Library + templates for built-in types, then library implementors aren't, + at least not without nonportable tricks.</p> + +<p>The most serious problem is a class template that has writeable + static member variables. Unfortunately, such class templates are + important and, in existing Standard Library implementations, are + often explicitly specialized by library implementors: locale facets, + which have a writeable static member variable <tt>id</tt>. If a + user's explicit instantiation collided with the implementations + explicit instantiation, iostream initialization could cause locales + to be constructed in an inconsistent state.</p> + +<p>One proposed implementation technique was for Standard Library + implementors to provide explicit instantiations in separate object + files, so that they would not be picked up by the linker when the + user also provides an explicit instantiation. However, this + technique only applies for Standard Library implementations that + are packaged as static archives. Most Standard Library + implementations nowadays are packaged as dynamic libraries, so this + technique would not apply.</p> + +<p>The Committee is now considering standardization of dynamic + linking. If there are such changes in the future, it may be + appropriate to revisit this issue later.</p> + + + + + +<hr> +<h3><a name="122"></a>122. streambuf/wstreambuf description should not say they are specializations</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#TC">TC</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Section 27.5.2 describes the streambuf classes this way: </p> + +<blockquote> + +<p>The class streambuf is a specialization of the template class basic_streambuf +specialized for the type char. </p> + +<p>The class wstreambuf is a specialization of the template class basic_streambuf +specialized for the type wchar_t. </p> + +</blockquote> + +<p>This implies that these classes must be template specializations, not typedefs. </p> + +<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove 27.5.2 [streambuf] paragraphs 2 and 3 (the above two +sentences). </p> + + +<p><b>Rationale:</b></p> +<p>The <tt>streambuf</tt> synopsis already has a declaration for the +typedefs and that is sufficient. </p> + + + + + +<hr> +<h3><a name="123"></a>123. Should valarray helper arrays fill functions be const?</h3> +<p><b>Section:</b> 26.5.5.3 [slice.arr.fill], 26.5.7.3 [gslice.array.fill], 26.5.8.3 [mask.array.fill], 26.5.9.3 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>One of the operator= in the valarray helper arrays is const and one +is not. For example, look at slice_array. This operator= in Section +26.5.5.1 [slice.arr.assign] is const: </p> + +<p> <tt>void operator=(const valarray<T>&) const;</tt> </p> + +<p>but this one in Section 26.5.5.3 [slice.arr.fill] is not: </p> + +<p> <tt>void operator=(const T&); </tt></p> + +<p>The description of the semantics for these two functions is similar. </p> + + +<p><b>Proposed resolution:</b></p> + +<p>26.5.5 [template.slice.array] Template class slice_array</p> +<blockquote> + + <p>In the class template definition for slice_array, replace the member + function declaration</p> + <pre> void operator=(const T&); + </pre> + <p>with</p> + <pre> void operator=(const T&) const; + </pre> +</blockquote> + +<p>26.5.5.3 [slice.arr.fill] slice_array fill function</p> +<blockquote> + + <p>Change the function declaration</p> + <pre> void operator=(const T&); + </pre> + <p>to</p> + <pre> void operator=(const T&) const; + </pre> +</blockquote> + +<p>26.5.7 [template.gslice.array] Template class gslice_array</p> +<blockquote> + + <p>In the class template definition for gslice_array, replace the member + function declaration</p> + <pre> void operator=(const T&); + </pre> + <p>with</p> + <pre> void operator=(const T&) const; + </pre> +</blockquote> + +<p>26.5.7.3 [gslice.array.fill] gslice_array fill function</p> +<blockquote> + + <p>Change the function declaration</p> + <pre> void operator=(const T&); + </pre> + <p>to</p> + <pre> void operator=(const T&) const; + </pre> +</blockquote> + +<p>26.5.8 [template.mask.array] Template class mask_array</p> +<blockquote> + + <p>In the class template definition for mask_array, replace the member + function declaration</p> + <pre> void operator=(const T&); + </pre> + <p>with</p> + <pre> void operator=(const T&) const; + </pre> +</blockquote> + +<p>26.5.8.3 [mask.array.fill] mask_array fill function</p> +<blockquote> + + <p>Change the function declaration</p> + <pre> void operator=(const T&); + </pre> + <p>to</p> + <pre> void operator=(const T&) const; + </pre> +</blockquote> + +<p>26.5.9 [template.indirect.array] Template class indirect_array</p> +<blockquote> + + <p>In the class template definition for indirect_array, replace the member + function declaration</p> + <pre> void operator=(const T&); + </pre> + <p>with</p> + <pre> void operator=(const T&) const; + </pre> +</blockquote> + +<p>26.5.9.3 [indirect.array.fill] indirect_array fill function</p> +<blockquote> + + <p>Change the function declaration</p> + <pre> void operator=(const T&); + </pre> + <p>to</p> + <pre> void operator=(const T&) const; + </pre> +</blockquote> + + +<p><i>[Redmond: Robert provided wording.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>There's no good reason for one version of operator= being const and +another one not. Because of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, this now +matters: these functions are now callable in more circumstances. In +many existing implementations, both versions are already const.</p> + + + + + +<hr> +<h3><a name="124"></a>124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*</h3> +<p><b>Section:</b> 22.2.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In Section 22.2.1.2 [locale.ctype.byname] +ctype_byname<charT>::do_scan_is() and do_scan_not() are declared +to return a const char* not a const charT*. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Change Section 22.2.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and +<tt>do_scan_not()</tt> to return a <tt> const +charT*</tt>. </p> + + + + + +<hr> +<h3><a name="125"></a>125. valarray<T>::operator!() return type is inconsistent</h3> +<p><b>Section:</b> 26.5.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.valarray">issues</a> in [template.valarray].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In Section 26.5.2 [template.valarray] valarray<T>::operator!() +is +declared to return a valarray<T>, but in Section 26.5.2.5 +[valarray.unary] it is declared to return a valarray<bool>. The +latter appears to be correct. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Change in Section 26.5.2 [template.valarray] the declaration of +<tt>operator!()</tt> so that the return type is +<tt>valarray<bool></tt>. </p> + + + + +<hr> +<h3><a name="126"></a>126. typos in Effects clause of ctype::do_narrow()</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#TC">TC</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p><p>Typos in 22.2.1.1.2 need to be fixed.</p> + +<p><b>Proposed resolution:</b></p> +<p>In Section 22.2.1.1.2 [locale.ctype.virtuals] change: </p> + +<pre> do_widen(do_narrow(c),0) == c</pre> + +<p>to:</p> + +<pre> do_widen(do_narrow(c,0)) == c</pre> + +<p>and change:</p> + +<pre> (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre> + +<p>to:</p> + +<pre> (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre> + + + + + +<hr> +<h3><a name="127"></a>127. auto_ptr<> conversion 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#TC">TC</a> + <b>Submitter:</b> Greg Colvin <b>Date:</b> 1999-02-17</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>There are two problems with the current <tt>auto_ptr</tt> wording +in the standard: </p> + +<p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested +because <tt>auto_ptr<Derived>::auto_ptr_ref</tt> is unrelated to +<tt>auto_ptr<Base>::auto_ptr_ref</tt>. <i>Also submitted by +Nathan Myers, with the same proposed resolution.</i></p> + +<p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an +<tt>auto_ptr_ref</tt> argument. </p> + +<p>I have discussed these problems with my proposal coauthor, Bill +Gibbons, and with some compiler and library implementors, and we +believe that these problems are not desired or desirable implications +of the standard. </p> + +<p>25 Aug 1999: The proposed resolution now reflects changes suggested +by Dave Abrahams, with Greg Colvin's concurrence; 1) changed +"assignment operator" to "public assignment +operator", 2) changed effects to specify use of release(), 3) +made the conversion to auto_ptr_ref const. </p> + +<p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue +states that the conversion from auto_ptr to auto_ptr_ref should +be const. This is not acceptable, because it would allow +initialization and assignment from _any_ const auto_ptr! It also +introduces an implementation difficulty in writing this conversion +function -- namely, somewhere along the line, a const_cast will be +necessary to remove that const so that release() may be called. This +may result in undefined behavior [7.1.5.1/4]. The conversion +operator does not have to be const, because a non-const implicit +object parameter may be bound to an rvalue [13.3.3.1.4/3] +[13.3.1/5]. </p> + + <p>Tokyo: The LWG removed the following from the proposed resolution:</p> + + <p>In 20.5.4 [meta.unary], paragraph 2, and 20.5.4.3 [meta.unary.prop], + paragraph 2, make the conversion to auto_ptr_ref const:</p> + <blockquote> + <pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre> + </blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>In 20.5.4 [meta.unary], paragraph 2, move +the <tt>auto_ptr_ref</tt> definition to namespace scope.</p> + +<p>In 20.5.4 [meta.unary], paragraph 2, add +a public assignment operator to the <tt>auto_ptr</tt> definition: </p> + +<blockquote> + <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre> +</blockquote> + +<p>Also add the assignment operator to 20.5.4.3 [meta.unary.prop]: </p> + +<blockquote> + <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre> + + <p><b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr + p</tt> that <tt>r</tt> holds a reference to.<br> + <b>Returns: </b><tt>*this</tt>.</p> + +</blockquote> + + + + + +<hr> +<h3><a name="129"></a>129. Need error indication from seekp() and seekg()</h3> +<p><b>Section:</b> 27.6.1.3 [istream.unformatted], 27.6.2.5 [ostream.seeks] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</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#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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Currently, the standard does not specify how seekg() and seekp() +indicate failure. They are not required to set failbit, and they can't +return an error indication because they must return *this, i.e. the +stream. Hence, it is undefined what happens if they fail. And they +<i>can</i> fail, for instance, when a file stream is disconnected from the +underlying file (is_open()==false) or when a wide character file +stream must perform a state-dependent code conversion, etc. </p> + +<p>The stream functions seekg() and seekp() should set failbit in the +stream state in case of failure.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add to the Effects: clause of seekg() in +27.6.1.3 [istream.unformatted] and to the Effects: clause of seekp() in +27.6.2.5 [ostream.seeks]: </p> + +<blockquote> + <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>). + </p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>Setting failbit is the usual error reporting mechanism for streams</p> + + + + +<hr> +<h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#451">451</a></p> +<p><b>Discussion:</b></p> +<p>Table 67 (23.1.1) says that container::erase(iterator) returns an +iterator. Table 69 (23.1.2) says that in addition to this requirement, +associative containers also say that container::erase(iterator) +returns void. That's not an addition; it's a change to the +requirements, which has the effect of making associative containers +fail to meet the requirements for containers.</p> + + +<p><b>Proposed resolution:</b></p> + +<p> +In 23.1.4 [associative.reqmts], in Table 69 Associative container +requirements, change the return type of <tt>a.erase(q)</tt> from +<tt>void</tt> to <tt>iterator</tt>. Change the +assertion/not/pre/post-condition from "erases the element pointed to +by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>. +Returns an iterator pointing to the element immediately following q +prior to the element being erased. If no such element exists, a.end() +is returned." +</p> + +<p> +In 23.1.4 [associative.reqmts], in Table 69 Associative container +requirements, change the return type of <tt>a.erase(q1, q2)</tt> +from <tt>void</tt> to <tt>iterator</tt>. Change the +assertion/not/pre/post-condition from "erases the elements in the +range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1, +q2)</tt>. Returns q2." +</p> + +<p> +In 23.3.1 [map], in the <tt>map</tt> class synopsis; and +in 23.3.2 [multimap], in the <tt>multimap</tt> class synopsis; and +in 23.3.3 [set], in the <tt>set</tt> class synopsis; and +in 23.3.4 [multiset], in the <tt>multiset</tt> class synopsis: +change the signature of the first <tt>erase</tt> overload to +</p> +<pre> iterator erase(iterator position); +</pre> +<p>and change the signature of the third <tt>erase</tt> overload to</p> +<pre> iterator erase(iterator first, iterator last); +</pre> + + +<p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p> + + +<p><i>[Post-Kona: the LWG agrees the return type should be +<tt>iterator</tt>, not <tt>void</tt>. (Alex Stepanov agrees too.) +Matt provided wording.]</i></p> + + +<p><i>[ + Sydney: the proposed wording went in the right direction, but it + wasn't good enough. We want to return an iterator from the range form + of erase as well as the single-iterator form. Also, the wording is + slightly different from the wording we have for sequences; there's no + good reason for having a difference. Matt provided new wording, +(reflected above) which we will review at the next meeting. +]</i></p> + + +<p><i>[ +Redmond: formally voted into WP. +]</i></p> + + + + + + + +<hr> +<h3><a name="132"></a>132. list::resize description uses random access iterators</h3> +<p><b>Section:</b> 23.2.4.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The description reads:</p> + +<p>-1- Effects:</p> + +<pre> if (sz > size()) + insert(end(), sz-size(), c); + else if (sz < size()) + erase(begin()+sz, end()); + else + ; // do nothing</pre> + +<p>Obviously list::resize should not be specified in terms of random access iterators.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 23.2.4.2 [list.capacity] paragraph 1 to:</p> + +<p>Effects:</p> + +<pre> if (sz > size()) + insert(end(), sz-size(), c); + else if (sz < size()) + { + iterator i = begin(); + advance(i, sz); + erase(i, end()); + }</pre> + +<p><i>[Dublin: The LWG asked Howard to discuss exception safety offline +with David Abrahams. They had a discussion and believe there is +no issue of exception safety with the proposed resolution.]</i></p> + + + + + + +<hr> +<h3><a name="133"></a>133. map missing get_allocator()</h3> +<p><b>Section:</b> 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p><p>The title says it all.</p> + +<p><b>Proposed resolution:</b></p> +<p>Insert in 23.3.1 [map], paragraph 2, +after operator= in the map declaration:</p> + +<pre> allocator_type get_allocator() const;</pre> + + + + +<hr> +<h3><a name="134"></a>134. vector constructors over specified</h3> +<p><b>Section:</b> 23.2.6.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The complexity description says: "It does at most 2N calls to the copy constructor +of T and logN reallocations if they are just input iterators ...".</p> + +<p>This appears to be overly restrictive, dictating the precise memory/performance +tradeoff for the implementor.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 23.2.6.1 [vector.cons], paragraph 1 to:</p> + +<p>-1- Complexity: The constructor template <class +InputIterator> vector(InputIterator first, InputIterator last) +makes only N calls to the copy constructor of T (where N is the +distance between first and last) and no reallocations if iterators +first and last are of forward, bidirectional, or random access +categories. It makes order N calls to the copy constructor of T and +order logN reallocations if they are just input iterators. +</p> + + +<p><b>Rationale:</b></p> +<p>"at most 2N calls" is correct only if the growth factor +is greater than or equal to 2. +</p> + + + + +<hr> +<h3><a name="136"></a>136. seekp, seekg setting wrong streams?</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#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>I may be misunderstanding the intent, but should not seekg set only +the input stream and seekp set only the output stream? The description +seems to say that each should set both input and output streams. If +that's really the intent, I withdraw this proposal.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In section 27.6.1.3 change:</p> + +<pre>basic_istream<charT,traits>& seekg(pos_type pos); +Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre> + +<p>To:</p> + +<pre>basic_istream<charT,traits>& seekg(pos_type pos); +Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::in). </pre> + +<p>In section 27.6.1.3 change:</p> + +<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir); +Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre> + +<p>To:</p> + +<pre>basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir); +Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::in). </pre> + +<p>In section 27.6.2.4, paragraph 2 change:</p> + +<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). </pre> + +<p>To:</p> + +<pre>-2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::out). </pre> + +<p>In section 27.6.2.4, paragraph 4 change:</p> + +<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). </pre> + +<p>To:</p> + +<pre>-4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::out). </pre> + +<p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would +like the opinion of more iostream experts before taking action.]</i></p> + + +<p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are +incorrect, his implementation already implements the Proposed +Resolution.]</i></p> + + +<p><i>[Post-Tokyo: Matt Austern comments:<br> +Is it a problem with basic_istream and basic_ostream, or is it a problem +with basic_stringbuf? +We could resolve the issue either by changing basic_istream and +basic_ostream, or by changing basic_stringbuf. I prefer the latter +change (or maybe both changes): I don't see any reason for the standard to +require that std::stringbuf s(std::string("foo"), std::ios_base::in); +s.pubseekoff(0, std::ios_base::beg); must fail.<br> +This requirement is a bit weird. There's no similar requirement +for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or +basic_filebuf<>::seekpos.]</i></p> + + + + + + +<hr> +<h3><a name="137"></a>137. Do use_facet and has_facet look in the global locale?</h3> +<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Section 22.1.1 [locale] says:</p> + +<p>-4- In the call to use_facet<Facet>(loc), the type argument +chooses a facet, making available all members of the named type. If +Facet is not present in a locale (or, failing that, in the global +locale), it throws the standard exception bad_cast. A C++ program can +check if a locale implements a particular facet with the template +function has_facet<Facet>(). </p> + +<p>This contradicts the specification given in section +22.1.2 [locale.global.templates]: +<br><br> +template <class Facet> const Facet& use_facet(const +locale& loc); <br> +<br> +-1- Get a reference to a facet of a locale. <br> +-2- Returns: a reference to the corresponding facet of loc, if present. <br> +-3- Throws: bad_cast if has_facet<Facet>(loc) is false. <br> +-4- Notes: The reference returned remains valid at least as long as any copy of loc exists +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove the phrase "(or, failing that, in the global locale)" +from section 22.1.1. </p> + + +<p><b>Rationale:</b></p> +<p>Needed for consistency with the way locales are handled elsewhere +in the standard.</p> + + + + +<hr> +<h3><a name="139"></a>139. Optional sequence operation table description unclear</h3> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The sentence introducing the Optional sequence operation table +(23.1.1 paragraph 12) has two problems:</p> + +<p>A. It says ``The operations in table 68 are provided only for the containers for which +they take constant time.''<br> +<br> +That could be interpreted in two ways, one of them being ``Even though table 68 shows +particular operations as being provided, implementations are free to omit them if they +cannot implement them in constant time.''<br> +<br> +B. That paragraph says nothing about amortized constant time, and it should. </p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace the wording in 23.1.1 paragraph 12 which begins ``The operations in table 68 are provided only..." +with:</p> + +<blockquote> + <p>Table 68 lists sequence operations that are provided for some types of sequential + containers but not others. An implementation shall provide these operations for all + container types shown in the ``container'' column, and shall implement them so as to take + amortized constant time.</p> +</blockquote> + + + + +<hr> +<h3><a name="141"></a>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3> +<p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Arch Robison <b>Date:</b> 1999-04-28</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they +say:<br> +<br> +— <tt>xpos <= pos</tt> and <tt>pos < size();</tt></p> + +<p>Surely the document meant to say ``<tt>xpos < size()</tt>'' in both places.</p> + +<p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same +proposed resolution.]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br> +<br> +— <tt>xpos <= pos</tt> and <tt>pos < size();<br> +<br> +</tt>to:<br> +<tt><br> +</tt>— <tt>xpos <= pos</tt> and <tt>xpos < size();</tt></p> + + + + +<hr> +<h3><a name="142"></a>142. lexicographical_compare complexity wrong</h3> +<p><b>Section:</b> 25.3.8 [alg.lex.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-06-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The lexicographical_compare complexity is specified as:<br> +<br> + "At most min((last1 - first1), (last2 - first2)) +applications of the corresponding comparison."<br> +<br> +The best I can do is twice that expensive.</p> + +<p>Nicolai Josuttis comments in lib-6862: You mean, to check for +equality you have to check both < and >? Yes, IMO you are +right! (and Matt states this complexity in his book)</p> + + + +<p><b>Proposed resolution:</b></p> +<p>Change 25.3.8 [alg.lex.comparison] complexity to:</p> + <blockquote><p> + At most <tt>2*min((last1 - first1), (last2 - first2))</tt> + applications of the corresponding comparison. + </p></blockquote> + +<p>Change the example at the end of paragraph 3 to read:</p> + <blockquote><p> + [Example:<br> + <br> + for ( ; first1 != last1 && first2 != last2 ; + ++first1, ++first2) {<br> + if (*first1 < *first2) return true;<br> + if (*first2 < *first1) return false;<br> + }<br> + return first1 == last1 && first2 != last2;<br> + <br> + --end example] + </p></blockquote> + + + + +<hr> +<h3><a name="144"></a>144. Deque constructor complexity wrong </h3> +<p><b>Section:</b> 23.2.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Herb Sutter <b>Date:</b> 1999-05-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 23.2.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears +to have complexity requirements which are incorrect, and which contradict the +complexity requirements for insert(). I suspect that the text in question, +below, was taken from vector:</p> +<blockquote> + <p>Complexity: If the iterators first and last are forward iterators, + bidirectional iterators, or random access iterators the constructor makes only + N calls to the copy constructor, and performs no reallocations, where N is + last - first.</p> +</blockquote> +<p>The word "reallocations" does not really apply to deque. Further, +all of the following appears to be spurious:</p> +<blockquote> + <p>It makes at most 2N calls to the copy constructor of T and log N + reallocations if they are input iterators.1)</p> + <p>1) The complexity is greater in the case of input iterators because each + element must be added individually: it is impossible to determine the distance + between first abd last before doing the copying.</p> +</blockquote> +<p>This makes perfect sense for vector, but not for deque. Why should deque gain +an efficiency advantage from knowing in advance the number of elements to +insert?</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 23.2.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the +footnote, with the following text (which also corrects the "abd" +typo):</p> +<blockquote> + <p>Complexity: Makes last - first calls to the copy constructor of T.</p> +</blockquote> + + + + +<hr> +<h3><a name="146"></a>146. complex<T> Inserter and Extractor need sentries</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#TC">TC</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The extractor for complex numbers is specified as: </p> + +<blockquote> + +<p> template<class T, class charT, class traits> <br> + basic_istream<charT, traits>& <br> + operator>>(basic_istream<charT, traits>& is, complex<T>& x);<br> + <br> +Effects: Extracts a complex number x of the form: u, (u), or (u,v), +where u is the real part and v is the imaginary part +(lib.istream.formatted). <br> +Requires: The input values be convertible to T. If bad input is +encountered, calls is.setstate(ios::failbit) (which may throw +ios::failure (lib.iostate.flags). <br> +Returns: is .</p> + +</blockquote> +<p>Is it intended that the extractor for complex numbers does not skip +whitespace, unlike all other extractors in the standard library do? +Shouldn't a sentry be used? <br> +<br> +The inserter for complex numbers is specified as:</p> + +<blockquote> + +<p> template<class T, class charT, class traits> <br> + basic_ostream<charT, traits>& <br> + operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);<br> +<br> +Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br> +<br> + template<class T, class charT, class traits> <br> + basic_ostream<charT, traits>& <br> + operator<<(basic_ostream<charT, traits>& o, const complex<T>& x) <br> + { <br> + basic_ostringstream<charT, traits> s; <br> + s.flags(o.flags()); <br> + s.imbue(o.getloc()); <br> + s.precision(o.precision()); <br> + s << '(' << x.real() << "," << x.imag() << ')'; <br> + return o << s.str(); <br> + }</p> + +</blockquote> + +<p>Is it intended that the inserter for complex numbers ignores the +field width and does not do any padding? If, with the suggested +implementation above, the field width were set in the stream then the +opening parentheses would be adjusted, but the rest not, because the +field width is reset to zero after each insertion.</p> + +<p>I think that both operations should use sentries, for sake of +consistency with the other inserters and extractors in the +library. Regarding the issue of padding in the inserter, I don't know +what the intent was. </p> + + +<p><b>Proposed resolution:</b></p> +<p>After 26.3.6 [complex.ops] paragraph 14 (operator>>), add a +Notes clause:</p> + +<blockquote> + +<p>Notes: This extraction is performed as a series of simpler +extractions. Therefore, the skipping of whitespace is specified to be the +same for each of the simpler extractions.</p> + +</blockquote> + + +<p><b>Rationale:</b></p> +<p>For extractors, the note is added to make it clear that skipping whitespace +follows an "all-or-none" rule.</p> + +<p>For inserters, the LWG believes there is no defect; the standard is correct +as written.</p> + + + + +<hr> +<h3><a name="147"></a>147. Library Intro refers to global functions that aren't global</h3> +<p><b>Section:</b> 17.4.4.3 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 1999-06-04</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The library had many global functions until 17.4.1.1 [lib.contents] +paragraph 2 was added: </p> + +<blockquote> + +<p>All library entities except macros, operator new and operator +delete are defined within the namespace std or namespaces nested +within namespace std. </p> + +</blockquote> + +<p>It appears "global function" was never updated in the following: </p> + +<blockquote> + +<p>17.4.4.3 - Global functions [lib.global.functions]<br> +<br> +-1- It is unspecified whether any global functions in the C++ Standard +Library are defined as inline (dcl.fct.spec).<br> +<br> +-2- A call to a global function signature described in Clauses +lib.language.support through lib.input.output behaves the same as if +the implementation declares no additional global function +signatures.*<br> +<br> + [Footnote: A valid C++ program always calls the expected library + global function. An implementation may also define additional + global functions that would otherwise not be called by a valid C++ + program. --- end footnote]<br> +<br> +-3- A global function cannot be declared by the implementation as +taking additional default arguments. <br> +<br> +17.4.4.4 - Member functions [lib.member.functions]<br> +<br> +-2- An implementation can declare additional non-virtual member +function signatures within a class: </p> + + <blockquote> + +<p>-- by adding arguments with default values to a member function +signature; The same latitude does not extend to the implementation of +virtual or global functions, however. </p> + + </blockquote> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> Change "global" to "global or non-member" in:</p> +<blockquote> + <p>17.4.4.3 [lib.global.functions] section title,<br> + 17.4.4.3 [lib.global.functions] para 1,<br> + 17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2 + places in the footnote,<br> + 17.4.4.3 [lib.global.functions] para 3,<br> + 17.4.4.4 [lib.member.functions] para 2</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p> +Because operator new and delete are global, the proposed resolution +was changed from "non-member" to "global or non-member. +</p> + + + + +<hr> +<h3><a name="148"></a>148. Functions in the example facet BoolNames should be const</h3> +<p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Jeremy Siek <b>Date:</b> 1999-06-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 22.2.8 [facets.examples] paragraph 13, the do_truename() and +do_falsename() functions in the example facet BoolNames should be +const. The functions they are overriding in +numpunct_byname<char> are const. </p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.8 [facets.examples] paragraph 13, insert "const" in +two places:</p> +<blockquote> + <p><tt>string do_truename() const { return "Oui Oui!"; }<br> + string do_falsename() const { return "Mais Non!"; }</tt></p> +</blockquote> + + + + +<hr> +<h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3> +<p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Matt McClure <b>Date:</b> 1999-06-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 25.1.7 [alg.find.first.of] paragraph 2 from:</p> + +<blockquote> +<p>Returns: The first iterator i in the range [first1, last1) such +that for some integer j in the range [first2, last2) ...</p> +</blockquote> + +<p>to:</p> + +<blockquote> +<p>Returns: The first iterator i in the range [first1, last1) such +that for some iterator j in the range [first2, last2) ...</p> +</blockquote> + + + + +<hr> +<h3><a name="151"></a>151. Can't currently clear() empty container</h3> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>For both sequences and associative containers, a.clear() has the +semantics of erase(a.begin(),a.end()), which is undefined for an empty +container since erase(q1,q2) requires that q1 be dereferenceable +(23.1.1,3 and 23.1.2,7). When the container is empty, a.begin() is +not dereferenceable.<br> +<br> +The requirement that q1 be unconditionally dereferenceable causes many +operations to be intuitively undefined, of which clearing an empty +container is probably the most dire.<br> +<br> +Since q1 and q2 are only referenced in the range [q1, q2), and [q1, +q2) is required to be a valid range, stating that q1 and q2 must be +iterators or certain kinds of iterators is unnecessary. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 23.1.1, paragraph 3, change:</p> +<blockquote> + <p>p and q2 denote valid iterators to a, q and q1 denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p> +</blockquote> +<p>to:</p> +<blockquote> + <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range + in a</p> +</blockquote> +<p>In 23.1.2, paragraph 7, change:</p> +<blockquote> + <p>p and q2 are valid iterators to a, q and q1 are valid dereferenceable + iterators to a, [q1, q2) is a valid range</p> +</blockquote> +<p>to</p> +<blockquote> + <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range + into a</p> +</blockquote> + + + + +<hr> +<h3><a name="152"></a>152. Typo in <tt>scan_is()</tt> semantics</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#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described +because there is no function <tt>is()</tt> which only takes a character as +argument. Also, in the effects clause (paragraph 3), the semantic is also kept +vague.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns +clause from:</p> +<blockquote> + <p>"... such that <tt>is(*p)</tt> +would..."</p> +</blockquote> +<p>to: "... such that <tt>is(m, *p)</tt> + would...."</p> + + + + + +<hr> +<h3><a name="153"></a>153. Typo in <tt>narrow()</tt> semantics</h3> +<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a></p> +<p><b>Discussion:</b></p> +<p>The description of the array version of <tt>narrow()</tt> (in +paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which +takes only three arguments because in addition to the range a default +character is needed.</p> + +<p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have +two signatures followed by a <b>Returns</b> clause that only addresses +one of them.</p> + + + +<p><b>Proposed resolution:</b></p> +<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] +paragraph 10 from:</p> +<p> Returns: do_widen(low, high, to).</p> + +<p>to:</p> +<p> Returns: do_widen(c) or do_widen(low, high, to), +respectively.</p> + +<p>Change 22.2.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:</p> +<pre> char narrow(char c, char /*dfault*/) const; + const char* narrow(const char* low, const char* high, + char /*dfault*/, char* to) const;</pre> +<pre> Returns: do_narrow(low, high, to).</pre> +<p>to:</p> +<pre> char narrow(char c, char dfault) const; + const char* narrow(const char* low, const char* high, + char dfault, char* to) const;</pre> +<pre> Returns: do_narrow(c, dfault) or + do_narrow(low, high, dfault, to), respectively.</pre> + +<p><i>[Kona: 1) the problem occurs in additional places, 2) a user +defined version could be different.]</i></p> + + +<p><i>[Post-Tokyo: Dietmar provided the above wording at the request of +the LWG. He could find no other places the problem occurred. He +asks for clarification of the Kona "a user defined +version..." comment above. Perhaps it was a circuitous way of +saying "dfault" needed to be uncommented?]</i></p> + + +<p><i>[Post-Toronto: the issues list maintainer has merged in the +proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the +same paragraphs.]</i></p> + + + + + + +<hr> +<h3><a name="154"></a>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt></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#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The table in paragraph 7 for the length modifier does not list the length +modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the +standard asks the implementation to do undefined things when using <tt>scanf()</tt> +(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s +is actually a problem I found quite often in production code, too).</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length +Modifier table to say that for <tt>double</tt> a length modifier +<tt>l</tt> is to be used.</p> + + +<p><b>Rationale:</b></p> +<p>The standard makes an embarrassing beginner's mistake.</p> + + + + +<hr> +<h3><a name="155"></a>155. Typo in naming the class defining the class <tt>Init</tt></h3> +<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>There are conflicting statements about where the class +<tt>Init</tt> is defined. According to 27.3 [iostream.objects] paragraph 2 +it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 [ios.base] it is defined as <tt>ios_base::Init</tt>.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 27.3 [iostream.objects] paragraph 2 from +"<tt>basic_ios::Init"</tt> to +"<tt>ios_base::Init"</tt>.</p> + + +<p><b>Rationale:</b></p> +<p>Although not strictly wrong, the standard was misleading enough to warrant +the change.</p> + + + + +<hr> +<h3><a name="156"></a>156. Typo in <tt>imbue()</tt> description</h3> +<p><b>Section:</b> 27.4.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>There is a small discrepancy between the declarations of +<tt>imbue()</tt>: in 27.4.2 [ios.base] the argument is passed as +<tt>locale const&</tt> (correct), in 27.4.2.3 [ios.base.locales] it +is passed as <tt>locale const</tt> (wrong).</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.4.2.3 [ios.base.locales] change the <tt>imbue</tt> argument +from "<tt>locale const" to "locale +const&".</tt></p> + + + + +<hr> +<h3><a name="158"></a>158. Underspecified semantics for <tt>setbuf()</tt></h3> +<p><b>Section:</b> 27.5.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The default behavior of <tt>setbuf()</tt> is described only for the +situation that <tt>gptr() != 0 && gptr() != egptr()</tt>: +namely to do nothing. What has to be done in other situations +is not described although there is actually only one reasonable +approach, namely to do nothing, too.</p> + +<p>Since changing the buffer would almost certainly mess up most +buffer management of derived classes unless these classes do it +themselves, the default behavior of <tt>setbuf()</tt> should always be +to do nothing.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 27.5.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior, +to: "Default behavior: Does nothing. Returns this."</p> + + + + +<hr> +<h3><a name="159"></a>159. Strange use of <tt>underflow()</tt></h3> +<p><b>Section:</b> 27.5.2.4.3 [streambuf.virt.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The description of the meaning of the result of +<tt>showmanyc()</tt> seems to be rather strange: It uses calls to +<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because +this function only reads the current character but does not extract +it, <tt>uflow()</tt> would extract the current character. This should +be fixed to use <tt>sbumpc()</tt> instead.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 27.5.2.4.3 [streambuf.virt.get] paragraph 1, +<tt>showmanyc()</tt>returns clause, by replacing the word +"supplied" with the words "extracted from the +stream".</p> + + + + +<hr> +<h3><a name="160"></a>160. Typo: Use of non-existing function <tt>exception()</tt></h3> +<p><b>Section:</b> 27.6.1.1 [istream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The paragraph 4 refers to the function <tt>exception()</tt> which +is not defined. Probably, the referred function is +<tt>basic_ios<>::exceptions()</tt>.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted], paragraph 1, +27.6.2.1 [ostream], paragraph 3, and 27.6.2.6.1 [ostream.formatted.reqmts], +paragraph 1, change "<tt>exception()" to +"exceptions()"</tt>.</p> + +<p><i>[Note to Editor: "exceptions" with an "s" +is the correct spelling.]</i></p> + + + + + + +<hr> +<h3><a name="161"></a>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt></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#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The note in the second paragraph pretends that the first argument +is an object of type <tt>istream_iterator</tt>. This is wrong: It is +an object of type <tt>istreambuf_iterator</tt>.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 27.6.1.2.2 [istream.formatted.arithmetic] from:</p> +<blockquote> + <p>The first argument provides an object of the istream_iterator class...</p> +</blockquote> +<p>to</p> +<blockquote> + <p>The first argument provides an object of the istreambuf_iterator class...</p> +</blockquote> + + + + + +<hr> +<h3><a name="164"></a>164. do_put() has apparently unused fill argument</h3> +<p><b>Section:</b> 22.2.5.3.2 [locale.time.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-07-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 22.2.5.3.2 [locale.time.put.virtuals] the do_put() function is specified +as taking a fill character as an argument, but the description of the +function does not say whether the character is used at all and, if so, +in which way. The same holds for any format control parameters that +are accessible through the ios_base& argument, such as the +adjustment or the field width. Is strftime() supposed to use the fill +character in any way? In any case, the specification of +time_put.do_put() looks inconsistent to me.<br> <br> Is the +signature of do_put() wrong, or is the effects clause incomplete?</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add the following note after 22.2.5.3.2 [locale.time.put.virtuals] +paragraph 2:</p> +<blockquote> + <p> [Note: the <tt>fill</tt> argument may be used in the implementation-defined formats, or by derivations. A space character is a reasonable default + for this argument. --end Note]</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>The LWG felt that while the normative text was correct, +users need some guidance on what to pass for the <tt>fill</tt> +argument since the standard doesn't say how it's used.</p> + + + + +<hr> +<h3><a name="165"></a>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3> +<p><b>Section:</b> 27.6.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt> +functions falling into one of the groups "formatted output functions" +and "unformatted output functions" calls any stream buffer function +which might call a virtual function other than <tt>overflow()</tt>. Basically +this is fine but this implies that <tt>sputn()</tt> (this function would call +the virtual function <tt>xsputn()</tt>) is never called by any of the standard +output functions. Is this really intended? At minimum it would be convenient to +call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt> +is the only virtual member of <tt>basic_streambuf</tt> called is in conflict +with the definition of <tt>flush()</tt> which calls <tt>rdbuf()->pubsync()</tt> +and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed +under "unformatted output functions").</p> +<p>In addition, I guess that the sentence starting with "They may use other +public members of <tt>basic_ostream</tt> ..." probably was intended to +start with "They may use other public members of <tt>basic_streamuf</tt>..." +although the problem with the virtual members exists in both cases.</p> +<p>I see two obvious resolutions:</p> +<ol> + <li>state in a footnote that this means that <tt>xsputn()</tt> will never be + called by any ostream member and that this is intended.</li> + <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>. + Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li> +</ol> + + +<p><b>Proposed resolution:</b></p> +<p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p> +<blockquote> + <p>They may use other public members of basic_ostream except that they do not + invoke any virtual members of rdbuf() except overflow().</p> +</blockquote> +<p>to:</p> +<blockquote> + <p>They may use other public members of basic_ostream except that they shall + not invoke any virtual members of rdbuf() except overflow(), xsputn(), and + sync().</p> +</blockquote> + +<p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or +PJP why the standard is written this way.]</i></p> + + +<p><i>[Post-Tokyo: Dietmar supplied wording at the request of the +LWG. He comments: The rules can be made a little bit more specific if +necessary be explicitly spelling out what virtuals are allowed to be +called from what functions and eg to state specifically that flush() +is allowed to call sync() while other functions are not.]</i></p> + + + + + + +<hr> +<h3><a name="167"></a>167. Improper use of <tt>traits_type::length()</tt></h3> +<p><b>Section:</b> 27.6.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Paragraph 4 states that the length is determined using +<tt>traits::length(s)</tt>. Unfortunately, this function is not +defined for example if the character type is <tt>wchar_t</tt> and the +type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if +the character type is <tt>char</tt> and the type of <tt>s</tt> is +either <tt>signed char const*</tt> or <tt>unsigned char +const*</tt>.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 27.6.2.6.4 [ostream.inserters.character] paragraph 4 from:</p> +<blockquote> + <p>Effects: Behaves like an formatted inserter (as described in + lib.ostream.formatted.reqmts) of out. After a sentry object is + constructed it inserts characters. The number of characters starting + at s to be inserted is traits::length(s). Padding is determined as + described in lib.facet.num.put.virtuals. The traits::length(s) + characters starting at s are widened using out.widen + (lib.basic.ios.members). The widened characters and any required + padding are inserted into out. Calls width(0).</p> +</blockquote> +<p>to:</p> +<blockquote> + <p>Effects: Behaves like a formatted inserter (as described in + lib.ostream.formatted.reqmts) of out. After a sentry object is + constructed it inserts <i>n</i> characters starting at <i>s</i>, + where <i>n</i> is the number that would be computed as if by:</p> + <ul> + <li>traits::length(s) for the overload where the first argument is of + type basic_ostream<charT, traits>& and the second is + of type const charT*, and also for the overload where the first + argument is of type basic_ostream<char, traits>& and + the second is of type const char*.</li> + <li>std::char_traits<char>::length(s) + for the overload where the first argument is of type + basic_ostream<charT, traits>& and the second is of type + const char*.</li> + <li>traits::length(reinterpret_cast<const char*>(s)) + for the other two overloads.</li> + </ul> + <p>Padding is determined as described in + lib.facet.num.put.virtuals. The <i>n</i> characters starting at + <i>s</i> are widened using out.widen (lib.basic.ios.members). The + widened characters and any required padding are inserted into + out. Calls width(0).</p> +</blockquote> + +<p><i>[Santa Cruz: Matt supplied new wording]</i></p> + + +<p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the + number that would be computed as if by"]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>We have five separate cases. In two of them we can use the +user-supplied traits class without any fuss. In the other three we +try to use something as close to that user-supplied class as possible. +In two cases we've got a traits class that's appropriate for +char and what we've got is a const signed char* or a const +unsigned char*; that's close enough so we can just use a reinterpret +cast, and continue to use the user-supplied traits class. Finally, +there's one case where we just have to give up: where we've got a +traits class for some arbitrary charT type, and we somehow have to +deal with a const char*. There's nothing better to do but fall back +to char_traits<char></p> + + + + + +<hr> +<h3><a name="168"></a>168. Typo: formatted vs. unformatted</h3> +<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The first paragraph begins with a descriptions what has to be done +in <i>formatted</i> output functions. Probably this is a typo and the +paragraph really want to describe unformatted output functions...</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.6.2.7 [ostream.unformatted] paragraph 1, the first and last +sentences, change the word "formatted" to +"unformatted":</p> +<blockquote> + <p>"Each <b>unformatted </b> output function begins ..."<br> + "... value specified for the <b>unformatted </b> output + function."</p> +</blockquote> + + + + +<hr> +<h3><a name="169"></a>169. Bad efficiency of <tt>overflow()</tt> mandated</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#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Paragraph 8, Notes, of this section seems to mandate an extremely +inefficient way of buffer handling for <tt>basic_stringbuf</tt>, +especially in view of the restriction that <tt>basic_ostream</tt> +member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 [ostream]): For each character to be inserted, a new buffer +is to be created.</p> +<p>Of course, the resolution below requires some handling of +simultaneous input and output since it is no longer possible to update +<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible +solution is to handle this in <tt>underflow()</tt>.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.7.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words +"at least" as in the following:</p> +<blockquote> + <p>To make a write position available, the function reallocates (or initially + allocates) an array object with a sufficient number of elements to hold the + current array object (if any), plus <b>at least</b> one additional write + position.</p> +</blockquote> + + + + +<hr> +<h3><a name="170"></a>170. Inconsistent definition of <tt>traits_type</tt></h3> +<p><b>Section:</b> 27.7.4 [stringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The classes <tt>basic_stringstream</tt> (27.7.4 [stringstream]), +<tt>basic_istringstream</tt> (27.7.2 [istringstream]), and +<tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) are inconsistent +in their definition of the type <tt>traits_type</tt>: For +<tt>istringstream</tt>, this type is defined, for the other two it is +not. This should be consistent.</p> + + +<p><b>Proposed resolution:</b></p> +<p><b>Proposed resolution:</b></p> <p>To the declarations of +<tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) and +<tt>basic_stringstream</tt> (27.7.4 [stringstream]) add:</p> +<blockquote> +<pre>typedef traits traits_type;</pre> +</blockquote> + + + + +<hr> +<h3><a name="171"></a>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3> +<p><b>Section:</b> 27.8.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 [filebuf] paragraph 3, it is stated that a joint input and +output position is maintained by <tt>basic_filebuf</tt>. Still, the +description of <tt>seekpos()</tt> seems to talk about different file +positions. In particular, it is unclear (at least to me) what is +supposed to happen to the output buffer (if there is one) if only the +input position is changed. The standard seems to mandate that the +output buffer is kept and processed as if there was no positioning of +the output position (by changing the input position). Of course, this +can be exactly what you want if the flag <tt>ios_base::ate</tt> is +set. However, I think, the standard should say something like +this:</p> +<ul> + <li>If <tt>(which & mode) == 0</tt> neither read nor write position is + changed and the call fails. Otherwise, the joint read and write position is + altered to correspond to <tt>sp</tt>.</li> + <li>If there is an output buffer, the output sequences is updated and any + unshift sequence is written before the position is altered.</li> + <li>If there is an input buffer, the input sequence is updated after the + position is altered.</li> +</ul> +<p>Plus the appropriate error handling, that is...</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before +paragraph 14 from:</p> +<blockquote> + <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in | + ios_base::out);</p> + <p>Alters the file position, if possible, to correspond to the position stored + in sp (as described below).</p> + <p>- if (which&ios_base::in)!=0, set the file position to sp, then update + the input sequence</p> + <p>- if (which&ios_base::out)!=0, then update the output sequence, write + any unshift sequence, and set the file position to sp.</p> +</blockquote> +<p>to:</p> +<blockquote> + <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in | + ios_base::out);</p> + <p>Alters the file position, if possible, to correspond to the position stored + in sp (as described below). Altering the file position performs as follows:</p> + <p>1. if (om & ios_base::out)!=0, then update the output sequence and + write any unshift sequence;</p> + <p>2. set the file position to sp;</p> + <p>3. if (om & ios_base::in)!=0, then update the input sequence;</p> + <p>where om is the open mode passed to the last call to open(). The operation + fails if is_open() returns false.</p> +</blockquote> + +<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p> + +<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p> + + + + + + +<hr> +<h3><a name="172"></a>172. Inconsistent types for <tt>basic_istream::ignore()</tt></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#TC">TC</a> + <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 27.6.1.1 [istream] the function +<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first +argument. However, in 27.6.1.3 [istream.unformatted] +paragraph 23 the first argument is of type <tt>int.</tt></p> + +<p>As far as I can see this is not really a contradiction because +everything is consistent if <tt>streamsize</tt> is typedef to be +<tt>int</tt>. However, this is almost certainly not what was +intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>, +as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p> + +<p>Darin Adler also +submitted this issue, commenting: Either 27.6.1.1 should be modified +to show a first parameter of type int, or 27.6.1.3 should be modified +to show a first parameter of type streamsize and use +numeric_limits<streamsize>::max.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.6.1.3 [istream.unformatted] paragraph 23 and 24, change both uses +of <tt>int</tt> in the description of <tt>ignore()</tt> to +<tt>streamsize</tt>.</p> + + + + +<hr> +<h3><a name="173"></a>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt></h3> +<p><b>Section:</b> 27.8.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +In 27.8.1.1 [filebuf] the function <tt>setbuf()</tt> gets an +object of type <tt>streamsize</tt> as second argument. However, in +27.8.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type +<tt>int</tt>. +</p> + +<p> +As far as I can see this is not really a contradiction because +everything is consistent if <tt>streamsize</tt> is typedef to be +<tt>int</tt>. However, this is almost certainly not what was +intended. The same thing happened to <tt>basic_istream::ignore()</tt>, +as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p>In 27.8.1.5 [filebuf.virtuals] paragraph 9, change all uses of +<tt>int</tt> in the description of <tt>setbuf()</tt> to +<tt>streamsize</tt>.</p> + + + + +<hr> +<h3><a name="174"></a>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt></h3> +<p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>According to paragraph 1 of this section, <tt>streampos</tt> is the +type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in +paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p> + + +<p><b>Proposed resolution:</b></p> +<p>Change D.6 [depr.ios.members] paragraph 1 from "<tt>typedef +OFF_T streampos;</tt>" to "<tt>typedef POS_T +streampos;</tt>"</p> + + + + +<hr> +<h3><a name="175"></a>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3> +<p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>According to paragraph 8 of this section, the methods +<tt>basic_streambuf::pubseekpos()</tt>, +<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt> +"may" be overloaded by a version of this function taking the +type <tt>ios_base::open_mode</tt> as last argument argument instead of +<tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined +in this section to be an alias for one of the integral types). The +clause specifies, that the last argument has a default argument in +three cases. However, this generates an ambiguity with the overloaded +version because now the arguments are absolutely identical if the last +argument is not specified.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In D.6 [depr.ios.members] paragraph 8, remove the default arguments for +<tt>basic_streambuf::pubseekpos()</tt>, +<tt>basic_ifstream::open()</tt>, and +<tt>basic_ofstream::open().</tt></p> + + + + +<hr> +<h3><a name="176"></a>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3> +<p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The "overload" for the function <tt>exceptions()</tt> in +paragraph 8 gives the impression that there is another function of +this function defined in class <tt>ios_base</tt>. However, this is not +the case. Thus, it is hard to tell how the semantics (paragraph 9) can +be implemented: "Call the corresponding member function specified +in clause 27 [input.output]."</p> + + +<p><b>Proposed resolution:</b></p> +<p>In D.6 [depr.ios.members] paragraph 8, move the declaration of the +function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p> + + + + +<hr> +<h3><a name="179"></a>179. Comparison of const_iterators to iterators doesn't work</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#WP">WP</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-07-02</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Currently the following will not compile on two well-known standard +library implementations:</p> + +<blockquote> + <pre>#include <set> +using namespace std; + +void f(const set<int> &s) +{ + set<int>::iterator i; + if (i==s.end()); // s.end() returns a const_iterator +}</pre> +</blockquote> + +<p> +The reason this doesn't compile is because operator== was implemented +as a member function of the nested classes set:iterator and +set::const_iterator, and there is no conversion from const_iterator to +iterator. Surprisingly, (s.end() == i) does work, though, because of +the conversion from iterator to const_iterator. +</p> + +<p> +I don't see a requirement anywhere in the standard that this must +work. Should there be one? If so, I think the requirement would need +to be added to the tables in section 24.1.1. I'm not sure about the +wording. If this requirement existed in the standard, I would think +that implementors would have to make the comparison operators +non-member functions.</p> + +<p>This issues was also raised on comp.std.c++ by Darin +Adler. The example given was:</p> + +<blockquote> + <pre>bool check_equal(std::deque<int>::iterator i, +std::deque<int>::const_iterator ci) +{ +return i == ci; +}</pre> +</blockquote> + +<p>Comment from John Potter:</p> +<blockquote> + <p> + In case nobody has noticed, accepting it will break reverse_iterator. + </p> + + <p> + The fix is to make the comparison operators templated on two types. + </p> + + <pre> template <class Iterator1, class Iterator2> + bool operator== (reverse_iterator<Iterator1> const& x, + reverse_iterator<Iterator2> const& y); + </pre> + + <p> + Obviously: return x.base() == y.base(); + </p> + + <p> + Currently, no reverse_iterator to const_reverse_iterator compares are + valid. + </p> + + <p> + BTW, I think the issue is in support of bad code. Compares should be + between two iterators of the same type. All std::algorithms require + the begin and end iterators to be of the same type. + </p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>Insert this paragraph after 23.1 [container.requirements] paragraph 7:</p> +<blockquote> + <p>In the expressions</p> + <pre> i == j + i != j + i < j + i <= j + i >= j + i > j + i - j + </pre> + <p>Where i and j denote objects of a container's iterator type, + either or both may be replaced by an object of the container's + const_iterator type referring to the same element with no + change in semantics.</p> +</blockquote> + +<p><i>[post-Toronto: Judy supplied a proposed resolution saying that +<tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in +iterator comparison and difference operations.]</i></p> + + +<p><i>[Redmond: Dave and Howard supplied a new proposed resolution which +explicitly listed expressions; there was concern that the previous +proposed resolution was too informal.]</i></p> + + + +<p><b>Rationale:</b></p> +<p> +The LWG believes it is clear that the above wording applies only to +the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>, +where <tt>X</tt> is a container. There is no requirement that +<tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt> +can be mixed. If mixing them is considered important, that's a +separate issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.) +</p> + + + + +<hr> +<h3><a name="181"></a>181. make_pair() unintended behavior</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#TC">TC</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-03</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The claim has surfaced in Usenet that expressions such as<br> +<br> + <tt>make_pair("abc", 3)</tt><br> +<br> +are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template +parameter to <tt> const char (&)[4]</tt>, which type is uncopyable.<br> +<br> +I doubt anyone intended that behavior... +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 20.2 [utility], paragraph 1 change the following +declaration of make_pair():</p> +<blockquote> + <pre>template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);</pre> +</blockquote> +<p>to:</p> +<blockquote> + <pre>template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);</pre> +</blockquote> +<p> In 20.2.3 [pairs] paragraph 7 and the line before, change:</p> +<blockquote> +<pre>template <class T1, class T2> +pair<T1, T2> make_pair(const T1& x, const T2& y);</pre> +</blockquote> +<p>to:</p> +<blockquote> +<pre>template <class T1, class T2> +pair<T1, T2> make_pair(T1 x, T2 y);</pre> +</blockquote> +<p>and add the following footnote to the effects clause:</p> +<blockquote> + <p> According to 12.8 [class.copy], an implementation is permitted + to not perform a copy of an argument, thus avoiding unnecessary + copies.</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>Two potential fixes were suggested by Matt Austern and Dietmar +Kühl, respectively, 1) overloading with array arguments, and 2) use of +a reference_traits class with a specialization for arrays. Andy +Koenig suggested changing to pass by value. In discussion, it appeared +that this was a much smaller change to the standard that the other two +suggestions, and any efficiency concerns were more than offset by the +advantages of the solution. Two implementors reported that the +proposed resolution passed their test suites.</p> + + + + +<hr> +<h3><a name="182"></a>182. Ambiguous references to size_t</h3> +<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Al Stevens <b>Date:</b> 1999-08-15</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Many references to <tt> size_t</tt> throughout the document +omit the <tt> std::</tt> namespace qualification.</p> <p>For +example, 17.4.3.5 [replacement.functions] paragraph 2:</p> +<blockquote> +<pre> operator new(size_t) + operator new(size_t, const std::nothrow_t&) + operator new[](size_t) + operator new[](size_t, const std::nothrow_t&)</pre> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> In 17.4.3.5 [replacement.functions] paragraph 2: replace:</p> +<blockquote> +<p><tt> - operator new(size_t)<br> + - operator new(size_t, const std::nothrow_t&)<br> + - operator new[](size_t)<br> + - operator new[](size_t, const std::nothrow_t&)</tt></p> +</blockquote> +<p> by:</p> +<blockquote> +<pre>- operator new(std::size_t) +- operator new(std::size_t, const std::nothrow_t&) +- operator new[](std::size_t) +- operator new[](std::size_t, const std::nothrow_t&)</pre> +</blockquote> +<p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p> +<blockquote> + <p>The typedef members pointer, const_pointer, size_type, and difference_type + are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p> +</blockquote> +<p> by:</p> +<blockquote> + <p>The typedef members pointer, const_pointer, size_type, and difference_type + are required to be T*, T const*, std::size_t, and std::ptrdiff_t, + respectively.</p> +</blockquote> +<p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p> +<blockquote> + <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p> + <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it + is unspecified when or how often this function is called. The use of hint is + unspecified, but intended as an aid to locality if an implementation so + desires.</p> +</blockquote> +<p>by:</p> +<blockquote> + <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p> + <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but + it is unspecified when or how often this function is called. The use of hint + is unspecified, but intended as an aid to locality if an implementation so + desires.</p> +</blockquote> +<p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p> +<blockquote> + <p>In Table 37, X denotes a Traits class defining types and functions for the + character container type CharT; c and d denote values of type CharT; p and q + denote values of type const CharT*; s denotes a value of type CharT*; n, i and + j denote values of type size_t; e and f denote values of type X::int_type; pos + denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p> +</blockquote> +<p>by:</p> +<blockquote> + <p>In Table 37, X denotes a Traits class defining types and functions for the + character container type CharT; c and d denote values of type CharT; p and q + denote values of type const CharT*; s denotes a value of type CharT*; n, i and + j denote values of type std::size_t; e and f denote values of type X::int_type; + pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p> +</blockquote> +<p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of +X::length(p): "size_t" by "std::size_t".</p> +<p> In [lib.std.iterator.tags] 24.3.3, paragraph 2: replace:<br> + typedef ptrdiff_t difference_type;<br> + by:<br> + typedef std::ptrdiff_t difference_type;</p> +<p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the +declaration of template <class charT> class ctype.<br> +<br> + In [lib.iterator.traits] 24.3.1, paragraph 2 put namespace std { ...} around the declaration of:<br> +<br> + template<class Iterator> struct iterator_traits<br> + template<class T> struct iterator_traits<T*><br> + template<class T> struct iterator_traits<const T*></p> + + +<p><b>Rationale:</b></p> +<p>The LWG believes correcting names like <tt>size_t</tt> and +<tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt> +to be essentially editorial. There there can't be another size_t or +ptrdiff_t meant anyway because, according to 17.4.3.2.4 [extern.types],</p> + +<blockquote><p> +For each type T from the Standard C library, the types ::T and std::T +are reserved to the implementation and, when defined, ::T shall be +identical to std::T. +</p></blockquote> + +<p>The issue is treated as a Defect Report to make explicit the Project +Editor's authority to make this change.</p> + +<p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the +request of the LWG.]</i></p> + + +<p><i>[Toronto: This is tangentially related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, but only tangentially: the intent of this issue is to +address use of the name <tt>size_t</tt> in contexts outside of +namespace std, such as in the description of <tt>::operator new</tt>. +The proposed changes should be reviewed to make sure they are +correct.]</i></p> + + +<p><i>[pre-Copenhagen: Nico has reviewed the changes and believes +them to be correct.]</i></p> + + + + + + + +<hr> +<h3><a name="183"></a>183. I/O stream manipulators don't work for wide character streams</h3> +<p><b>Section:</b> 27.6.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-07-07</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.6.3 [std.manip] paragraph 3 says (clause numbering added for +exposition):</p> +<blockquote> +<p>Returns: An object s of unspecified type such that if [1] out is an (instance +of) basic_ostream then the expression out<<s behaves as if f(s) were +called, and if [2] in is an (instance of) basic_istream then the expression +in>>s behaves as if f(s) were called. Where f can be defined as: ios_base& +f(ios_base& str, ios_base::fmtflags mask) { // reset specified flags +str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression +out<<s has type ostream& and value out. [4] The expression in>>s +has type istream& and value in.</p> +</blockquote> +<p>Given the definitions [1] and [2] for out and in, surely [3] should read: +"The expression out << s has type basic_ostream& ..." and +[4] should read: "The expression in >> s has type basic_istream& +..."</p> +<p>If the wording in the standard is correct, I can see no way of implementing +any of the manipulators so that they will work with wide character streams.</p> +<p>e.g. wcout << setbase( 16 );</p> +<p>Must have value 'wcout' (which makes sense) and type 'ostream&' (which +doesn't).</p> +<p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and +8. In addition, Para 6 [setfill] has a similar error, but relates only to +ostreams.</p> +<p>I'd be happier if there was a better way of saying this, to make it clear +that the value of the expression is "the same specialization of +basic_ostream as out"&</p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace section 27.6.3 [std.manip] except paragraph 1 with the +following:</p> +<blockquote> +<p>2- The type designated smanip in each of the following function +descriptions is implementation-specified and may be different for each +function.<br> +<br> +<tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br> +<br> +-3- Returns: An object s of unspecified type such that if out is an +instance of basic_ostream<charT,traits> then the expression +out<<s behaves +as if f(s, mask) were called, or if in is an instance of +basic_istream<charT,traits> then the expression in>>s +behaves as if +f(s, mask) were called. The function f can be defined as:*<br> +<br> +[Footnote: The expression cin >> resetiosflags(ios_base::skipws) +clears ios_base::skipws in the format flags stored in the +basic_istream<charT,traits> object cin (the same as cin >> +noskipws), and the expression cout << +resetiosflags(ios_base::showbase) clears +ios_base::showbase in the format flags stored in the +basic_ostream<charT,traits> object cout (the same as cout +<< +noshowbase). --- end footnote]<br> +<br> + <tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br> + {<br> + // reset specified flags<br> + str.setf(ios_base::fmtflags(0), mask);<br> + return str;<br> + }<br> +</tt><br> +The expression out<<s has type basic_ostream<charT,traits>& and value out. +The expression in>>s has type basic_istream<charT,traits>& and value in.<br> +<br> + <tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br> +<br> +-4- Returns: An object s of unspecified type such that if out is an +instance of basic_ostream<charT,traits> then the expression +out<<s behaves +as if f(s, mask) were called, or if in is an instance of +basic_istream<charT,traits> then the expression in>>s +behaves as if f(s, +mask) were called. The function f can be defined as:<br> +<br> + <tt>ios_base& f(ios_base& str, ios_base::fmtflags mask)<br> + {<br> + // set specified flags<br> + str.setf(mask);<br> + return str;<br> + }<br> +</tt><br> +The expression out<<s has type basic_ostream<charT,traits>& and value out. +The expression in>>s has type basic_istream<charT,traits>& and value in.<br> +<br> +<tt>smanip setbase(int base);</tt><br> +<br> +-5- Returns: An object s of unspecified type such that if out is an +instance of basic_ostream<charT,traits> then the expression +out<<s behaves +as if f(s, base) were called, or if in is an instance of +basic_istream<charT,traits> then the expression in>>s +behaves as if f(s, +base) were called. The function f can be defined as:<br> +<br> + <tt>ios_base& f(ios_base& str, int base)<br> + {<br> + // set basefield<br> + str.setf(base == 8 ? ios_base::oct :<br> + base == 10 ? ios_base::dec :<br> + base == 16 ? ios_base::hex :<br> + ios_base::fmtflags(0), ios_base::basefield);<br> + return str;<br> + }<br> +</tt><br> +The expression out<<s has type basic_ostream<charT,traits>& and value out. +The expression in>>s has type basic_istream<charT,traits>& and value in.<br> +<br> +<tt>smanip setfill(char_type c);<br> +</tt><br> +-6- Returns: An object s of unspecified type such that if out is (or is +derived from) basic_ostream<charT,traits> and c has type charT +then the +expression out<<s behaves as if f(s, c) were called. The function +f can be +defined as:<br> +<br> + <tt>template<class charT, class traits><br> + basic_ios<charT,traits>& f(basic_ios<charT,traits>& str, charT c)<br> + {<br> + // set fill character<br> + str.fill(c);<br> + return str;<br> + }<br> +</tt><br> +The expression out<<s has type basic_ostream<charT,traits>& and value out.<br> +<br> +<tt>smanip setprecision(int n);</tt><br> +<br> +-7- Returns: An object s of unspecified type such that if out is an +instance of basic_ostream<charT,traits> then the expression +out<<s behaves +as if f(s, n) were called, or if in is an instance of +basic_istream<charT,traits> then the expression in>>s +behaves as if f(s, n) +were called. The function f can be defined as:<br> +<br> + <tt>ios_base& f(ios_base& str, int n)<br> + {<br> + // set precision<br> + str.precision(n);<br> + return str;<br> + }<br> +</tt><br> +The expression out<<s has type basic_ostream<charT,traits>& and value out. +The expression in>>s has type basic_istream<charT,traits>& and value in<br> +.<br> +<tt>smanip setw(int n);<br> +</tt><br> +-8- Returns: An object s of unspecified type such that if out is an +instance of basic_ostream<charT,traits> then the expression +out<<s behaves +as if f(s, n) were called, or if in is an instance of +basic_istream<charT,traits> then the expression in>>s +behaves as if f(s, n) +were called. The function f can be defined as:<br> +<br> + <tt>ios_base& f(ios_base& str, int n)<br> + {<br> + // set width<br> + str.width(n);<br> + return str;<br> + }<br> +</tt><br> +The expression out<<s has type +basic_ostream<charT,traits>& and value out. The expression +in>>s has type basic_istream<charT,traits>& and value +in. +</p> +</blockquote> + +<p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of +the proposed resolution.]</i></p> + + +<p><i>[Tokyo - The LWG noted that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> involves +the same paragraphs.]</i></p> + + +<p><i>[Post-Tokyo: The issues list maintainer combined the proposed +resolution of this issue with the proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so +intertwined that dealing with them separately appear fraught with +error. The full text was supplied by Bill Plauger; it was cross +checked against changes supplied by Andy Sawyer. It should be further +checked by the LWG.]</i></p> + + + + + + +<hr> +<h3><a name="184"></a>184. numeric_limits<bool> wording problems</h3> +<p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-07-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>bools are defined by the standard to be of integer types, as per +3.9.1 [basic.fundamental] paragraph 7. However "integer types" +seems to have a special meaning for the author of 18.2. The net effect +is an unclear and confusing specification for +numeric_limits<bool> as evidenced below.</p> + +<p>18.2.1.2/7 says numeric_limits<>::digits is, for built-in integer +types, the number of non-sign bits in the representation.</p> + +<p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero +arithmetical value converts to true.</p> + +<p>I don't think it makes sense at all to require +numeric_limits<bool>::digits and numeric_limits<bool>::digits10 to +be meaningful.</p> + +<p>The standard defines what constitutes a signed (resp. unsigned) integer +types. It doesn't categorize bool as being signed or unsigned. And the set of +values of bool type has only two elements.</p> + +<p>I don't think it makes sense to require numeric_limits<bool>::is_signed +to be meaningful.</p> + +<p>18.2.1.2/18 for numeric_limits<integer_type>::radix says:</p> +<blockquote> + <p>For integer types, specifies the base of the representation.186)</p> +</blockquote> + +<p>This disposition is at best misleading and confusing for the standard +requires a "pure binary numeration system" for integer types as per +3.9.1/7</p> + +<p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g +BCD)." This also erroneous as the standard never defines any integer +types with base representation other than 2.</p> + +<p>Furthermore, numeric_limits<bool>::is_modulo and +numeric_limits<bool>::is_signed have similar problems.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Append to the end of 18.2.1.5 [numeric.special]:</p> +<blockquote> + <p>The specialization for bool shall be provided as follows:</p> + <pre> namespace std { + template<> class numeric_limits<bool> { + public: + static const bool is_specialized = true; + static bool min() throw() { return false; } + static bool max() throw() { return true; } + + static const int digits = 1; + static const int digits10 = 0; + static const bool is_signed = false; + static const bool is_integer = true; + static const bool is_exact = true; + static const int radix = 2; + static bool epsilon() throw() { return 0; } + static bool round_error() throw() { return 0; } + + static const int min_exponent = 0; + static const int min_exponent10 = 0; + static const int max_exponent = 0; + static const int max_exponent10 = 0; + + static const bool has_infinity = false; + static const bool has_quiet_NaN = false; + static const bool has_signaling_NaN = false; + static const float_denorm_style has_denorm = denorm_absent; + static const bool has_denorm_loss = false; + static bool infinity() throw() { return 0; } + static bool quiet_NaN() throw() { return 0; } + static bool signaling_NaN() throw() { return 0; } + static bool denorm_min() throw() { return 0; } + + static const bool is_iec559 = false; + static const bool is_bounded = true; + static const bool is_modulo = false; + + static const bool traps = false; + static const bool tinyness_before = false; + static const float_round_style round_style = round_toward_zero; + }; + }</pre> +</blockquote> + +<p><i>[Tokyo: The LWG desires wording that specifies exact values +rather than more general wording in the original proposed +resolution.]</i></p> + + +<p><i>[Post-Tokyo: At the request of the LWG in Tokyo, Nico +Josuttis provided the above wording.]</i></p> + + + + + + +<hr> +<h3><a name="185"></a>185. Questionable use of term "inline"</h3> +<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> UK Panel <b>Date:</b> 1999-07-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Paragraph 4 of 20.6 [function.objects] says:</p> +<blockquote> + <p> [Example: To negate every element of a: transform(a.begin(), a.end(), + a.begin(), negate<double>()); The corresponding functions will inline + the addition and the negation. end example]</p> +</blockquote> +<p>(Note: The "addition" referred to in the above is in para 3) we can +find no other wording, except this (non-normative) example which suggests that +any "inlining" will take place in this case.</p> +<p>Indeed both:</p> +<blockquote> + <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is + unspecified whether any global functions in the C++ Standard Library + are defined as inline (7.1.2).</p> +</blockquote> +<p>and</p> +<blockquote> + <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is + unspecified whether any member functions in the C++ Standard Library + are defined as inline (7.1.2).</p> +</blockquote> +<p>take care to state that this may indeed NOT be the case.</p> +<p>Thus the example "mandates" behavior that is explicitly +not required elsewhere.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 20.6 [function.objects] paragraph 1, remove the sentence:</p> +<blockquote> +<p>They are important for the effective use of the library.</p> +</blockquote> +<p>Remove 20.6 [function.objects] paragraph 2, which reads:</p> +<blockquote> + <p> Using function objects together with function templates + increases the expressive power of the library as well as making the + resulting code much more efficient.</p> +</blockquote> +<p>In 20.6 [function.objects] paragraph 4, remove the sentence:</p> +<blockquote> + <p>The corresponding functions will inline the addition and the + negation.</p> +</blockquote> + +<p><i>[Kona: The LWG agreed there was a defect.]</i></p> + +<p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p> + + + + + + +<hr> +<h3><a name="186"></a>186. bitset::set() second parameter should be bool</h3> +<p><b>Section:</b> 23.3.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Darin Adler <b>Date:</b> 1999-08-13</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>In section 23.3.5.2 [bitset.members], paragraph 13 defines the +bitset::set operation to take a second parameter of type int. The +function tests whether this value is non-zero to determine whether to +set the bit to true or false. The type of this second parameter should +be bool. For one thing, the intent is to specify a Boolean value. For +another, the result type from test() is bool. In addition, it's +possible to slice an integer that's larger than an int. This can't +happen with bool, since conversion to bool has the semantic of +translating 0 to false and any non-zero value to true.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 23.3.5 [template.bitset] Para 1 Replace:</p> +<blockquote> +<pre>bitset<N>& set(size_t pos, int val = true ); </pre> +</blockquote> +<p>With:</p> +<blockquote> + <pre>bitset<N>& set(size_t pos, bool val = true );</pre> +</blockquote> +<p>In 23.3.5.2 [bitset.members] Para 12(.5) Replace:</p> +<blockquote> + <pre>bitset<N>& set(size_t pos, int val = 1 );</pre> +</blockquote> +<p>With:</p> +<blockquote> + <pre>bitset<N>& set(size_t pos, bool val = true );</pre> +</blockquote> + +<p><i>[Kona: The LWG agrees with the description. Andy Sawyer will work +on better P/R wording.]</i></p> + +<p><i>[Post-Tokyo: Andy provided the above wording.]</i></p> + + + +<p><b>Rationale:</b></p> +<p><tt>bool</tt> is a better choice. It is believed that binary +compatibility is not an issue, because this member function is +usually implemented as <tt>inline</tt>, and because it is already +the case that users cannot rely on the type of a pointer to a +nonvirtual member of a standard library class.</p> + + + + + +<hr> +<h3><a name="187"></a>187. iter_swap underspecified</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#WP">WP</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-14</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The description of iter_swap in 25.2.2 paragraph 7,says that it +``exchanges the values'' of the objects to which two iterators +refer.<br> <br> What it doesn't say is whether it does so using swap +or using the assignment operator and copy constructor.<br> <br> This +question is an important one to answer, because swap is specialized to +work efficiently for standard containers.<br> For example:</p> +<blockquote> +<pre>vector<int> v1, v2; +iter_swap(&v1, &v2);</pre> +</blockquote> +<p>Is this call to iter_swap equivalent to calling swap(v1, v2)? +Or is it equivalent to</p> +<blockquote> +<pre>{ +vector<int> temp = v1; +v1 = v2; +v2 = temp; +}</pre> +</blockquote> +<p>The first alternative is O(1); the second is O(n).</p> +<p>A LWG member, Dave Abrahams, comments:</p> +<blockquote> +<p>Not an objection necessarily, but I want to point out the cost of +that requirement:</p> + <blockquote> +<p><tt>iter_swap(list<T>::iterator, list<T>::iterator)</tt></p> + </blockquote> +<p>can currently be specialized to be more efficient than +iter_swap(T*,T*) for many T (by using splicing). Your proposal would +make that optimization illegal. </p> +</blockquote> + +<p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators +which are no longer permitted.]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p> +<blockquote> +<p>Exchanges the values pointed to by the two iterators a and b.</p> +</blockquote> +<p>to</p> +<blockquote> +<p><tt>swap(*a, *b)</tt>.</p> +</blockquote> + + + +<p><b>Rationale:</b></p> +<p>It's useful to say just what <tt>iter_swap</tt> does. There may be + some iterators for which we want to specialize <tt>iter_swap</tt>, + but the fully general version should have a general specification.</p> + +<p>Note that in the specific case of <tt>list<T>::iterator</tt>, +iter_swap should not be specialized as suggested above. That would do +much more than exchanging the two iterators' values: it would change +predecessor/successor relationships, possibly moving the iterator from +one list to another. That would surely be inappropriate.</p> + + + + + +<hr> +<h3><a name="189"></a>189. setprecision() not specified correctly</h3> +<p><b>Section:</b> 27.4.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-25</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision, +and includes a parenthetical note saying that it is the number of +digits after the decimal point.<br> +<br> +This claim is not strictly correct. For example, in the default +floating-point output format, setprecision sets the number of +significant digits printed, not the number of digits after the decimal +point.<br> +<br> +I would like the committee to look at the definition carefully and +correct the statement in 27.4.2.2</p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove from 27.4.2.2 [fmtflags.state], paragraph 9, the text +"(number of digits after the decimal point)".</p> + + + + +<hr> +<h3><a name="193"></a>193. Heap operations description incorrect</h3> +<p><b>Section:</b> 25.3.6 [alg.heap.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Markus Mauhart <b>Date:</b> 1999-09-24</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a></p> +<p><b>Discussion:</b></p> +<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them +is<br> +<br> + `"(1) *a is the largest element"<br> +<br> +I think this is incorrect and should be changed to the wording in the proposed +resolution.</p> +<p>Actually there are two independent changes:</p> +<blockquote> + <p>A-"part of largest equivalence class" instead of "largest", cause 25.3 + [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p> + <p>B-Take +'an oldest' from that equivalence class, otherwise the heap functions +could not be used for a priority queue as explained in 23.2.3.2.2 +[lib.priqueue.members] (where I assume that a "priority queue" respects +priority AND time).</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>Change 25.3.6 [alg.heap.operations] property (1) from:</p> +<blockquote> + <p>(1) *a is the largest element</p> +</blockquote> +<p>to:</p> +<blockquote> + <p>(1) There is no element greater than <tt>*a</tt></p> +</blockquote> + + + + + +<hr> +<h3><a name="195"></a>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</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#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-10-13</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Suppose that <tt>is.flags() & ios_base::skipws</tt> is nonzero. +What should <tt>basic_istream<>::sentry</tt>'s constructor do if it +reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it +should set failbit. Should it set eofbit as well? The standard +doesn't seem to answer that question.</p> + +<p>On the one hand, nothing in 27.6.1.1.3 [istream::sentry] says that +<tt>basic_istream<>::sentry</tt> should ever set eofbit. On the +other hand, 27.6.1.1 [istream] paragraph 4 says that if +extraction from a <tt>streambuf</tt> "returns +<tt>traits::eof()</tt>, then the input function, except as explicitly +noted otherwise, completes its actions and does +<tt>setstate(eofbit)"</tt>. So the question comes down to +whether <tt>basic_istream<>::sentry</tt>'s constructor is an +input function.</p> + +<p>Comments from Jerry Schwarz:</p> +<blockquote> +<p>It was always my intention that eofbit should be set any time that a +virtual returned something to indicate eof, no matter what reason +iostream code had for calling the virtual.</p> +<p> +The motivation for this is that I did not want to require streambufs +to behave consistently if their virtuals are called after they have +signaled eof.</p> +<p> +The classic case is a streambuf reading from a UNIX file. EOF isn't +really a state for UNIX file descriptors. The convention is that a +read on UNIX returns 0 bytes to indicate "EOF", but the file +descriptor isn't shut down in any way and future reads do not +necessarily also return 0 bytes. In particular, you can read from +tty's on UNIX even after they have signaled "EOF". (It +isn't always understood that a ^D on UNIX is not an EOF indicator, but +an EOL indicator. By typing a "line" consisting solely of +^D you cause a read to return 0 bytes, and by convention this is +interpreted as end of file.)</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p> +<blockquote> +<p>If <tt>is.rdbuf()->sbumpc()</tt> or <tt>is.rdbuf()->sgetc()</tt> +returns <tt>traits::eof()</tt>, the function calls +<tt>setstate(failbit | eofbit)</tt> (which may throw +<tt>ios_base::failure</tt>). +</p> +</blockquote> + + + + +<hr> +<h3><a name="198"></a>198. Validity of pointers and references unspecified after iterator destruction</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#WP">WP</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 1999-11-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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Is a pointer or reference obtained from an iterator still valid after +destruction of the iterator? +</p> +<p> +Is a pointer or reference obtained from an iterator still valid after the value +of the iterator changes? +</p> +<blockquote> +<pre>#include <iostream> +#include <vector> +#include <iterator> + +int main() +{ + typedef std::vector<int> vec_t; + vec_t v; + v.push_back( 1 ); + + // Is a pointer or reference obtained from an iterator still + // valid after destruction of the iterator? + int * p = &*v.begin(); + std::cout << *p << '\n'; // OK? + + // Is a pointer or reference obtained from an iterator still + // valid after the value of the iterator changes? + vec_t::iterator iter( v.begin() ); + p = &*iter++; + std::cout << *p << '\n'; // OK? + + return 0; +} +</pre> +</blockquote> + +<p>The standard doesn't appear to directly address these +questions. The standard needs to be clarified. At least two real-world +cases have been reported where library implementors wasted +considerable effort because of the lack of clarity in the +standard. The question is important because requiring pointers and +references to remain valid has the effect for practical purposes of +prohibiting iterators from pointing to cached rather than actual +elements of containers.</p> + +<p>The standard itself assumes that pointers and references obtained +from an iterator are still valid after iterator destruction or +change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 [reverse.iter.conv], which returns a reference, defines +effects:</p> + +<blockquote> + <pre>Iterator tmp = current; +return *--tmp;</pre> +</blockquote> +<p>The definition of reverse_iterator::operator->(), 24.4.1.3.4 +[reverse.iter.op.star], which returns a pointer, defines effects:</p> +<blockquote> + <pre>return &(operator*());</pre> +</blockquote> + +<p>Because the standard itself assumes pointers and references remain +valid after iterator destruction or change, the standard should say so +explicitly. This will also reduce the chance of user code breaking +unexpectedly when porting to a different standard library +implementation.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add a new paragraph to 24.1 [iterator.requirements]:</p> +<blockquote><p> +Destruction of an iterator may invalidate pointers and references +previously obtained from that iterator. +</p></blockquote> + +<p>Replace paragraph 1 of 24.4.1.3.3 [reverse.iter.conv] with:</p> + +<blockquote> +<p><b>Effects:</b></p> +<pre> this->tmp = current; + --this->tmp; + return *this->tmp; +</pre> + +<p> +[<i>Note:</i> This operation must use an auxiliary member variable, +rather than a temporary variable, to avoid returning a reference that +persists beyond the lifetime of its associated iterator. (See +24.1 [iterator.requirements].) The name of this member variable is shown for +exposition only. <i>--end note</i>] +</p> +</blockquote> + +<p><i>[Post-Tokyo: The issue has been reformulated purely +in terms of iterators.]</i></p> + + +<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation +assumption by reverse_iterator. The issue and proposed resolution was +reformulated yet again to reflect this reality.]</i></p> + + +<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator +assumes its underlying iterator has persistent pointers and +references. Andy Koenig pointed out that it is possible to rewrite +reverse_iterator so that it no longer makes such an assupmption. +However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>. If we +decide it is intentional that <tt>p[n]</tt> may return by value +instead of reference when <tt>p</tt> is a Random Access Iterator, +other changes in reverse_iterator will be necessary.]</i></p> + + + +<p><b>Rationale:</b></p> +<p>This issue has been discussed extensively. Note that it is +<i>not</i> an issue about the behavior of predefined iterators. It is +asking whether or not user-defined iterators are permitted to have +transient pointers and references. Several people presented examples +of useful user-defined iterators that have such a property; examples +include a B-tree iterator, and an "iota iterator" that doesn't point +to memory. Library implementors already seem to be able to cope with +such iterators: they take pains to avoid forming references to memory +that gets iterated past. The only place where this is a problem is +<tt>reverse_iterator</tt>, so this issue changes +<tt>reverse_iterator</tt> to make it work.</p> + +<p>This resolution does not weaken any guarantees provided by +predefined iterators like <tt>list<int>::iterator</tt>. +Clause 23 should be reviewed to make sure that guarantees for +predefined iterators are as strong as users expect.</p> + + + + + + +<hr> +<h3><a name="199"></a>199. What does <tt>allocate(0)</tt> return?</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#TC">TC</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Suppose that <tt>A</tt> is a class that conforms to the +Allocator requirements of Table 32, and <tt>a</tt> is an +object of class <tt>A</tt> What should be the return +value of <tt>a.allocate(0)</tt>? Three reasonable +possibilities: forbid the argument <tt>0</tt>, return +a null pointer, or require that the return value be a +unique non-null pointer. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add a note to the <tt>allocate</tt> row of Table 32: +"[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p> + + +<p><b>Rationale:</b></p> +<p>A key to understanding this issue is that the ultimate use of +allocate() is to construct an iterator, and that iterator for zero +length sequences must be the container's past-the-end +representation. Since this already implies special case code, it +would be over-specification to mandate the return value. +</p> + + + + +<hr> +<h3><a name="200"></a>200. Forward iterator requirements don't allow constant iterators</h3> +<p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In table 74, the return type of the expression <tt>*a</tt> is given +as <tt>T&</tt>, where <tt>T</tt> is the iterator's value type. +For constant iterators, however, this is wrong. ("Value type" +is never defined very precisely, but it is clear that the value type +of, say, <tt>std::list<int>::const_iterator</tt> is supposed to be +<tt>int</tt>, not <tt>const int</tt>.) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the +return type from "<tt>T&</tt>" to "<tt>T&</tt> +if <tt>X</tt> is mutable, otherwise <tt>const T&</tt>". +In the <tt>a->m</tt> row, change the return type from +"<tt>U&</tt>" to "<tt>U&</tt> if <tt>X</tt> is mutable, +otherwise <tt>const U&</tt>". +</p> + +<p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg; +there are multiple const problems with the STL portion of the library +and that these should be addressed as a single package. Note +that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a> has already been declared NAD Future for +that very reason.]</i></p> + + +<p><i>[Redmond: the LWG thinks this is separable from other constness +issues. This issue is just cleanup; it clarifies language that was +written before we had iterator_traits. Proposed resolution was +modified: the original version only discussed *a. It was pointed out +that we also need to worry about *r++ and a->m.]</i></p> + + + + + + + +<hr> +<h3><a name="201"></a>201. Numeric limits terminology wrong</h3> +<p><b>Section:</b> 18.2.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Stephen Cleary <b>Date:</b> 1999-12-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In some places in this section, the terms "fundamental types" and +"scalar types" are used when the term "arithmetic types" is intended. +The current usage is incorrect because void is a fundamental type and +pointers are scalar types, neither of which should have +specializations of numeric_limits. +</p> +<p><i>[Lillehammer: it remains true that numeric_limits is using + imprecise language. However, none of the proposals for changed + wording are clearer. A redesign of numeric_limits is needed, but this + is more a task than an open issue.]</i></p> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Change 18.2 [support.limits] to: +</p> + +<blockquote> +<p> +-1- The headers <tt><limits></tt>, <tt><climits></tt>, +<tt><cfloat></tt>, and <tt><cinttypes></tt> supply +characteristics of implementation-dependent <del>fundamental</del> +<ins>arithmetic</ins> types (3.9.1). +</p> +</blockquote> + +<p> +Change 18.2.1 [limits] to: +</p> + +<blockquote> +<p> +-1- The <tt>numeric_limits</tt> component provides a C++ program with +information about various properties of the implementation's +representation of the <del>fundamental</del> <ins>arithmetic</ins> +types. +</p> +<p> +-2- Specializations shall be provided for each <del>fundamental</del> +<ins>arithmetic</ins> type, both floating point and integer, including +<tt>bool</tt>. The member <tt>is_specialized</tt> shall be <tt>true</tt> +for all such specializations of <tt>numeric_limits</tt>. +</p> +<p> +-4- Non-<del>fundamental</del><ins>arithmetic</ins> standard types, such +as <tt>complex<T></tt> (26.3.2), shall not have specializations. +</p> +</blockquote> + +<p> +Change 18.2.1.1 [numeric.limits] to: +</p> + +<blockquote> +<p> +<del>-1- The member <tt>is_specialized</tt> makes it possible to distinguish +between fundamental types, which have specializations, and non-scalar types, +which do not.</del> +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="202"></a>202. unique() effects unclear when predicate not an equivalence relation</h3> +<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-01-13</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +What should unique() do if you give it a predicate that is not an +equivalence relation? There are at least two plausible answers: +</p> + +<blockquote> + +<p> + 1. You can't, because 25.2.8 says that it it "eliminates all but + the first element from every consecutive group of equal + elements..." and it wouldn't make sense to interpret "equal" as + meaning anything but an equivalence relation. [It also doesn't + make sense to interpret "equal" as meaning ==, because then there + would never be any sense in giving a predicate as an argument at + all.] +</p> + +<p> + 2. The word "equal" should be interpreted to mean whatever the + predicate says, even if it is not an equivalence relation + (and in particular, even if it is not transitive). +</p> + +</blockquote> + +<p> +The example that raised this question is from Usenet: +</p> + +<blockquote> + +<pre>int f[] = { 1, 3, 7, 1, 2 }; +int* z = unique(f, f+5, greater<int>());</pre> + +</blockquote> + +<p> +If one blindly applies the definition using the predicate +greater<int>, and ignore the word "equal", you get: +</p> + +<blockquote> + +<p> + Eliminates all but the first element from every consecutive group + of elements referred to by the iterator i in the range [first, last) + for which *i > *(i - 1). +</p> + +</blockquote> + +<p> +The first surprise is the order of the comparison. If we wanted to +allow for the predicate not being an equivalence relation, then we +should surely compare elements the other way: pred(*(i - 1), *i). If +we do that, then the description would seem to say: "Break the +sequence into subsequences whose elements are in strictly increasing +order, and keep only the first element of each subsequence". So the +result would be 1, 1, 2. If we take the description at its word, it +would seem to call for strictly DEcreasing order, in which case the +result should be 1, 3, 7, 2.<br> +<br> +In fact, the SGI implementation of unique() does neither: It yields 1, +3, 7. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 25.2.9 [alg.unique] paragraph 1 to:</p> +<blockquote><p> +For a nonempty range, eliminates all but the first element from every +consecutive group of equivalent elements referred to by the iterator +<tt>i</tt> in the range [first+1, last) for which the following +conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) != +false</tt>. +</p></blockquote> + +<p> +Also insert a new paragraph, paragraph 2a, that reads: "Requires: The +comparison function must be an equivalence relation." +</p> + +<p><i>[Redmond: discussed arguments for and against requiring the +comparison function to be an equivalence relation. Straw poll: +14-2-5. First number is to require that it be an equivalence +relation, second number is to explicitly not require that it be an +equivalence relation, third number is people who believe they need +more time to consider the issue. A separate issue: Andy Sawyer +pointed out that "i-1" is incorrect, since "i" can refer to the first +iterator in the range. Matt provided wording to address this +problem.]</i></p> + + +<p><i>[Curaçao: The LWG changed "... the range (first, +last)..." to "... the range [first+1, last)..." for +clarity. They considered this change close enough to editorial to not +require another round of review.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The LWG also considered an alternative resolution: change +25.2.9 [alg.unique] paragraph 1 to:</p> + +<blockquote><p> +For a nonempty range, eliminates all but the first element from every +consecutive group of elements referred to by the iterator +<tt>i</tt> in the range (first, last) for which the following +conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) != +false</tt>. +</p></blockquote> + +<p> +Also insert a new paragraph, paragraph 1a, that reads: "Notes: The +comparison function need not be an equivalence relation." +</p> + + +<p>Informally: the proposed resolution imposes an explicit requirement +that the comparison function be an equivalence relation. The +alternative resolution does not, and it gives enough information so +that the behavior of unique() for a non-equivalence relation is +specified. Both resolutions are consistent with the behavior of +existing implementations.</p> + + + + + +<hr> +<h3><a name="206"></a>206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</h3> +<p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-08-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>As specified, the implementation of the nothrow version of operator +new does not necessarily call the ordinary operator new, but may +instead simply call the same underlying allocator and return a null +pointer instead of throwing an exception in case of failure.</p> + +<p>Such an implementation breaks code that replaces the ordinary +version of new, but not the nothrow version. If the ordinary version +of new/delete is replaced, and if the replaced delete is not +compatible with pointers returned from the library versions of new, +then when the replaced delete receives a pointer allocated by the +library new(nothrow), crash follows.</p> + +<p>The fix appears to be that the lib version of new(nothrow) must +call the ordinary new. Thus when the ordinary new gets replaced, the +lib version will call the replaced ordinary new and things will +continue to work.</p> + +<p>An alternative would be to have the ordinary new call +new(nothrow). This seems sub-optimal to me as the ordinary version of +new is the version most commonly replaced in practice. So one would +still need to replace both ordinary and nothrow versions if one wanted +to replace the ordinary version.</p> + +<p>Another alternative is to put in clear text that if one version is +replaced, then the other must also be replaced to maintain +compatibility. Then the proposed resolution below would just be a +quality of implementation issue. There is already such text in +paragraph 7 (under the new(nothrow) version). But this nuance is +easily missed if one reads only the paragraphs relating to the +ordinary new.</p> + +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html">N2158</a> +has been written explaining the rationale for the proposed resolution below. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 18.5.1.1 [new.delete.single]: +</p> + +<blockquote> +<pre>void* operator new(std::size_t <i>size</i>, const std::nothrow_t&) throw(); +</pre> +<blockquote> +<p> +-5- <i>Effects:</i> Same as above, except that it is called by a placement +version of a <i>new-expression</i> when a C++ program prefers a null pointer result as +an error indication, instead of a <tt>bad_alloc</tt> exception. +</p> + +<p> +-6- <i>Replaceable:</i> a C++ program may define a function with this function +signature that displaces the default version defined by the C++ Standard +library. +</p> + +<p> +-7- <i>Required behavior:</i> Return a non-null pointer to suitably aligned +storage (3.7.4), or else return a null pointer. This nothrow version of operator +new returns a pointer obtained as if acquired from the <ins>(possibly +replaced)</ins> ordinary version. This requirement is binding on a replacement +version of this function. +</p> + +<p> +-8- <i>Default behavior:</i> +</p> +<ul> +<li><ins> +Calls <tt>operator new(<i>size</i>)</tt>. +</ins></li> +<li><ins> +If the call to <tt>operator new(<i>size</i>)</tt> returns normally, returns +the result of that call, else +</ins></li> +<li><ins> +if the call to <tt>operator new(<i>size</i>)</tt> throws an exception, returns +a null pointer. +</ins></li> +<li><del> +Executes a loop: Within the loop, the function first attempts to allocate the +requested storage. Whether the attempt involves a call to the Standard C library +function <tt>malloc</tt> is unspecified. +</del></li> +<li><del> +Returns a pointer to the allocated storage if the attempt is successful. +Otherwise, if the last argument to <tt>set_new_handler()</tt> was a null +pointer, return a null pointer. +</del></li> +<li><del> +Otherwise, the function calls the current <i>new_handler</i> (18.5.2.2). If the +called function returns, the loop repeats. +</del></li> +<li><del> +The loop terminates when an attempt to allocate the requested storage is +successful or when a called <i>new_handler</i> function does not return. If the +called <i>new_handler</i> function terminates by throwing a <tt>bad_alloc +exception</tt>, the function returns a null pointer. +</del></li> +</ul> +<p> +-9- [<i>Example:</i> +</p> +<blockquote><pre>T* p1 = new T; <i>// throws bad_alloc if it fails</i> +T* p2 = new(nothrow) T; <i>// returns 0 if it fails</i> +</pre></blockquote> +<p> +--<i>end example</i>] +</p> +</blockquote> + +<pre>void operator delete(void* <i>ptr</i>) throw(); +<del>void operator delete(void* <i>ptr</i>, const std::nothrow_t&) throw();</del> +</pre> + +<blockquote> +<p> +-10- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by a +<i>delete-expression</i> to render the value of <tt><i>ptr</i></tt> invalid. +</p> +<p> +-11- <i>Replaceable:</i> a C++ program may define a function with this function +signature that displaces the default version defined by the C++ Standard +library. +</p> +<p> +-12- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the value +returned by an earlier call to the <del>default</del> <ins>(possibly +replaced)</ins> <tt>operator new(std::size_t)</tt> or <tt>operator +new(std::size_t, const std::nothrow_t&)</tt>. +</p> +<p> +-13- <i>Default behavior:</i> +</p> +<ul> +<li> +For a null value of <tt><i>ptr</i></tt>, do nothing. +</li> +<li> +Any other value of <tt><i>ptr</i></tt> shall be a value returned earlier by a +call to the default <tt>operator new</tt>, which was not invalidated by an +intervening call to <tt>operator delete(void*)</tt> (17.4.3.7). For such a +non-null value of <tt><i>ptr</i></tt>, reclaims storage allocated by the earlier +call to the default <tt>operator new</tt>. +</li> +</ul> +<p> +-14- <i>Remarks:</i> It is unspecified under what conditions part or all of +such reclaimed storage is allocated by a subsequent call to <tt>operator +new</tt> or any of <tt>calloc</tt>, <tt>malloc</tt>, or <tt>realloc</tt>, +declared in <tt><cstdlib></tt>. +</p> +</blockquote> + +<pre><ins>void operator delete(void* <i>ptr</i>, const std::nothrow_t&) throw();</ins> +</pre> + +<blockquote> +<p><ins> +-15- <i>Effects:</i> Same as above, except that it is called by the +implementation when an exception propagates from a nothrow placement version +of the <i>new-expression</i> (i.e. when the constructor throws an exception). +</ins></p> +<p><ins> +-16- <i>Replaceable:</i> a C++ program may define a function with this function +signature that displaces the default version defined by the C++ Standard +library. +</ins></p> +<p><ins> +-17- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the +value returned by an earlier call to the (possibly replaced) <tt>operator +new(std::size_t)</tt> or <tt>operator new(std::size_t, const +std::nothrow_t&)</tt>. </ins></p> +<p><ins> +-18- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt>. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 18.5.1.2 [new.delete.array] +</p> + +<blockquote> +<pre>void* operator new[](std::size_t <i>size</i>, const std::nothrow_t&) throw(); +</pre> + +<blockquote> +<p> +-5- <i>Effects:</i> Same as above, except that it is called by a placement +version of a <i>new-expression</i> when a C++ program prefers a null pointer result as +an error indication, instead of a <tt>bad_alloc</tt> exception. +</p> + +<p> +-6- <i>Replaceable:</i> a C++ program can define a function with this function +signature that displaces the default version defined by the C++ Standard +library. +</p> + +<p> +-7- <i>Required behavior:</i> <del>Same as for operator <tt>new(std::size_t, +const std::nothrow_t&)</tt>. This nothrow version of operator <tt>new[]</tt> +returns a pointer obtained as if acquired from the ordinary version.</del> +<ins>Return a non-null pointer to suitably aligned storage (3.7.4), or else +return a null pointer. This nothrow version of operator new returns a pointer +obtained as if acquired from the (possibly replaced) <tt>operator +new[](std::size_t <i>size</i>)</tt>. This requirement is binding on a +replacement version of this function.</ins> +</p> + +<p> +-8- <i>Default behavior:</i> <del>Returns <tt>operator new(<i>size</i>, +nothrow)</tt>.</del> +</p> + +<ul> +<li><ins> +Calls <tt>operator new[](<i>size</i>)</tt>. +</ins></li> +<li><ins> +If the call to <tt>operator new[](<i>size</i>)</tt> returns normally, returns +the result of that call, else +</ins></li> +<li><ins> +if the call to <tt>operator new[](<i>size</i>)</tt> throws an exception, returns +a null pointer. +</ins></li> +</ul> +</blockquote> + +<pre>void operator delete[](void* <i>ptr</i>) throw(); +void operator delete[](void* <i>ptr</i>, const std::nothrow_t&) throw(); +</pre> + +<blockquote> +<p> +-9- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by the +array form of a <i>delete-expression</i> to render the value of +<tt><i>ptr</i></tt> invalid. +</p> + +<p> +-10- <i>Replaceable:</i> a C++ program can define a function with this function +signature that displaces the default version defined by the C++ Standard +library. +</p> + +<p> +-11- <i>Requires:</i> the value of +<tt><i>ptr</i></tt> is null or the value returned by an earlier call to +<tt>operator new[](std::size_t)</tt> or <tt>operator new[](std::size_t, const +std::nothrow_t&)</tt>. +</p> + +<p> +-12- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt> or +<tt>operator delete<ins>[]</ins>(<i>ptr</i><del>, std::nothrow</del>)</tt> respectively. +</p> +</blockquote> + +</blockquote> + + + +<p><b>Rationale:</b></p> +<p>Yes, they may become unlinked, and that is by design. If a user +replaces one, the user should also replace the other.</p> + +<p><i>[ +Reopened due to a gcc conversation between Howard, Martin and Gaby. Forwarding +or not is visible behavior to the client and it would be useful for the client +to know which behavior it could depend on. +]</i></p> + + +<p><i>[ +Batavia: Robert voiced serious reservations about backwards compatibility for +his customers. +]</i></p> + + + + + + +<hr> +<h3><a name="208"></a>208. Unnecessary restriction on past-the-end iterators</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#TC">TC</a> + <b>Submitter:</b> Stephen Cleary <b>Date:</b> 2000-02-02</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and +past-the-end values are always non-singular."</p> +<p>This places an unnecessary restriction on past-the-end iterators for +containers with forward iterators (for example, a singly-linked list). If the +past-the-end value on such a container was a well-known singular value, it would +still satisfy all forward iterator requirements.</p> +<p>Removing this restriction would allow, for example, a singly-linked list +without a "footer" node.</p> +<p>This would have an impact on existing code that expects past-the-end +iterators obtained from different (generic) containers being not equal.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 24.1 [iterator.requirements] paragraph 5, the last sentence, from:</p> +<blockquote> +<p>Dereferenceable and past-the-end values are always non-singular.</p> +</blockquote> +<p>to:</p> +<blockquote> +<p>Dereferenceable values are always non-singular. </p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>For some kinds of containers, including singly linked lists and +zero-length vectors, null pointers are perfectly reasonable past-the-end +iterators. Null pointers are singular. +</p> + + + + +<hr> +<h3><a name="209"></a>209. basic_string declarations 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#TC">TC</a> + <b>Submitter:</b> Igor Stauder <b>Date:</b> 2000-02-11</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In Section 21.3 [basic.string] the basic_string member function +declarations use a consistent style except for the following functions:</p> +<blockquote> + <pre>void push_back(const charT); +basic_string& assign(const basic_string&); +void swap(basic_string<charT,traits,Allocator>&);</pre> +</blockquote> +<p>- push_back, assign, swap: missing argument name <br> +- push_back: use of const with charT (i.e. POD type passed by value +not by reference - should be charT or const charT& )<br> +- swap: redundant use of template parameters in argument +basic_string<charT,traits,Allocator>&</p> + + +<p><b>Proposed resolution:</b></p> +<p>In Section 21.3 [basic.string] change the basic_string member +function declarations push_back, assign, and swap to:</p> +<blockquote> + <pre>void push_back(charT c); + +basic_string& assign(const basic_string& str); +void swap(basic_string& str);</pre> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>Although the standard is in general not consistent in declaration +style, the basic_string declarations are consistent other than the +above. The LWG felt that this was sufficient reason to merit the +change. +</p> + + + + +<hr> +<h3><a name="210"></a>210. distance first and last confused</h3> +<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-02-15</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In paragraph 9 of section 25 [algorithms], it is written:</p> +<blockquote> + <p> In the description of the algorithms operators + 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-b is the same + as of<br> + <br> + <tt>return distance(a, b);</tt></p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>On the last line of paragraph 9 of section 25 [algorithms] change +<tt>"a-b"</tt> to <tt>"b-a".</tt></p> + + +<p><b>Rationale:</b></p> +<p>There are two ways to fix the defect; change the description to b-a +or change the return to distance(b,a). The LWG preferred the +former for consistency.</p> + + + + +<hr> +<h3><a name="211"></a>211. operator>>(istream&, string&) doesn't set failbit</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#TC">TC</a> + <b>Submitter:</b> Scott Snyder <b>Date:</b> 2000-02-04</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The description of the stream extraction operator for std::string (section +21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in +the case that the operator fails to extract any characters from the input +stream.</p> +<p>This implies that the typical construction</p> +<blockquote> + <pre>std::istream is; +std::string str; +... +while (is >> str) ... ;</pre> +</blockquote> +<p>(which tests failbit) is not required to terminate at EOF.</p> +<p>Furthermore, this is inconsistent with other extraction operators, +which do include this requirement. (See sections 27.6.1.2 [istream.formatted] and 27.6.1.3 [istream.unformatted]), where this +requirement is present, either explicitly or implicitly, for the +extraction operators. It is also present explicitly in the description +of getline (istream&, string&, charT) in section 21.3.8.9 [string.io] paragraph 8.)</p> + + +<p><b>Proposed resolution:</b></p> +<p>Insert new paragraph after paragraph 2 in section 21.3.8.9 [string.io]:</p> +<blockquote> + +<p>If the function extracts no characters, it calls +is.setstate(ios::failbit) which may throw ios_base::failure +(27.4.4.3).</p> +</blockquote> + + + + +<hr> +<h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</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#TC">TC</a> + <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The standard doesn't specify what min_element() and max_element() shall +return if the range is empty (first equals last). The usual implementations +return last. This problem seems also apply to partition(), stable_partition(), +next_permutation(), and prev_permutation().</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 25.3.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and +9, append: Returns last if first==last.</p> + + +<p><b>Rationale:</b></p> +<p>The LWG looked in some detail at all of the above mentioned +algorithms, but believes that except for min_element() and +max_element() it is already clear that last is returned if first == +last.</p> + + + + +<hr> +<h3><a name="214"></a>214. set::find() missing const overload</h3> +<p><b>Section:</b> 23.3.3 [set], 23.3.4 [multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-28</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#450">450</a></p> +<p><b>Discussion:</b></p> +<p>The specification for the associative container requirements in +Table 69 state that the find member function should "return +iterator; const_iterator for constant a". The map and multimap +container descriptions have two overloaded versions of find, but set +and multiset do not, all they have is:</p> +<blockquote> + <pre>iterator find(const key_type & x) const;</pre> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>Change the prototypes for find(), lower_bound(), upper_bound(), and +equal_range() in section 23.3.3 [set] and section 23.3.4 [multiset] to each have two overloads:</p> +<blockquote> + <pre>iterator find(const key_type & x); +const_iterator find(const key_type & x) const;</pre> + <pre>iterator lower_bound(const key_type & x); +const_iterator lower_bound(const key_type & x) const;</pre> + <pre>iterator upper_bound(const key_type & x); +const_iterator upper_bound(const key_type & x) const;</pre> + <pre>pair<iterator, iterator> equal_range(const key_type & x); +pair<const_iterator, const_iterator> equal_range(const key_type & x) const;</pre> +</blockquote> + +<p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording +extending the proposed resolution to lower_bound, upper_bound, and +equal_range.]</i></p> + + + + + + +<hr> +<h3><a name="217"></a>217. Facets example (Classifying Japanese characters) contains errors</h3> +<p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-02-29</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The example in 22.2.8, paragraph 11 contains the following errors:</p> +<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function +must be const in order for it to be callable on a const object (a reference to +which which is what std::use_facet<>() returns).</p> +<p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the +name of the namespace `My'.</p> +<p>3) In the definition of `loc' and subsequently in the call to use_facet<>() +in main(), the name of the facet is misspelled: it should read `My::JCtype' +rather than `My::JCType'.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace the "Classifying Japanese characters" example in 22.2.8, +paragraph 11 with the following:</p> +<pre>#include <locale></pre> +<pre>namespace My { + using namespace std; + class JCtype : public locale::facet { + public: + static locale::id id; // required for use as a new locale facet + bool is_kanji (wchar_t c) const; + JCtype() {} + protected: + ~JCtype() {} + }; +}</pre> +<pre>// file: filt.C +#include <iostream> +#include <locale> +#include "jctype" // above +std::locale::id My::JCtype::id; // the static JCtype member +declared above.</pre> +<pre>int main() +{ + using namespace std; + typedef ctype<wchar_t> wctype; + locale loc(locale(""), // the user's preferred locale... + new My::JCtype); // and a new feature ... + wchar_t c = use_facet<wctype>(loc).widen('!'); + if (!use_facet<My::JCtype>(loc).is_kanji(c)) + cout << "no it isn't!" << endl; + return 0; +}</pre> + + + + +<hr> +<h3><a name="220"></a>220. ~ios_base() usage valid?</h3> +<p><b>Section:</b> 27.4.2.7 [ios.base.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 2000-03-13</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7 +paragraph 2:</p> +<blockquote> + <p>Effects: Destroys an object of class ios_base. Calls each registered + callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such + time that any ios_base member function called from within fn has well defined + results.</p> +</blockquote> +<p>But what is not clear is: If no callback functions were ever registered, does +it matter whether the ios_base members were ever initialized?</p> +<p>For instance, does this program have defined behavior:</p> +<blockquote> + <pre>#include <ios></pre> + <pre>class D : public std::ios_base { };</pre> + <pre>int main() { D d; }</pre> +</blockquote> +<p>It seems that registration of a callback function would surely affect the +state of an ios_base. That is, when you register a callback function with an +ios_base, the ios_base must record that fact somehow.</p> +<p>But if after construction the ios_base is in an indeterminate state, and that +state is not made determinate before the destructor is called, then how would +the destructor know if any callbacks had indeed been registered? And if the +number of callbacks that had been registered is indeterminate, then is not the +behavior of the destructor undefined?</p> +<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes +it explicit that destruction before initialization results in undefined +behavior.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Modify 27.4.2.7 paragraph 1 from</p> +<blockquote> + <p>Effects: Each ios_base member has an indeterminate value after + construction.</p> +</blockquote> +<p>to</p> +<blockquote> + <p>Effects: Each ios_base member has an indeterminate +value after construction. These members must be initialized by calling +basic_ios::init. If an ios_base object is destroyed before these +initializations have taken place, the behavior is undefined.</p> +</blockquote> + + + + +<hr> +<h3><a name="221"></a>221. num_get<>::do_get stage 2 processing broken</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#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-03-14</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Stage 2 processing of numeric conversion is broken.</p> + +<p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral +conversion specifier is %i. A %i specifier determines a number's base +by its prefix (0 for octal, 0x for hex), so the intention is clearly +that a 0x prefix is allowed. Paragraph 8 in the same section, +however, describes very precisely how characters are processed. (It +must be done "as if" by a specified code fragment.) That +description does not allow a 0x prefix to be recognized.</p> + +<p>Very roughly, stage 2 processing reads a char_type ct. It converts +ct to a char, not by using narrow but by looking it up in a +translation table that was created by widening the string literal +"0123456789abcdefABCDEF+-". The character "x" is +not found in that table, so it can't be recognized by stage 2 +processing.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.2.1.2 paragraph 8, replace the line:</p> +<blockquote> + <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre> +</blockquote> +<p>with the line:</p> +<blockquote> + <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>If we're using the technique of widening a string literal, the +string literal must contain every character we wish to recognize. +This technique has the consequence that alternate representations +of digits will not be recognized. This design decision was made +deliberately, with full knowledge of that limitation.</p> + + + + + +<hr> +<h3><a name="222"></a>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3> +<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-03-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p> +<blockquote> + <pre>21.3.6.8 - basic_string::compare [lib.string::compare] + +int compare(size_type pos1, size_type n1, + const basic_string<charT,traits,Allocator>& str , + size_type pos2 , size_type n2 ) const; + +-4- Returns: + + basic_string<charT,traits,Allocator>(*this,pos1,n1).compare( + basic_string<charT,traits,Allocator>(str,pos2,n2)) .</pre> +</blockquote> +<p>and the constructor that's implicitly called by the above is +defined to throw an out-of-range exception if pos > str.size(). See +section 21.3.1 [string.require] paragraph 4.</p> + +<p>On the other hand, the compare function descriptions themselves don't have +"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements +that do not apply to a function are omitted.</p> +<p>So it seems there is an inconsistency in the standard -- are the +"Effects" clauses correct, or are the "Throws" clauses +missing?</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 17.3.1.3 [structure.specifications] paragraph 3, the footnote 148 attached to +the sentence "Descriptions of function semantics contain the +following elements (as appropriate):", insert the word +"further" so that the foot note reads:</p> +<blockquote> + <p>To save space, items that do not apply to a function are + omitted. For example, if a function does not specify any further + preconditions, there will be no "Requires" paragraph.</p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>The standard is somewhat inconsistent, but a failure to note a +throw condition in a throws clause does not grant permission not to +throw. The inconsistent wording is in a footnote, and thus +non-normative. The proposed resolution from the LWG clarifies the +footnote.</p> + + + + +<hr> +<h3><a name="223"></a>223. reverse algorithm should use iter_swap rather than swap</h3> +<p><b>Section:</b> 25.2.10 [alg.reverse] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-03-21</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 25.2.10 [alg.reverse], replace:</p> + <blockquote><p> + Effects: For each non-negative integer i <= (last - first)/2, + applies swap to all pairs of iterators first + i, (last - i) - 1. + </p></blockquote> +<p>with:</p> + <blockquote><p> + Effects: For each non-negative integer i <= (last - first)/2, + applies iter_swap to all pairs of iterators first + i, (last - i) - 1. + </p></blockquote> + + + + +<hr> +<h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> + <b>Submitter:</b> Ed Brey <b>Date:</b> 2000-03-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>In the associative container requirements table in 23.1.2 paragraph 7, +a.clear() has complexity "log(size()) + N". However, the meaning of N +is not defined.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In the associative container requirements table in 23.1.2 paragraph +7, the complexity of a.clear(), change "log(size()) + N" to +"linear in <tt>size()</tt>".</p> + + +<p><b>Rationale:</b></p> +<p>It's the "log(size())", not the "N", that is in +error: there's no difference between <i>O(N)</i> and <i>O(N + +log(N))</i>. The text in the standard is probably an incorrect +cut-and-paste from the range version of <tt>erase</tt>.</p> + + + + +<hr> +<h3><a name="225"></a>225. std:: algorithms use of other unqualified algorithms</h3> +<p><b>Section:</b> 17.4.4.3 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in +user namespaces might be found through Koenig lookup?</p> +<p>For example, a popular standard library implementation includes this +implementation of std::unique:</p> +<blockquote> +<pre>namespace std { + template <class _ForwardIter> + _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) { + __first = adjacent_find(__first, __last); + return unique_copy(__first, __last, __first); + } + }</pre> +</blockquote> +<p>Imagine two users on opposite sides of town, each using unique on his own +sequences bounded by my_iterators . User1 looks at his standard library +implementation and says, "I know how to implement a more efficient +unique_copy for my_iterators", and writes:</p> +<blockquote> +<pre>namespace user1 { + class my_iterator; + // faster version for my_iterator + my_iterator unique_copy(my_iterator, my_iterator, my_iterator); + }</pre> +</blockquote> +<p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p> +<p>User2 has other needs, and writes:</p> +<blockquote> +<pre>namespace user2 { + class my_iterator; + // Returns true iff *c is a unique copy of *a and *b. + bool unique_copy(my_iterator a, my_iterator b, my_iterator c); + }</pre> +</blockquote> +<p>User2 is shocked to find later that his fully-qualified use of +std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to +compile (if he's lucky). Looking in the standard, he sees the following Effects +clause for unique():</p> +<blockquote> + <p>Effects: Eliminates all but the first element from every consecutive group + of equal elements referred to by the iterator i in the range [first, last) for + which the following corresponding conditions hold: *i == *(i - 1) or pred(*i, + *(i - 1)) != false</p> +</blockquote> +<p>The standard gives user2 absolutely no reason to think he can interfere with +std::unique by defining names in namespace user2. His standard library has been +built with the template export feature, so he is unable to inspect the +implementation. User1 eventually compiles his code with another compiler, and +his version of unique_copy silently stops being called. Eventually, he realizes +that he was depending on an implementation detail of his library and had no +right to expect his unique_copy() to be called portably.</p> +<p>On the face of it, and given above scenario, it may seem obvious that the +implementation of unique() shown is non-conforming because it uses unique_copy() +rather than ::std::unique_copy(). Most standard library implementations, +however, seem to disagree with this notion.</p> +<p> <i>[Tokyo: Steve Adamczyk from +the core working group indicates that "std::" is sufficient; +leading "::" qualification is not required because any namespace +qualification is sufficient to suppress Koenig lookup.]</i></p> + + +<p><b>Proposed resolution:</b></p> +<p>Add a paragraph and a note at the end of +17.4.4.3 [global.functions]:</p> +<blockquote> + +<p>Unless otherwise specified, no global or non-member function in the +standard library shall use a function from another namespace which is +found through <i>argument-dependent name lookup</i> (3.4.2 [basic.lookup.argdep]).</p> + +<p>[Note: the phrase "unless otherwise specified" is intended to +allow Koenig lookup in cases like that of ostream_iterators:<br> + +<br> + Effects:</p> + <blockquote> +<p>*out_stream << value;<br> + if(delim != 0) *out_stream << delim;<br> + return (*this);</p> + <p>--end note]</p> + </blockquote> +</blockquote> + +<p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but +is as yet unsure if the proposed resolution is the best +solution. Furthermore, the LWG believes that the same problem of +unqualified library names applies to wording in the standard itself, +and has opened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> accordingly. Any resolution of +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be coordinated with the resolution of +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p> + + +<p><i>[Toronto: The LWG is not sure if this is a defect in the +standard. Most LWG members believe that an implementation of +<tt>std::unique</tt> like the one quoted in this issue is already +illegal, since, under certain circumstances, its semantics are not +those specified in the standard. The standard's description of +<tt>unique</tt> does not say that overloading <tt>adjacent_find</tt> +should have any effect.]</i></p> + + +<p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues +225, 226, and 229. Their conclusion was that the issues should be +separated into an LWG portion (Howard's paper, N1387=02-0045), and a +EWG portion (Dave will write a proposal). The LWG and EWG had +(separate) discussions of this plan the next day. The proposed +resolution for this issue is in accordance with Howard's paper.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>It could be argued that this proposed isn't strictly necessary, + that the Standard doesn't grant implementors license to write a + standard function that behaves differently than specified in the + Standard just because of an unrelated user-defined name in some + other namespace. However, this is at worst a clarification. It is + surely right that algorithsm shouldn't pick up random names, that + user-defined names should have no effect unless otherwise specified. + Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> deals with the question of when it is + appropriate for the standard to explicitly specify otherwise.</p> + + + + + +<hr> +<h3><a name="226"></a>226. User supplied specializations or overloads of namespace std function templates</h3> +<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The issues are: </p> +<p>1. How can a 3rd party library implementor (lib1) write a version of a standard +algorithm which is specialized to work with his own class template? </p> +<p>2. How can another library implementor (lib2) write a generic algorithm which +will take advantage of the specialized algorithm in lib1?</p> +<p>This appears to be the only viable answer under current language rules:</p> +<blockquote> + <pre>namespace lib1 +{ + // arbitrary-precision numbers using T as a basic unit + template <class T> + class big_num { //... + }; + </pre> + <pre> // defining this in namespace std is illegal (it would be an + // overload), so we hope users will rely on Koenig lookup + template <class T> + void swap(big_int<T>&, big_int<T>&); +}</pre> + <pre>#include <algorithm> +namespace lib2 +{ + template <class T> + void generic_sort(T* start, T* end) + { + ... + // using-declaration required so we can work on built-in types + using std::swap; + // use Koenig lookup to find specialized algorithm if available + swap(*x, *y); + } +}</pre> +</blockquote> +<p>This answer has some drawbacks. First of all, it makes writing lib2 difficult +and somewhat slippery. The implementor needs to remember to write the +using-declaration, or generic_sort will fail to compile when T is a built-in +type. The second drawback is that the use of this style in lib2 effectively +"reserves" names in any namespace which defines types which may +eventually be used with lib2. This may seem innocuous at first when applied to +names like swap, but consider more ambiguous names like unique_copy() instead. +It is easy to imagine the user wanting to define these names differently in his +own namespace. A definition with semantics incompatible with the standard +library could cause serious problems (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>).</p> +<p>Why, you may ask, can't we just partially specialize std::swap()? It's +because the language doesn't allow for partial specialization of function +templates. If you write:</p> +<blockquote> + <pre>namespace std +{ + template <class T> + void swap(lib1::big_int<T>&, lib1::big_int<T>&); +}</pre> +</blockquote> +<p>You have just overloaded std::swap, which is illegal under the current +language rules. On the other hand, the following full specialization is legal:</p> +<blockquote> + <pre>namespace std +{ + template <> + void swap(lib1::other_type&, lib1::other_type&); +}</pre> +</blockquote> + +<p>This issue reflects concerns raised by the "Namespace issue +with specialized swap" thread on comp.lang.c++.moderated. A +similar set of concerns was earlier raised on the boost.org mailing +list and the ACCU-general mailing list. Also see library reflector +message c++std-lib-7354.</p> + +<p> +J. C. van Winkel points out (in c++std-lib-9565) another unexpected +fact: it's impossible to output a container of std::pair's using copy +and an ostream_iterator, as long as both pair-members are built-in or +std:: types. That's because a user-defined operator<< for (for +example) std::pair<const std::string, int> will not be found: +lookup for operator<< will be performed only in namespace std. +Opinions differed on whether or not this was a defect, and, if so, +whether the defect is that something is wrong with user-defined +functionality and std, or whether it's that the standard library does +not provide an operator<< for std::pair<>. +</p> + + + +<p><b>Proposed resolution:</b></p> + +<p>Adopt the wording proposed in Howard Hinnant's paper + N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p> + + +<p><i>[Tokyo: Summary, "There is no conforming way to extend +std::swap for user defined templates." The LWG agrees that +there is a problem. Would like more information before +proceeding. This may be a core issue. Core issue 229 has been opened +to discuss the core aspects of this problem. It was also noted that +submissions regarding this issue have been received from several +sources, but too late to be integrated into the issues list. +]</i></p> + + +<p><i>[Post-Tokyo: A paper with several proposed resolutions, +J16/00-0029==WG21/N1252, "Shades of namespace std functions +" by Alan Griffiths, is in the Post-Tokyo mailing. It +should be considered a part of this issue.]</i></p> + + +<p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a +resolution that involves core changes: it would add partial +specialization of function template. The Core Working Group is +reluctant to add partial specialization of function templates. It is +viewed as a large change, CWG believes that proposal presented leaves +some syntactic issues unanswered; if the CWG does add partial +specialization of function templates, it wishes to develop its own +proposal. The LWG continues to believe that there is a serious +problem: there is no good way for users to force the library to use +user specializations of generic standard library functions, and in +certain cases (e.g. transcendental functions called by +<tt>valarray</tt> and <tt>complex</tt>) this is important. Koenig +lookup isn't adequate, since names within the library must be +qualified with <tt>std</tt> (see issue 225), specialization doesn't +work (we don't have partial specialization of function templates), and +users aren't permitted to add overloads within namespace std. +]</i></p> + + +<p><i>[Copenhagen: Discussed at length, with no consensus. Relevant +papers in the pre-Copenhagen mailing: N1289, N1295, N1296. Discussion +focused on four options. (1) Relax restrictions on overloads within +namespace std. (2) Mandate that the standard library use unqualified +calls for <tt>swap</tt> and possibly other functions. (3) Introduce +helper class templates for <tt>swap</tt> and possibly other functions. +(4) Introduce partial specialization of function templates. Every +option had both support and opposition. Straw poll (first number is +support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8; +(4) 4, 4.]</i></p> + + +<p><i>[Redmond: Discussed, again no consensus. Herb presented an +argument that a user who is defining a type <tt>T</tt> with an +associated <tt>swap</tt> should not be expected to put that +<tt>swap</tt> in namespace std, either by overloading or by partial +specialization. The argument is that <tt>swap</tt> is part of +<tt>T</tt>'s interface, and thus should to in the same namespace as +<tt>T</tt> and only in that namespace. If we accept this argument, +the consequence is that standard library functions should use +unqualified call of <tt>swap</tt>. (And which other functions? Any?) +A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will +try to put together a proposal before the next meeting.]</i></p> + + +<p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues +225, 226, and 229. Their conclusion was that the issues should be +separated into an LWG portion (Howard's paper, N1387=02-0045), and a +EWG portion (Dave will write a proposal). The LWG and EWG had +(separate) discussions of this plan the next day. The proposed +resolution is the one proposed by Howard.]</i></p> + + +<p><i>[Santa Cruz: the LWG agreed with the general direction of + Howard's paper, N1387. (Roughly: Koenig lookup is disabled unless + we say otherwise; this issue is about when we do say otherwise.) + However, there were concerns about wording. Howard will provide new + wording. Bill and Jeremy will review it.]</i></p> + + +<p><i>[Kona: Howard proposed the new wording. The LWG accepted his + proposed resolution.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>Informally: introduce a Swappable concept, and specify that the + value types of the iterators passed to certain standard algorithms + (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform + to that concept. The Swappable concept will make it clear that + these algorithms use unqualified lookup for the calls + to <tt>swap</tt>. Also, in 26.5.3.3 [valarray.transcend] paragraph 1, + state that the valarray transcendentals use unqualified lookup.</p> + + + + + +<hr> +<h3><a name="227"></a>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</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#TC">TC</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-09</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#TC">TC</a> status.</p> +<p><b>Discussion:</b></p> +<p>25.2.2 reads:</p> +<blockquote> + <p><tt> template<class T> void swap(T& a, T& b);</tt><br> + <br> + Requires: Type T is Assignable (_lib.container.requirements_).<br> + Effects: Exchanges values stored in two locations.</p> +</blockquote> +<p>The only reasonable** generic implementation of swap requires construction of a + new temporary copy of one of its arguments:</p> +<blockquote> +<pre>template<class T> void swap(T& a, T& b); + { + T tmp(a); + a = b; + b = tmp; + }</pre> +</blockquote> +<p>But a type which is only Assignable cannot be swapped by this implementation.</p> +<p>**Yes, there's also an unreasonable implementation which would require T to be + DefaultConstructible instead of CopyConstructible. I don't think this is worthy + of consideration:</p> +<blockquote> +<pre>template<class T> void swap(T& a, T& b); +{ + T tmp; + tmp = a; + a = b; + b = tmp; +}</pre> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>Change 25.2.2 paragraph 1 from:</p> +<blockquote> +<p> Requires: Type T is Assignable (23.1).</p> +</blockquote> +<p>to:</p> +<blockquote> +<p> Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p> +</blockquote> + + + + + +<hr> +<h3><a name="228"></a>228. Incorrect specification of "..._byname" facets</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#WP">WP</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The sections 22.2.1.2 [locale.ctype.byname], 22.2.1.5 +[locale.codecvt.byname], +sref ref="22.2.1.6", 22.2.3.2 [locale.numpunct.byname], 22.2.4.2 +[locale.collate.byname], 22.2.5.4 [locale.time.put.byname], 22.2.6.4 +[locale.moneypunct.byname], and 22.2.7.2 [locale.messages.byname] +overspecify the +definitions of the "..._byname" classes by listing a bunch +of virtual functions. At the same time, no semantics of these +functions are defined. Real implementations do not define these +functions because the functional part of the facets is actually +implemented in the corresponding base classes and the constructor of +the "..._byname" version just provides suitable date used by +these implementations. For example, the 'numpunct' methods just return +values from a struct. The base class uses a statically initialized +struct while the derived version reads the contents of this struct +from a table. However, no virtual function is defined in +'numpunct_byname'.</p> + +<p>For most classes this does not impose a problem but specifically +for 'ctype' it does: The specialization for 'ctype_byname<char>' +is required because otherwise the semantics would change due to the +virtual functions defined in the general version for 'ctype_byname': +In 'ctype<char>' the method 'do_is()' is not virtual but it is +made virtual in both 'ctype<cT>' and 'ctype_byname<cT>'. +Thus, a class derived from 'ctype_byname<char>' can tell whether +this class is specialized or not under the current specification: +Without the specialization, 'do_is()' is virtual while with +specialization it is not virtual.</p> + + +<p><b>Proposed resolution:</b></p> +<p> Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p> +<pre> namespace std { + template <class charT> + class ctype_byname : public ctype<charT> { + public: + typedef ctype<charT>::mask mask; + explicit ctype_byname(const char*, size_t refs = 0); + protected: + ~ctype_byname(); // virtual + }; + }</pre> +<p> Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p> +<pre> namespace std { + template <class internT, class externT, class stateT> + class codecvt_byname : public codecvt<internT, externT, stateT> { + public: + explicit codecvt_byname(const char*, size_t refs = 0); + protected: + ~codecvt_byname(); // virtual + }; + } +</pre> +<p> Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p> +<pre> namespace std { + template <class charT> + class numpunct_byname : public numpunct<charT> { + // this class is specialized for char and wchar_t. + public: + typedef charT char_type; + typedef basic_string<charT> string_type; + explicit numpunct_byname(const char*, size_t refs = 0); + protected: + ~numpunct_byname(); // virtual + }; + }</pre> +<p> Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p> +<pre> namespace std { + template <class charT> + class collate_byname : public collate<charT> { + public: + typedef basic_string<charT> string_type; + explicit collate_byname(const char*, size_t refs = 0); + protected: + ~collate_byname(); // virtual + }; + }</pre> +<p> Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p> +<pre> namespace std { + template <class charT, class InputIterator = istreambuf_iterator<charT> > + class time_get_byname : public time_get<charT, InputIterator> { + public: + typedef time_base::dateorder dateorder; + typedef InputIterator iter_type</pre> +<pre> explicit time_get_byname(const char*, size_t refs = 0); + protected: + ~time_get_byname(); // virtual + }; + }</pre> +<p> Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p> +<pre> namespace std { + template <class charT, class OutputIterator = ostreambuf_iterator<charT> > + class time_put_byname : public time_put<charT, OutputIterator> + { + public: + typedef charT char_type; + typedef OutputIterator iter_type;</pre> +<pre> explicit time_put_byname(const char*, size_t refs = 0); + protected: + ~time_put_byname(); // virtual + }; + }"</pre> +<p> Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p> +<pre> namespace std { + template <class charT, bool Intl = false> + class moneypunct_byname : public moneypunct<charT, Intl> { + public: + typedef money_base::pattern pattern; + typedef basic_string<charT> string_type;</pre> +<pre> explicit moneypunct_byname(const char*, size_t refs = 0); + protected: + ~moneypunct_byname(); // virtual + }; + }</pre> +<p> Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p> +<pre> namespace std { + template <class charT> + class messages_byname : public messages<charT> { + public: + typedef messages_base::catalog catalog; + typedef basic_string<charT> string_type;</pre> +<pre> explicit messages_byname(const char*, size_t refs = 0); + protected: + ~messages_byname(); // virtual + }; + }</pre> +<p>Remove section 22.2.1.4 [locale.codecvt] completely (because in +this case only those members are defined to be virtual which are +defined to be virtual in 'ctype<cT>'.)</p> + +<p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of +the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>.]</i></p> + + +<p><i>[Copenhagen: proposed resolution was revised slightly, to remove +three last virtual functions from <tt>messages_byname</tt>.]</i></p> + + + + + + + +<hr> +<h3><a name="229"></a>229. Unqualified references of other library entities</h3> +<p><b>Section:</b> 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 2000-04-19</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Throughout the library chapters, the descriptions of library entities refer +to other library entities without necessarily qualifying the names.</p> + +<p>For example, section 25.2.2 "Swap" describes the effect of +swap_ranges in terms of the unqualified name "swap". This section +could reasonably be interpreted to mean that the library must be implemented so +as to do a lookup of the unqualified name "swap", allowing users to +override any ::std::swap function when Koenig lookup applies.</p> + +<p>Although it would have been best to use explicit qualification with +"::std::" throughout, too many lines in the standard would have to be +adjusted to make that change in a Technical Corrigendum.</p> + +<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of +<tt>size_t</tt>, is a special case of this. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p> +<blockquote> + <p>Whenever a name x defined in the standard library is mentioned, the name x + is assumed to be fully qualified as ::std::x, unless explicitly described + otherwise. For example, if the Effects section for library function F is + described as calling library function G, the function ::std::G is meant.</p> +</blockquote> + +<p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of +the LWG to solve a problem in the standard itself similar to the +problem within implementations of library identified by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>. Any resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be +coordinated with the resolution of this issue.]</i></p> + + +<p><i>[post-Toronto: Howard is undecided about whether it is +appropriate for all standard library function names referred to in +other standard library functions to be explicitly qualified by +<tt>std</tt>: it is common advice that users should define global +functions that operate on their class in the same namespace as the +class, and this requires argument-dependent lookup if those functions +are intended to be called by library code. Several LWG members are +concerned that valarray appears to require argument-dependent lookup, +but that the wording may not be clear enough to fall under +"unless explicitly described otherwise".]</i></p> + + +<p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues +225, 226, and 229. Their conclusion was that the issues should be +separated into an LWG portion (Howard's paper, N1387=02-0045), and a +EWG portion (Dave will write a proposal). The LWG and EWG had +(separate) discussions of this plan the next day. This paper resolves +issues 225 and 226. In light of that resolution, the proposed +resolution for the current issue makes sense.]</i></p> + + + + + + + +<hr> +<h3><a name="230"></a>230. Assignable specified without also specifying CopyConstructible</h3> +<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2000-04-26</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> identified an instance (std::swap) where +Assignable was specified without also specifying +CopyConstructible. The LWG asked that the standard be searched to +determine if the same defect existed elsewhere.</p> + +<p>There are a number of places (see proposed resolution below) where +Assignable is specified without also specifying +CopyConstructible. There are also several cases where both are +specified. For example, 26.4.1 [rand.req].</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 23.1 [container.requirements] table 65 for value_type: +change "T is Assignable" to "T is CopyConstructible and +Assignable" +</p> + +<p>In 23.1.4 [associative.reqmts] table 69 X::key_type; change +"Key is Assignable" to "Key is +CopyConstructible and Assignable"<br> +</p> + +<p>In 24.1.2 [output.iterators] paragraph 1, change: +</p> +<blockquote> +<p> A class or a built-in type X satisfies the requirements of an +output iterator if X is an Assignable type (23.1) and also the +following expressions are valid, as shown in Table 73: +</p> +</blockquote> +<p>to: +</p> +<blockquote> +<p> A class or a built-in type X satisfies the requirements of an +output iterator if X is a CopyConstructible (20.1.3) and Assignable +type (23.1) and also the following expressions are valid, as shown in +Table 73: +</p> +</blockquote> + +<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of +the LWG. He asks that the 25.2.5 [alg.replace] and 25.2.6 [alg.fill] changes be studied carefully, as it is not clear that +CopyConstructible is really a requirement and may be +overspecification.]</i></p> + + +<p><i>[Portions of the resolution for issue 230 have been superceded by +the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The original proposed resolution also included changes to input +iterator, fill, and replace. The LWG believes that those changes are +not necessary. The LWG considered some blanket statement, where an +Assignable type was also required to be Copy Constructible, but +decided against this because fill and replace really don't require the +Copy Constructible property.</p> + + + + +<hr> +<h3><a name="231"></a>231. Precision in iostream?</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#WP">WP</a> + <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 2000-04-25</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>What is the following program supposed to output?</p> +<pre>#include <iostream> + + int + main() + { + std::cout.setf( std::ios::scientific , std::ios::floatfield ) ; + std::cout.precision( 0 ) ; + std::cout << 1.00 << '\n' ; + return 0 ; + }</pre> +<p>From my C experience, I would expect "1e+00"; this is what +<tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs +"1.000000e+00".</p> + +<p>The only indication I can find in the standard is 22.2.2.2.2/11, +where it says "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." +This is an obvious error, however, fixed is not a mask for a field, +but a value that a multi-bit field may take -- the results of and'ing +fmtflags with ios::fixed are not defined, at least not if +ios::scientific has been set. G++'s behavior corresponds to what might +happen if you do use (flags & fixed) != 0 with a typical +implementation (floatfield == 3 << something, fixed == 1 +<< something, and scientific == 2 << something).</p> + +<p>Presumably, the intent is either (flags & floatfield) != 0, or +(flags & floatfield) == fixed; the first gives something more or +less like the effect of precision in a printf floating point +conversion. Only more or less, of course. In order to implement printf +formatting correctly, you must know whether the precision was +explicitly set or not. Say by initializing it to -1, instead of 6, and +stating that for floating point conversions, if precision < -1, 6 +will be used, for fixed point, if precision < -1, 1 will be used, +etc. Plus, of course, if precision == 0 and flags & floatfield == +0, 1 should be = used. But it probably isn't necessary to emulate all +of the anomalies of printf:-).</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Replace 22.2.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following +sentence: +</p> +<blockquote><p> +For conversion from a floating-point type, +<tt><i>str</i>.precision()</tt> is specified in the conversion +specification. +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p>The floatfield determines whether numbers are formatted as if +with %f, %e, or %g. If the <tt>fixed</tt> bit is set, it's %f, +if <tt>scientific</tt> it's %e, and if both bits are set, or +neither, it's %g.</p> +<p>Turning to the C standard, a precision of 0 is meaningful +for %f and %e. For %g, precision 0 is taken to be the same as +precision 1.</p> +<p>The proposed resolution has the effect that if neither +<tt>fixed</tt> nor <tt>scientific</tt> is set we'll be +specifying a precision of 0, which will be internally +turned into 1. There's no need to call it out as a special +case.</p> +<p>The output of the above program will be "1e+00".</p> + +<p><i>[Post-Curaçao: Howard provided improved wording covering the case +where precision is 0 and mode is %g.]</i></p> + + + + + + + +<hr> +<h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3> +<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-04-18</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed +specializations of standard templates to those that "depend on a +user-defined name of external linkage."</p> +<p>This term, however, is not adequately defined, making it possible to +construct a specialization that is, I believe, technically legal according to +17.4.3.1/1, but that specializes a standard template for a built-in type such as +'int'.</p> +<p>The following code demonstrates the problem:</p> +<blockquote> + <pre>#include <algorithm></pre> + <pre>template<class T> struct X +{ + typedef T type; +};</pre> + <pre>namespace std +{ + template<> void swap(::X<int>::type& i, ::X<int>::type& j); +}</pre> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>Change "user-defined name" to "user-defined +type".</p> + + +<p><b>Rationale:</b></p> +<p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++ +Programming Language</i>. It disallows the example in the issue, +since the underlying type itself is not user-defined. The only +possible problem I can see is for non-type templates, but there's no +possible way for a user to come up with a specialization for bitset, +for example, that might not have already been specialized by the +implementor?</p> + +<p><i>[Toronto: this may be related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>.]</i></p> + + +<p><i>[post-Toronto: Judy provided the above proposed resolution and +rationale.]</i></p> + + + + + + +<hr> +<h3><a name="233"></a>233. Insertion hints in associative containers</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-04-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#192">192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#246">246</a></p> +<p><b>Discussion:</b></p> +<p> +If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator +into the multimap, then <tt>mm.insert(p, x)</tt> inserts +<tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as +to where it should go. Table 69 claims that the execution time is +amortized constant if the insert winds up taking place adjacent to +<tt>p</tt>, but does not say when, if ever, this is guaranteed to +happen. All it says it that <tt>p</tt> is a hint as to where to +insert. +</p> +<p> +The question is whether there is any guarantee about the relationship +between <tt>p</tt> and the insertion point, and, if so, what it +is. +</p> +<p> +I believe the present state is that there is no guarantee: The user +can supply <tt>p</tt>, and the implementation is allowed to +disregard it entirely. +</p> + +<p><b>Additional comments from Nathan:</b><br> + +The vote [in Redmond] was on whether to elaborately specify the use of +the hint, or to require behavior only if the value could be inserted +adjacent to the hint. I would like to ensure that we have a chance to +vote for a deterministic treatment: "before, if possible, otherwise +after, otherwise anywhere appropriate", as an alternative to the +proposed "before or after, if possible, otherwise [...]". +</p> + +<p><i>[Toronto: there was general agreement that this is a real defect: +when inserting an element x into a multiset that already contains +several copies of x, there is no way to know whether the hint will be +used. The proposed resolution was that the new element should always +be inserted as close to the hint as possible. So, for example, if +there is a subsequence of equivalent values, then providing a.begin() +as the hint means that the new element should be inserted before the +subsequence even if a.begin() is far away. JC van Winkel supplied +precise wording for this proposed resolution, and also for an +alternative resolution in which hints are only used when they are +adjacent to the insertion point.]</i></p> + + +<p><i>[Copenhagen: the LWG agreed to the original proposed resolution, +in which an insertion hint would be used even when it is far from the +insertion point. This was contingent on seeing a example +implementation showing that it is possible to implement this +requirement without loss of efficiency. John Potter provided such a +example implementation.]</i></p> + + +<p><i>[Redmond: The LWG was reluctant to adopt the proposal that +emerged from Copenhagen: it seemed excessively complicated, and went +beyond fixing the defect that we identified in Toronto. PJP provided +the new wording described in this issue. Nathan agrees that we +shouldn't adopt the more detailed semantics, and notes: "we know that +you can do it efficiently enough with a red-black tree, but there are +other (perhaps better) balanced tree techniques that might differ +enough to make the detailed semantics hard to satisfy."]</i></p> + + +<p><i>[Curaçao: Nathan should give us the alternative wording he +suggests so the LWG can decide between the two options.]</i></p> + + +<p><i>[Lillehammer: The LWG previously rejected the more detailed + semantics, because it seemed more loike a new feature than like + defect fixing. We're now more sympathetic to it, but we (especially + Bill) are still worried about performance. N1780 describes a naive + algorithm, but it's not clear whether there is a non-naive + implementation. Is it possible to implement this as efficently as + the current version of insert?]</i></p> + + +<p><i>[Post Lillehammer: +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">N1780</a> +updated in post meeting mailing with +feedback from Lillehammer with more information regarding performance. +]</i></p> + + +<p><i>[ +Batavia: +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a> +accepted with minor wording changes in the proposed wording (reflected in the +proposed resolution below). Concerns about the performance of the algorithm +were satisfactorily met by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>. +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a> already handles the stability of equal ranges +and so that part of the resolution from +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a> +is no longer needed (or reflected in the proposed wording below). +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> + +<p> +Change the indicated rows of the "Associative container requirements" Table in +23.1.4 [associative.reqmts] to: +</p> + +<p></p><center> +<table border="1"> +<caption>Associative container requirements</caption> +<tbody><tr><th>expression</th> <th>return type</th> +<th>assertion/note<br>pre/post-condition</th> +<th>complexity</th></tr> +<tr><td><tt>a_eq.insert(t)</tt></td> +<td><tt>iterator</tt></td> +<td> +inserts <tt>t</tt> and returns the iterator pointing to the newly inserted +element. <ins>If a range containing elements equivalent to <tt>t</tt> exists in +<tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that range.</ins> +</td> +<td> +logarithmic +</td></tr> +<tr><td><tt>a.insert(p,t)</tt></td> +<td><tt>iterator</tt></td> +<td> +inserts <tt>t</tt> if and only if there is no element with key equivalent to the +key of <tt>t</tt> in containers with unique keys; always inserts <tt>t</tt> in containers +with equivalent keys. always returns the iterator pointing to the element with key +equivalent to the key of <tt>t</tt>. <del>iterator <tt>p</tt> is a hint pointing to where +the insert should start to search.</del> <ins><tt>t</tt> is inserted as close as possible +to the position just prior to <tt>p</tt>.</ins> +</td> +<td> +logarithmic in general, but amortized constant if <tt>t</tt> is inserted right <del>after</del> + <ins>before</ins> <tt>p</tt>. +</td></tr> +</tbody></table> +</center> + + + + + + +<hr> +<h3><a name="234"></a>234. Typos in allocator definition</h3> +<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and +<tt>destruct()</tt> are described as returns but the functions actually +return <tt>void</tt>.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Substitute "Returns" by "Effect".</p> + + + + +<hr> +<h3><a name="235"></a>235. No specification of default ctor for reverse_iterator</h3> +<p><b>Section:</b> 24.4.1.1 [reverse.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The declaration of <tt>reverse_iterator</tt> lists a default +constructor. However, no specification is given what this constructor +should do.</p> + + +<p><b>Proposed resolution:</b></p> + <p>In section 24.4.1.3.1 [reverse.iter.cons] add the following + paragraph:</p> + <blockquote> + <p><tt>reverse_iterator()</tt></p> + + <p>Default initializes <tt>current</tt>. Iterator operations + applied to the resulting iterator have defined behavior if and + only if the corresponding operations are defined on a default + constructed iterator of type <tt>Iterator</tt>.</p> + </blockquote> + <p><i>[pre-Copenhagen: Dietmar provide wording for proposed + resolution.]</i></p> + + + + + + +<hr> +<h3><a name="237"></a>237. Undefined expression in complexity specification</h3> +<p><b>Section:</b> 23.2.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The complexity specification in paragraph 6 says that the complexity +is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is +defined on iterators this term is in general undefined because it +would have to be <tt>last - first</tt>.</p> + + +<p><b>Proposed resolution:</b></p> + <p>Change paragraph 6 from</p> + <blockquote><p>Linear in <i>first - last</i>.</p></blockquote> + <p>to become</p> + <blockquote><p>Linear in <i>distance(first, last)</i>.</p></blockquote> + + + + +<hr> +<h3><a name="238"></a>238. Contradictory results of stringbuf initialization.</h3> +<p><b>Section:</b> 27.7.1.1 [stringbuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-05-11</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of +'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine +that far but consider this code:</p> + +<pre> std::basic_stringbuf<char> sbuf("hello, world", std::ios_base::openmode(0)); + std::cout << "'" << sbuf.str() << "'\n"; +</pre> + +<p>Paragraph 3 of 27.7.1.1 basically says that in this case neither +the output sequence nor the input sequence is initialized and +paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either +returns the input or the output sequence. None of them is initialized, +ie. both are empty, in which case the return from <tt>str()</tt> is +defined to be <tt>basic_string<cT>()</tt>.</p> + +<p>However, probably only test cases in some testsuites will detect this +"problem"...</p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove 27.7.1.1 paragraph 4.</p> + + +<p><b>Rationale:</b></p> +<p>We could fix 27.7.1.1 paragraph 4, but there would be no point. If +we fixed it, it would say just the same thing as text that's already +in the standard.</p> + + + + +<hr> +<h3><a name="239"></a>239. Complexity of unique() and/or unique_copy incorrect</h3> +<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The complexity of unique and unique_copy are inconsistent with each +other and inconsistent with the implementations. The standard +specifies:</p> + +<p>for unique():</p> + +<blockquote><p>-3- Complexity: If the range (last - first) is not empty, exactly +(last - first) - 1 applications of the corresponding predicate, otherwise +no applications of the predicate.</p></blockquote> + +<p>for unique_copy():</p> + +<blockquote><p>-7- Complexity: Exactly last - first applications of the corresponding +predicate.</p></blockquote> + +<p> +The implementations do it the other way round: unique() applies the +predicate last-first times and unique_copy() applies it last-first-1 +times.</p> + +<p>As both algorithms use the predicate for pair-wise comparison of +sequence elements I don't see a justification for unique_copy() +applying the predicate last-first times, especially since it is not +specified to which pair in the sequence the predicate is applied +twice.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change both complexity sections in 25.2.9 [alg.unique] to:</p> + +<blockquote><p>Complexity: For nonempty ranges, exactly last - first - 1 +applications of the corresponding predicate.</p></blockquote> + + + + + + +<hr> +<h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3> +<p><b>Section:</b> 25.1.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The complexity section of adjacent_find is defective:</p> + +<blockquote> +<pre>template <class ForwardIterator> +ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last + BinaryPredicate pred); +</pre> + +<p>-1- Returns: The first iterator i such that both i and i + 1 are in +the range [first, last) for which the following corresponding +conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns +last if no such iterator is found.</p> + +<p>-2- Complexity: Exactly find(first, last, value) - first applications +of the corresponding predicate. +</p> +</blockquote> + +<p>In the Complexity section, it is not defined what "value" +is supposed to mean. My best guess is that "value" means an +object for which one of the conditions pred(*i,value) or +pred(value,*i) is true, where i is the iterator defined in the Returns +section. However, the value type of the input sequence need not be +equality-comparable and for this reason the term find(first, last, +value) - first is meaningless.</p> + +<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or +find_if(first, last, bind1st(pred,*i)) - first might come closer to +the intended specification. Binders can only be applied to function +objects that have the function call operator declared const, which is +not required of predicates because they can have non-const data +members. For this reason, a specification using a binder could only be +an "as-if" specification.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the complexity section in 25.1.8 [alg.adjacent.find] to:</p> +<blockquote><p> +For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1, +(<i>last</i> - <i>first</i>) - 1)</tt> applications of the +corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s +return value. +</p></blockquote> + +<p><i>[Copenhagen: the original resolution specified an upper +bound. The LWG preferred an exact count.]</i></p> + + + + + + + +<hr> +<h3><a name="241"></a>241. Does unique_copy() require CopyConstructible and Assignable?</h3> +<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>Some popular implementations of unique_copy() create temporary +copies of values in the input sequence, at least if the input iterator +is a pointer. Such an implementation is built on the assumption that +the value type is CopyConstructible and Assignable.</p> + +<p>It is common practice in the standard that algorithms explicitly +specify any additional requirements that they impose on any of the +types used by the algorithm. An example of an algorithm that creates +temporary copies and correctly specifies the additional requirements +is accumulate(), 26.4.1 [rand.req].</p> + +<p>Since the specifications of unique() and unique_copy() do not +require CopyConstructible and Assignable of the InputIterator's value +type the above mentioned implementations are not standard-compliant. I +cannot judge whether this is a defect in the standard or a defect in +the implementations.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 25.2.8 change:</p> + +<blockquote><p> +-4- Requires: The ranges [first, last) and [result, result+(last-first)) +shall not overlap. +</p></blockquote> + +<p>to:</p> + +<blockquote> + <p>-4- Requires: The ranges [first, last) and [result, + result+(last-first)) shall not overlap. The expression *result = + *first must be valid. If neither InputIterator nor OutputIterator + meets the requirements of forward iterator then the value type of + InputIterator must be copy constructible. Otherwise copy + constructible is not required. </p> +</blockquote> + +<p><i>[Redmond: the original proposed resolution didn't impose an +explicit requirement that the iterator's value type must be copy +constructible, on the grounds that an input iterator's value type must +always be copy constructible. Not everyone in the LWG thought that +this requirement was clear from table 72. It has been suggested that +it might be possible to implement <tt>unique_copy</tt> without +requiring assignability, although current implementations do impose +that requirement. Howard provided new wording.]</i></p> + + +<p><i>[ +Curaçao: The LWG changed the PR editorially to specify +"neither...nor...meet..." as clearer than +"both...and...do not meet...". Change believed to be so +minor as not to require re-review. +]</i></p> + + + + + + + + +<hr> +<h3><a name="242"></a>242. Side effects of function objects</h3> +<p><b>Section:</b> 25.2.4 [alg.transform], 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The algorithms transform(), accumulate(), inner_product(), +partial_sum(), and adjacent_difference() require that the function +object supplied to them shall not have any side effects.</p> + +<p>The standard defines a side effect in 1.9 [intro.execution] as:</p> +<blockquote><p>-7- Accessing an object designated by a volatile lvalue (basic.lval), +modifying an object, calling a library I/O function, or calling a function +that does any of those operations are all side effects, which are changes +in the state of the execution environment.</p></blockquote> + +<p>As a consequence, the function call operator of a function object supplied +to any of the algorithms listed above cannot modify data members, cannot +invoke any function that has a side effect, and cannot even create and +modify temporary objects. It is difficult to imagine a function object +that is still useful under these severe limitations. For instance, any +non-trivial transformator supplied to transform() might involve creation +and modification of temporaries, which is prohibited according to the current +wording of the standard.</p> + +<p>On the other hand, popular implementations of these algorithms exhibit +uniform and predictable behavior when invoked with a side-effect-producing +function objects. It looks like the strong requirement is not needed for +efficient implementation of these algorithms.</p> + +<p>The requirement of side-effect-free function objects could be +replaced by a more relaxed basic requirement (which would hold for all +function objects supplied to any algorithm in the standard library):</p> +<blockquote><p>A function objects supplied to an algorithm shall not invalidate +any iterator or sequence that is used by the algorithm. Invalidation of +the sequence includes destruction of the sorting order if the algorithm +relies on the sorting order (see section 25.3 - Sorting and related operations +[lib.alg.sorting]).</p></blockquote> + +<p>I can't judge whether it is intended that the function objects supplied +to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference() +shall not modify sequence elements through dereferenced iterators.</p> + +<p>It is debatable whether this issue is a defect or a change request. +Since the consequences for user-supplied function objects are drastic and +limit the usefulness of the algorithms significantly I would consider it +a defect.</p> + + +<p><b>Proposed resolution:</b></p> + +<p><i>Things to notice about these changes:</i></p> + +<ol> +<li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges + are intentional. we want to prevent side-effects from + invalidating the end iterators.</i></li> + +<li> <i>That has the unintentional side-effect of prohibiting + modification of the end element as a side-effect. This could + conceivably be significant in some cases.</i></li> + +<li> <i>The wording also prevents side-effects from modifying elements + of the output sequence. I can't imagine why anyone would want + to do this, but it is arguably a restriction that implementors + don't need to place on users.</i></li> + +<li> <i>Lifting the restrictions imposed in #2 and #3 above is possible + and simple, but would require more verbiage.</i></li> +</ol> + +<p>Change 25.2.3/2 from:</p> + +<blockquote><p> + -2- Requires: op and binary_op shall not have any side effects. +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -2- Requires: in the ranges [first1, last1], [first2, first2 + + (last1 - first1)] and [result, result + (last1- first1)], op and + binary_op shall neither modify elements nor invalidate iterators or + subranges. + [Footnote: The use of fully closed ranges is intentional --end footnote] +</p></blockquote> + + +<p>Change 25.2.3/2 from:</p> + +<blockquote><p> + -2- Requires: op and binary_op shall not have any side effects. +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -2- Requires: op and binary_op shall not invalidate iterators or + subranges, or modify elements in the ranges [first1, last1], + [first2, first2 + (last1 - first1)], and [result, result + (last1 + - first1)]. + [Footnote: The use of fully closed ranges is intentional --end footnote] +</p></blockquote> + + +<p>Change 26.4.1/2 from:</p> + +<blockquote><p> + -2- Requires: T must meet the requirements of CopyConstructible + (lib.copyconstructible) and Assignable (lib.container.requirements) + types. binary_op shall not cause side effects. +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -2- Requires: T must meet the requirements of CopyConstructible + (lib.copyconstructible) and Assignable + (lib.container.requirements) types. In the range [first, last], + binary_op shall neither modify elements nor invalidate iterators + or subranges. + [Footnote: The use of a fully closed range is intentional --end footnote] +</p></blockquote> + +<p>Change 26.4.2/2 from:</p> + +<blockquote><p> + -2- Requires: T must meet the requirements of CopyConstructible + (lib.copyconstructible) and Assignable (lib.container.requirements) + types. binary_op1 and binary_op2 shall not cause side effects. +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -2- Requires: T must meet the requirements of CopyConstructible + (lib.copyconstructible) and Assignable (lib.container.requirements) + types. In the ranges [first, last] and [first2, first2 + (last - + first)], binary_op1 and binary_op2 shall neither modify elements + nor invalidate iterators or subranges. + [Footnote: The use of fully closed ranges is intentional --end footnote] +</p></blockquote> + + +<p>Change 26.4.3/4 from:</p> + +<blockquote><p> + -4- Requires: binary_op is expected not to have any side effects. +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -4- Requires: In the ranges [first, last] and [result, result + + (last - first)], binary_op shall neither modify elements nor + invalidate iterators or subranges. + [Footnote: The use of fully closed ranges is intentional --end footnote] +</p></blockquote> + +<p>Change 26.4.4/2 from:</p> + +<blockquote><p> + -2- Requires: binary_op shall not have any side effects. +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -2- Requires: In the ranges [first, last] and [result, result + + (last - first)], binary_op shall neither modify elements nor + invalidate iterators or subranges. + [Footnote: The use of fully closed ranges is intentional --end footnote] +</p></blockquote> + +<p><i>[Toronto: Dave Abrahams supplied wording.]</i></p> + + +<p><i>[Copenhagen: Proposed resolution was modified slightly. Matt +added footnotes pointing out that the use of closed ranges was +intentional.]</i></p> + + + + + + + +<hr> +<h3><a name="243"></a>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-05-15</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>basic_istream<>::get(), and basic_istream<>::getline(), +are unclear with respect to the behavior and side-effects of the named +functions in case of an error.</p> + +<p>27.6.1.3, p1 states that "... If the sentry object returns +true, when converted to a value of type bool, the function endeavors +to obtain the requested input..." It is not clear from this (or +the rest of the paragraph) what precisely the behavior should be when +the sentry ctor exits by throwing an exception or when the sentry +object returns false. In particular, what is the number of characters +extracted that gcount() returns supposed to be?</p> + +<p>27.6.1.3 p8 and p19 say about the effects of get() and getline(): +"... In any case, it then stores a null character (using +charT()) into the next successive location of the array." Is not +clear whether this sentence applies if either of the conditions above +holds (i.e., when sentry fails).</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add to 27.6.1.3, p1 after the sentence</p> + +<blockquote><p> +"... If the sentry object returns true, when converted to a value of +type bool, the function endeavors to obtain the requested input." +</p></blockquote> + +<p>the following</p> + + +<blockquote><p> +"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." +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p>Although the general philosophy of the input functions is that the +argument should not be modified upon failure, <tt>getline</tt> +historically added a terminating null unconditionally. Most +implementations still do that. Earlier versions of the draft standard +had language that made this an unambiguous requirement; those words +were moved to a place where their context made them less clear. See +Jerry Schwarz's message c++std-lib-7618.</p> + + + + +<hr> +<h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3> +<p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-06-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Paragraph 2 of 23.2.6.4 [vector.modifiers] describes the complexity +of <tt>vector::insert</tt>:</p> + + <blockquote><p> + Complexity: If first and last are forward iterators, bidirectional + iterators, or random access iterators, the complexity is linear in + the number of elements in the range [first, last) plus the distance + to the end of the vector. If they are input iterators, the complexity + is proportional to the number of elements in the range [first, last) + times the distance to the end of the vector. + </p></blockquote> + +<p>First, this fails to address the non-iterator forms of +<tt>insert</tt>.</p> + +<p>Second, the complexity for input iterators misses an edge case -- +it requires that an arbitrary number of elements can be added at +the end of a <tt>vector</tt> in constant time.</p> + +<p>I looked to see if <tt>deque</tt> had a similar problem, and was +surprised to find that <tt>deque</tt> places no requirement on the +complexity of inserting multiple elements (23.2.2.3 [deque.modifiers], +paragraph 3):</p> + + <blockquote><p> + Complexity: In the worst case, inserting a single element into a + deque takes time linear in the minimum of the distance from the + insertion point to the beginning of the deque and the distance + from the insertion point to the end of the deque. Inserting a + single element either at the beginning or end of a deque always + takes constant time and causes a single call to the copy constructor + of T. + </p></blockquote> + + +<p><b>Proposed resolution:</b></p> + +<p>Change Paragraph 2 of 23.2.6.4 [vector.modifiers] to</p> + <blockquote><p> + Complexity: The complexity is linear in the number of elements + inserted plus the distance to the end of the vector. + </p></blockquote> + + <p><i>[For input iterators, one may achieve this complexity by first + inserting at the end of the <tt>vector</tt>, and then using + <tt>rotate</tt>.]</i></p> + + +<p>Change 23.2.2.3 [deque.modifiers], paragraph 3, to:</p> + + <blockquote><p> + Complexity: The complexity is linear in the number of elements + inserted plus the shorter of the distances to the beginning and + end of the deque. Inserting a single element at either the + beginning or the end of a deque causes a single call to the copy + constructor of T. + </p></blockquote> + + + +<p><b>Rationale:</b></p> +<p>This is a real defect, and proposed resolution fixes it: some + complexities aren't specified that should be. This proposed + resolution does constrain deque implementations (it rules out the + most naive possible implementations), but the LWG doesn't see a + reason to permit that implementation.</p> + + + + + +<hr> +<h3><a name="248"></a>248. time_get fails to set eofbit</h3> +<p><b>Section:</b> 22.2.5 [category.time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-06-22</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>There is no requirement that any of time_get member functions set +ios::eofbit when they reach the end iterator while parsing their input. +Since members of both the num_get and money_get facets are required to +do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members +should follow the same requirement for consistency.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add paragraph 2 to section 22.2.5.1 with the following text:</p> + +<blockquote><p> +If the end iterator is reached during parsing by any of the get() +member functions, the member sets ios_base::eofbit in err. +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p>Two alternative resolutions were proposed. The LWG chose this one +because it was more consistent with the way eof is described for other +input facets.</p> + + + + +<hr> +<h3><a name="250"></a>250. splicing invalidates iterators</h3> +<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Brian Parker <b>Date:</b> 2000-07-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 23.2.4.4 [list.ops] states that +</p> +<pre> void splice(iterator position, list<T, Allocator>& x); +</pre> +<p> +<i>invalidates</i> all iterators and references to list <tt>x</tt>. +</p> + +<p> +This is unnecessary and defeats an important feature of splice. In +fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid +after <tt>splice</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p>Add a footnote to 23.2.4.4 [list.ops], paragraph 1:</p> +<blockquote><p> +[<i>Footnote:</i> As specified in [default.con.req], paragraphs +4-5, the semantics described in this clause applies only to the case +where allocators compare equal. --end footnote] +</p></blockquote> + +<p>In 23.2.4.4 [list.ops], replace paragraph 4 with:</p> +<blockquote><p> +Effects: Inserts the contents of x before position and x becomes +empty. Pointers and references to the moved elements of x now refer to +those same elements but as members of *this. Iterators referring to the +moved elements will continue to refer to their elements, but they now +behave as iterators into *this, not into x. +</p></blockquote> + +<p>In 23.2.4.4 [list.ops], replace paragraph 7 with:</p> +<blockquote><p> +Effects: Inserts an element pointed to by i from list x before +position and removes the element from x. The result is unchanged if +position == i or position == ++i. Pointers and references to *i continue +to refer to this same element but as a member of *this. Iterators to *i +(including i itself) continue to refer to the same element, but now +behave as iterators into *this, not into x. +</p></blockquote> + +<p>In 23.2.4.4 [list.ops], replace paragraph 12 with:</p> +<blockquote><p> +Requires: [first, last) is a valid range in x. The result is +undefined if position is an iterator in the range [first, last). +Pointers and references to the moved elements of x now refer to those +same elements but as members of *this. Iterators referring to the moved +elements will continue to refer to their elements, but they now behave as +iterators into *this, not into x. +</p></blockquote> + +<p><i>[pre-Copenhagen: Howard provided wording.]</i></p> + + + +<p><b>Rationale:</b></p> +<p>The original proposed resolution said that iterators and references +would remain "valid". The new proposed resolution clarifies what that +means. Note that this only applies to the case of equal allocators. +From [default.con.req] paragraph 4, the behavior of list when +allocators compare nonequal is outside the scope of the standard.</p> + + + + +<hr> +<h3><a name="251"></a>251. basic_stringbuf missing allocator_type</h3> +<p><b>Section:</b> 27.7.1 [stringbuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-07-28</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The synopsis for the template class <tt>basic_stringbuf</tt> +doesn't list a typedef for the template parameter +<tt>Allocator</tt>. This makes it impossible to determine the type of +the allocator at compile time. It's also inconsistent with all other +template classes in the library that do provide a typedef for the +<tt>Allocator</tt> parameter.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add to the synopses of the class templates basic_stringbuf (27.7.1), +basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and +basic_stringstream (27.7.4) the typedef:</p> +<pre> typedef Allocator allocator_type; +</pre> + + + + +<hr> +<h3><a name="252"></a>252. missing casts/C-style casts used in iostreams</h3> +<p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-07-28</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate +const_cast<> in the Returns clause for basic_istringstream<>::rdbuf(). +The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and +D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing +the cast altogether.</p> + +<p>C-style casts have not been deprecated, so the first part of this +issue is stylistic rather than a matter of correctness.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.7.2.2, p1 replace </p> +<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre> + +<p>with</p> +<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre> + + +<p>In 27.7.3.2, p1 replace</p> +<pre> -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.</pre> + +<p>with</p> +<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre> + +<p>In 27.7.6, p1, replace</p> +<pre> -1- Returns: &sb</pre> + +<p>with</p> +<pre> -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).</pre> + +<p>In D.7.2.2, p1 replace</p> +<pre> -2- Returns: &sb. </pre> + +<p>with</p> +<pre> -2- Returns: const_cast<strstreambuf*>(&sb).</pre> + + + + +<hr> +<h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3> +<p><b>Section:</b> 26.5.2.1 [valarray.cons], 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Robert Klarer <b>Date:</b> 2000-07-31</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>This discussion is adapted from message c++std-lib-7056 posted +November 11, 1999. I don't think that anyone can reasonably claim +that the problem described below is NAD.</p> + +<p>These valarray constructors can never be called:</p> + +<pre> template <class T> + valarray<T>::valarray(const slice_array<T> &); + template <class T> + valarray<T>::valarray(const gslice_array<T> &); + template <class T> + valarray<T>::valarray(const mask_array<T> &); + template <class T> + valarray<T>::valarray(const indirect_array<T> &); +</pre> + +<p>Similarly, these valarray assignment operators cannot be +called:</p> + +<pre> template <class T> + valarray<T> valarray<T>::operator=(const slice_array<T> &); + template <class T> + valarray<T> valarray<T>::operator=(const gslice_array<T> &); + template <class T> + valarray<T> valarray<T>::operator=(const mask_array<T> &); + template <class T> + valarray<T> valarray<T>::operator=(const indirect_array<T> &); +</pre> + +<p>Please consider the following example:</p> + +<pre> #include <valarray> + using namespace std; + + int main() + { + valarray<double> va1(12); + valarray<double> va2(va1[slice(1,4,3)]); // line 1 + } +</pre> + + +<p>Since the valarray va1 is non-const, the result of the sub-expression +va1[slice(1,4,3)] at line 1 is an rvalue of type const +std::slice_array<double>. This slice_array rvalue is then used to +construct va2. The constructor that is used to construct va2 is +declared like this:</p> + +<pre> template <class T> + valarray<T>::valarray(const slice_array<T> &); +</pre> + +<p>Notice the constructor's const reference parameter. When the +constructor is called, a slice_array must be bound to this reference. +The rules for binding an rvalue to a const reference are in 8.5.3, +paragraph 5 (see also 13.3.3.1.4). Specifically, paragraph 5 +indicates that a second slice_array rvalue is constructed (in this +case copy-constructed) from the first one; it is this second rvalue +that is bound to the reference parameter. Paragraph 5 also requires +that the constructor that is used for this purpose be callable, +regardless of whether the second rvalue is elided. The +copy-constructor in this case is not callable, however, because it is +private. Therefore, the compiler should report an error.</p> + +<p>Since slice_arrays are always rvalues, the valarray constructor that has a +parameter of type const slice_array<T> & can never be called. The +same reasoning applies to the three other constructors and the four +assignment operators that are listed at the beginning of this post. +Furthermore, since these functions cannot be called, the valarray helper +classes are almost entirely useless.</p> + + +<p><b>Proposed resolution:</b></p> +<p>slice_array:</p> +<ul> +<li> Make the copy constructor and copy-assignment operator declarations + public in the slice_array class template definition in 26.5.5 [template.slice.array] </li> +<li> remove paragraph 3 of 26.5.5 [template.slice.array]</li> +<li> remove the copy constructor declaration from [cons.slice.arr]</li> +<li> change paragraph 1 of [cons.slice.arr] to read "This constructor is declared + to be private. This constructor need not be defined."</li> +<li> remove the first sentence of paragraph 1 of 26.5.5.1 [slice.arr.assign]</li> +<li> Change the first three words of the second sentence of paragraph 1 of + 26.5.5.1 [slice.arr.assign] to "These assignment operators have"</li> +</ul> + +<p>gslice_array:</p> +<ul> +<li> Make the copy constructor and copy-assignment operator declarations + public in the gslice_array class template definition in 26.5.7 [template.gslice.array] </li> +<li> remove the note in paragraph 3 of 26.5.7 [template.gslice.array]</li> +<li> remove the copy constructor declaration from [gslice.array.cons]</li> +<li> change paragraph 1 of [gslice.array.cons] to read "This constructor is declared + to be private. This constructor need not be defined."</li> +<li> remove the first sentence of paragraph 1 of 26.5.7.1 [gslice.array.assign]</li> +<li> Change the first three words of the second sentence of paragraph 1 of + 26.5.7.1 [gslice.array.assign] to "These assignment operators have"</li> +</ul> + +<p>mask_array:</p> +<ul> +<li> Make the copy constructor and copy-assignment operator declarations + public in the mask_array class template definition in 26.5.8 [template.mask.array] </li> +<li> remove the note in paragraph 2 of 26.5.8 [template.mask.array]</li> +<li> remove the copy constructor declaration from [mask.array.cons]</li> +<li> change paragraph 1 of [mask.array.cons] to read "This constructor is declared + to be private. This constructor need not be defined."</li> +<li> remove the first sentence of paragraph 1 of 26.5.8.1 [mask.array.assign]</li> +<li> Change the first three words of the second sentence of paragraph 1 of + 26.5.8.1 [mask.array.assign] to "These assignment operators have"</li> +</ul> + +<p>indirect_array:</p> +<ul> +<li>Make the copy constructor and copy-assignment operator declarations + public in the indirect_array class definition in 26.5.9 [template.indirect.array]</li> +<li> remove the note in paragraph 2 of 26.5.9 [template.indirect.array]</li> +<li> remove the copy constructor declaration from [indirect.array.cons]</li> +<li> change the descriptive text in [indirect.array.cons] to read "This constructor is + declared to be private. This constructor need not be defined."</li> +<li> remove the first sentence of paragraph 1 of 26.5.9.1 [indirect.array.assign]</li> +<li> Change the first three words of the second sentence of paragraph 1 of + 26.5.9.1 [indirect.array.assign] to "These assignment operators have"</li> +</ul> +<p><i>[Proposed resolution was modified in Santa Cruz: explicitly make +copy constructor and copy assignment operators public, instead of +removing them.]</i></p> + + + +<p><b>Rationale:</b></p> +<p>Keeping the valarray constructors private is untenable. Merely +making valarray a friend of the helper classes isn't good enough, +because access to the copy constructor is checked in the user's +environment.</p> + +<p>Making the assignment operator public is not strictly necessary to +solve this problem. A majority of the LWG <i>(straw poll: 13-4)</i> +believed we should make the assignment operators public, in addition +to the copy constructors, for reasons of symmetry and user +expectation.</p> + + + + + +<hr> +<h3><a name="254"></a>254. Exception types in clause 19 are constructed from <tt>std::string</tt></h3> +<p><b>Section:</b> 19.1 [std.exceptions], 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-08-01</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Many of the standard exception types which implementations are +required to throw are constructed with a const std::string& +parameter. For example: +</p> + +<pre> 19.1.5 Class out_of_range [lib.out.of.range] + namespace std { + class out_of_range : public logic_error { + public: + explicit out_of_range(const string& what_arg); + }; + } + + 1 The class out_of_range defines the type of objects thrown as excep- + tions to report an argument value not in its expected range. + + out_of_range(const string& what_arg); + + Effects: + Constructs an object of class out_of_range. + Postcondition: + strcmp(what(), what_arg.c_str()) == 0. +</pre> + +<p> +There are at least two problems with this: +</p> +<ol> +<li>A program which is low on memory may end up throwing +std::bad_alloc instead of out_of_range because memory runs out while +constructing the exception object.</li> +<li>An obvious implementation which stores a std::string data member +may end up invoking terminate() during exception unwinding because the +exception object allocates memory (or rather fails to) as it is being +copied.</li> +</ol> + +<p> +There may be no cure for (1) other than changing the interface to +out_of_range, though one could reasonably argue that (1) is not a +defect. Personally I don't care that much if out-of-memory is reported +when I only have 20 bytes left, in the case when out_of_range would +have been reported. People who use exception-specifications might care +a lot, though. +</p> + +<p> +There is a cure for (2), but it isn't completely obvious. I think a +note for implementors should be made in the standard. Avoiding +possible termination in this case shouldn't be left up to chance. The +cure is to use a reference-counted "string" implementation +in the exception object. I am not necessarily referring to a +std::string here; any simple reference-counting scheme for a NTBS +would do. +</p> + +<p><b>Further discussion, in email:</b></p> + +<p> +...I'm not so concerned about (1). After all, a library implementation +can add const char* constructors as an extension, and users don't +<i>need</i> to avail themselves of the standard exceptions, though this is +a lame position to be forced into. FWIW, std::exception and +std::bad_alloc don't require a temporary basic_string. +</p> + +<p> +...I don't think the fixed-size buffer is a solution to the problem, +strictly speaking, because you can't satisfy the postcondition +<br> + <tt> strcmp(what(), what_arg.c_str()) == 0</tt> +<br> +For all values of what_arg (i.e. very long values). That means that +the only truly conforming solution requires a dynamic allocation. +</p> + +<p><b>Further discussion, from Redmond:</b></p> + +<p>The most important progress we made at the Redmond meeting was +realizing that there are two separable issues here: the const +string& constructor, and the copy constructor. If a user writes +something like <tt>throw std::out_of_range("foo")</tt>, the const +string& constructor is invoked before anything gets thrown. The +copy constructor is potentially invoked during stack unwinding.</p> + +<p>The copy constructor is a more serious problem, becuase failure +during stack unwinding invokes <tt>terminate</tt>. The copy +constructor must be nothrow. <i>Curaçao: Howard thinks this +requirement may already be present.</i></p> + +<p>The fundamental problem is that it's difficult to get the nothrow +requirement to work well with the requirement that the exception +objects store a string of unbounded size, particularly if you also try +to make the const string& constructor nothrow. Options discussed +include:</p> + +<ul> +<li>Limit the size of a string that exception objects are required to +throw: change the postconditions of 19.1.2 [domain.error] paragraph 3 +and 19.1.6 [runtime.error] paragraph 3 to something like this: +"strncmp(what(), what_arg._str(), N) == 0, where N is an +implementation defined constant no smaller than 256".</li> +<li>Allow the const string& constructor to throw, but not the +copy constructor. It's the implementor's responsibility to get it +right. (An implementor might use a simple refcount class.)</li> +<li>Compromise between the two: an implementation is not allowed to +throw if the string's length is less than some N, but, if it doesn't +throw, the string must compare equal to the argument.</li> +<li>Add a new constructor that takes a const char*</li> +</ul> + +<p>(Not all of these options are mutually exclusive.)</p> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Change 19.1.1 [logic.error] +</p> + +<blockquote> +<pre>namespace std { + class logic_error : public exception { + public: + explicit logic_error(const string& <i>what_arg</i>); + <ins>explicit logic_error(const char* <i>what_arg</i>);</ins> + }; +} +</pre> +<p>...</p> +<p> +<ins><tt>logic_error(const char* <i>what_arg</i>);</tt></ins> +</p> +<blockquote> +<p><ins> +-4- <i>Effects:</i> Constructs an object of class <tt>logic_error</tt>. +</ins></p> +<p><ins> +-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 19.1.2 [domain.error] +</p> + +<blockquote> +<pre>namespace std { + class domain_error : public logic_error { + public: + explicit domain_error(const string& <i>what_arg</i>); + <ins>explicit domain_error(const char* <i>what_arg</i>);</ins> + }; +} +</pre> +<p>...</p> +<p> +<ins><tt>domain_error(const char* <i>what_arg</i>);</tt></ins> +</p> +<blockquote> +<p><ins> +-4- <i>Effects:</i> Constructs an object of class <tt>domain_error</tt>. +</ins></p> +<p><ins> +-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>. +</ins></p> + +</blockquote> +</blockquote> + +<p> +Change 19.1.3 [invalid.argument] +</p> + +<blockquote> +<pre>namespace std { + class invalid_argument : public logic_error { + public: + explicit invalid_argument(const string& <i>what_arg</i>); + <ins>explicit invalid_argument(const char* <i>what_arg</i>);</ins> + }; +} +</pre> +<p>...</p> +<p> +<ins><tt>invalid_argument(const char* <i>what_arg</i>);</tt></ins> +</p> +<blockquote> +<p><ins> +-4- <i>Effects:</i> Constructs an object of class <tt>invalid_argument</tt>. +</ins></p> +<p><ins> +-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 19.1.4 [length.error] +</p> + +<blockquote> +<pre>namespace std { + class length_error : public logic_error { + public: + explicit length_error(const string& <i>what_arg</i>); + <ins>explicit length_error(const char* <i>what_arg</i>);</ins> + }; +} +</pre> +<p>...</p> +<p> +<ins><tt>length_error(const char* <i>what_arg</i>);</tt></ins> +</p> +<blockquote> +<p><ins> +-4- <i>Effects:</i> Constructs an object of class <tt>length_error</tt>. +</ins></p> +<p><ins> +-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 19.1.5 [out.of.range] +</p> + +<blockquote> +<pre>namespace std { + class out_of_range : public logic_error { + public: + explicit out_of_range(const string& <i>what_arg</i>); + <ins>explicit out_of_range(const char* <i>what_arg</i>);</ins> + }; +} +</pre> +<p>...</p> +<p> +<ins><tt>out_of_range(const char* <i>what_arg</i>);</tt></ins> +</p> +<blockquote> +<p><ins> +-4- <i>Effects:</i> Constructs an object of class <tt>out_of_range</tt>. +</ins></p> +<p><ins> +-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 19.1.6 [runtime.error] +</p> + +<blockquote> +<pre>namespace std { + class runtime_error : public exception { + public: + explicit runtime_error(const string& <i>what_arg</i>); + <ins>explicit runtime_error(const char* <i>what_arg</i>);</ins> + }; +} +</pre> +<p>...</p> +<p> +<ins><tt>runtime_error(const char* <i>what_arg</i>);</tt></ins> +</p> +<blockquote> +<p><ins> +-4- <i>Effects:</i> Constructs an object of class <tt>runtime_error</tt>. +</ins></p> +<p><ins> +-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 19.1.7 [range.error] +</p> + +<blockquote> +<pre>namespace std { + class range_error : public runtime_error { + public: + explicit range_error(const string& <i>what_arg</i>); + <ins>explicit range_error(const char* <i>what_arg</i>);</ins> + }; +} +</pre> +<p>...</p> +<p> +<ins><tt>range_error(const char* <i>what_arg</i>);</tt></ins> +</p> +<blockquote> +<p><ins> +-4- <i>Effects:</i> Constructs an object of class <tt>range_error</tt>. +</ins></p> +<p><ins> +-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 19.1.8 [overflow.error] +</p> + +<blockquote> +<pre>namespace std { + class overflow_error : public runtime_error { + public: + explicit overflow_error(const string& <i>what_arg</i>); + <ins>explicit overflow_error(const char* <i>what_arg</i>);</ins> + }; +} +</pre> +<p>...</p> +<p> +<ins><tt>overflow_error(const char* <i>what_arg</i>);</tt></ins> +</p> +<blockquote> +<p><ins> +-4- <i>Effects:</i> Constructs an object of class <tt>overflow_error</tt>. +</ins></p> +<p><ins> +-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 19.1.9 [underflow.error] +</p> + +<blockquote> +<pre>namespace std { + class underflow_error : public runtime_error { + public: + explicit underflow_error(const string& <i>what_arg</i>); + <ins>explicit underflow_error(const char* <i>what_arg</i>);</ins> + }; +} +</pre> +<p>...</p> +<p> +<ins><tt>underflow_error(const char* <i>what_arg</i>);</tt></ins> +</p> +<blockquote> +<p><ins> +-4- <i>Effects:</i> Constructs an object of class <tt>underflow_error</tt>. +</ins></p> +<p><ins> +-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 27.4.2.1.1 [ios::failure] +</p> + +<blockquote> +<pre>namespace std { + class ios_base::failure : public exception { + public: + explicit failure(const string& <i>msg</i>); + <ins>explicit failure(const char* <i>msg</i>);</ins> + virtual const char* what() const throw(); +}; +} +</pre> +<p>...</p> +<p> +<ins><tt>failure(const char* <i>msg</i>);</tt></ins> +</p> +<blockquote> +<p><ins> +-4- <i>Effects:</i> Constructs an object of class <tt>failure</tt>. +</ins></p> +<p><ins> +-5- <i>Postcondition:</i> <tt>strcmp(what(), <i>msg</i>) == 0</tt>. +</ins></p> +</blockquote> + +</blockquote> + + + +<p><b>Rationale:</b></p> + +<p>Throwing a bad_alloc while trying to construct a message for another +exception-derived class is not necessarily a bad thing. And the +bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p> + +<p><b>Future:</b></p> + +<p>All involved would like to see const char* constructors added, but +this should probably be done for C++0X as opposed to a DR.</p> + +<p>I believe the no throw specs currently decorating these functions +could be improved by some kind of static no throw spec checking +mechanism (in a future C++ language). As they stand, the copy +constructors might fail via a call to unexpected. I think what is +intended here is that the copy constructors can't fail.</p> + +<p><i>[Pre-Sydney: reopened at the request of Howard Hinnant. + Post-Redmond: James Kanze noticed that the copy constructors of + exception-derived classes do not have nothrow clauses. Those + classes have no copy constructors declared, meaning the + compiler-generated implicit copy constructors are used, and those + compiler-generated constructors might in principle throw anything.]</i></p> + + +<p><i>[ +Batavia: Merged copy constructor and assignment operator spec into <tt>exception</tt> +and added <tt>ios::failure</tt> into the proposed resolution. +]</i></p> + + +<p><i>[ +Oxford: The proposed resolution simply addresses the issue of constructing +the exception objects with <tt>const char*</tt> and string literals without +the need to explicit include or construct a <tt>std::string</tt>. +]</i></p> + + + + + + + +<hr> +<h3><a name="256"></a>256. typo in 27.4.4.2, p17: copy_event does not exist</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-21</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +27.4.4.2, p17 says +</p> + +<blockquote><p> +-17- Before copying any parts of rhs, calls each registered callback +pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but +exceptions() have been replaced, calls each callback pair that was +copied from rhs as (*fn)(copy_event,*this,index). +</p></blockquote> + +<p> +The name copy_event isn't defined anywhere. The intended name was +copyfmt_event. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace copy_event with copyfmt_event in the named paragraph.</p> + + + + +<hr> +<h3><a name="258"></a>258. Missing allocator 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#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-08-22</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +From lib-7752: +</p> + +<p> +I've been assuming (and probably everyone else has been assuming) that +allocator instances have a particular property, and I don't think that +property can be deduced from anything in Table 32. +</p> + +<p> +I think we have to assume that allocator type conversion is a +homomorphism. That is, if x1 and x2 are of type X, where +X::value_type is T, and if type Y is X::template +rebind<U>::other, then Y(x1) == Y(x2) if and only if x1 == x2. +</p> + +<p> +Further discussion: Howard Hinnant writes, in lib-7757: +</p> + +<p> +I think I can prove that this is not provable by Table 32. And I agree +it needs to be true except for the "and only if". If x1 != x2, I see no +reason why it can't be true that Y(x1) == Y(x2). Admittedly I can't +think of a practical instance where this would happen, or be valuable. +But I also don't see a need to add that extra restriction. I think we +only need: +</p> + +<blockquote><p> + if (x1 == x2) then Y(x1) == Y(x2) +</p></blockquote> + +<p> +If we decide that == on allocators is transitive, then I think I can +prove the above. But I don't think == is necessarily transitive on +allocators. That is: +</p> + +<p> +Given x1 == x2 and x2 == x3, this does not mean x1 == x3. +</p> + +<p>Example:</p> + +<blockquote> +<p> +x1 can deallocate pointers from: x1, x2, x3 <br> +x2 can deallocate pointers from: x1, x2, x4 <br> +x3 can deallocate pointers from: x1, x3 <br> +x4 can deallocate pointers from: x2, x4 +</p> + +<p> +x1 == x2, and x2 == x4, but x1 != x4 +</p> +</blockquote> +<p><i>[Toronto: LWG members offered multiple opinions. One +opinion is that it should not be required that <tt>x1 == x2</tt> +implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be +required that <tt>X(x1) == x1</tt>. Another opinion is that +the second line from the bottom in table 32 already implies the +desired property. This issue should be considered in light of +other issues related to allocator instances.]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Accept proposed wording from +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 3. +</p> + + +<p><i>[Lillehammer: Same conclusion as before: this should be + considered as part of an allocator redesign, not solved on its own.]</i></p> + + +<p><i>[ +Batavia: An allocator redesign is not forthcoming and thus we fixed this one issue. +]</i></p> + + +<p><i>[ +Toronto: Reopened at the request of the project editor (Pete) because the proposed +wording did not fit within the indicated table. The intent of the resolution remains +unchanged. Pablo to work with Pete on improved wording. +]</i></p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which +was subsequently split out into a separate paper N2436 for the purposes of voting. +The resolution in N2436 addresses this issue. The LWG voted to accelerate this +issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="259"></a>259. <tt>basic_string::operator[]</tt> and const correctness</h3> +<p><b>Section:</b> 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Chris Newton <b>Date:</b> 2000-08-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.capacity">issues</a> in [string.capacity].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i> +</p> + +<p> +The standard's description of <tt>basic_string<>::operator[]</tt> +seems to violate const correctness. +</p> + +<p> +The standard (21.3.4/1) says that "If <tt>pos < size()</tt>, +returns <tt>data()[pos]</tt>." The types don't work. The +return value of <tt>data()</tt> is <tt>const charT*</tt>, but +<tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In section 21.3.4, paragraph 1, change +"<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() + +<i>pos</i>)</tt>". +</p> + + + + +<hr> +<h3><a name="260"></a>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt></h3> +<p><b>Section:</b> 24.5.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows +it as returning the iterator by value. 24.5.1.2, p5 shows the same +operator as returning the iterator by reference. That's incorrect +given the Effects clause below (since a temporary is returned). The +`&' is probably just a typo.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the declaration in 24.5.1.2, p5 from</p> + <pre> istream_iterator<T,charT,traits,Distance>& operator++(int); + </pre> +<p>to</p> + <pre> istream_iterator<T,charT,traits,Distance> operator++(int); + </pre> +<p>(that is, remove the `&').</p> + + + + +<hr> +<h3><a name="261"></a>261. Missing description of <tt>istream_iterator::operator!=</tt></h3> +<p><b>Section:</b> 24.5.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +24.5.1, p3 lists the synopsis for +</p> + +<pre> template <class T, class charT, class traits, class Distance> + bool operator!=(const istream_iterator<T,charT,traits,Distance>& x, + const istream_iterator<T,charT,traits,Distance>& y); +</pre> + +<p> +but there is no description of what the operator does (i.e., no Effects +or Returns clause) in 24.5.1.2. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add paragraph 7 to the end of section 24.5.1.2 with the following text: +</p> + +<pre> template <class T, class charT, class traits, class Distance> + bool operator!=(const istream_iterator<T,charT,traits,Distance>& x, + const istream_iterator<T,charT,traits,Distance>& y); +</pre> + +<p>-7- Returns: !(x == y).</p> + + + + +<hr> +<h3><a name="262"></a>262. Bitmask operator ~ specified incorrectly</h3> +<p><b>Section:</b> 17.3.2.1.2 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2000-09-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The ~ operation should be applied after the cast to int_type. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 17.3.2.1.2 [lib.bitmask.types] operator~ from: +</p> + +<pre> bitmask operator~ ( bitmask X ) + { return static_cast< bitmask>(static_cast<int_type>(~ X)); } +</pre> + +<p> +to: +</p> + +<pre> bitmask operator~ ( bitmask X ) + { return static_cast< bitmask>(~static_cast<int_type>(X)); } +</pre> + + + + +<hr> +<h3><a name="263"></a>263. Severe restriction on <tt>basic_string</tt> reference counting</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#WP">WP</a> + <b>Submitter:</b> Kevlin Henney <b>Date:</b> 2000-09-04</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The note in paragraph 6 suggests that the invalidation rules for +references, pointers, and iterators in paragraph 5 permit a reference- +counted implementation (actually, according to paragraph 6, they permit +a "reference counted implementation", but this is a minor editorial fix). +</p> + +<p> +However, the last sub-bullet is so worded as to make a reference-counted +implementation unviable. In the following example none of the +conditions for iterator invalidation are satisfied: +</p> + +<pre> // first example: "*******************" should be printed twice + string original = "some arbitrary text", copy = original; + const string & alias = original; + + string::const_iterator i = alias.begin(), e = alias.end(); + for(string::iterator j = original.begin(); j != original.end(); ++j) + *j = '*'; + while(i != e) + cout << *i++; + cout << endl; + cout << original << endl; +</pre> + +<p> +Similarly, in the following example: +</p> + +<pre> // second example: "some arbitrary text" should be printed out + string original = "some arbitrary text", copy = original; + const string & alias = original; + + string::const_iterator i = alias.begin(); + original.begin(); + while(i != alias.end()) + cout << *i++; +</pre> + +<p> +I have tested this on three string implementations, two of which were +reference counted. The reference-counted implementations gave +"surprising behavior" because they invalidated iterators on +the first call to non-const begin since construction. The current +wording does not permit such invalidation because it does not take +into account the first call since construction, only the first call +since various member and non-member function calls. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the following sentence in 21.3 paragraph 5 from +</p> + +<blockquote><p> + Subsequent to any of the above uses except the forms of insert() and + erase() which return iterators, the first call to non-const member + functions operator[](), at(), begin(), rbegin(), end(), or rend(). +</p></blockquote> + +<p>to</p> + +<blockquote><p> + Following construction or any of the above uses, except the forms of + insert() and erase() that return iterators, the first call to non- + const member functions operator[](), at(), begin(), rbegin(), end(), + or rend(). +</p></blockquote> + + + + +<hr> +<h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> John Potter <b>Date:</b> 2000-09-07</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></p> +<p><b>Discussion:</b></p> +<p> +Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient. +Consider inserting a sorted range of even integers into a set<int> containing the odd +integers in the same range. +</p> + +<p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p> + + +<p><b>Proposed resolution:</b></p> +<p> +In Table 69, in section 23.1.2, change the complexity clause for +insertion of a range from "N log(size() + N) (N is the distance +from i to j) in general; linear if [i, j) is sorted according to +value_comp()" to "N log(size() + N), where N is the distance +from i to j". +</p> + +<p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced +parens in the revised wording.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p> +Testing for valid insertions could be less efficient than simply +inserting the elements when the range is not both sorted and between +two adjacent existing elements; this could be a QOI issue. +</p> + +<p> +The LWG considered two other options: (a) specifying that the +complexity was linear if [i, j) is sorted according to value_comp() +and between two adjacent existing elements; or (b) changing to +Klog(size() + N) + (N - K) (N is the distance from i to j and K is the +number of elements which do not insert immediately after the previous +element from [i, j) including the first). The LWG felt that, since +we can't guarantee linear time complexity whenever the range to be +inserted is sorted, it's more trouble than it's worth to say that it's +linear in some special cases. +</p> + + + + +<hr> +<h3><a name="265"></a>265. std::pair::pair() effects overly restrictive</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-09-11</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I don't see any requirements on the types of the elements of the +std::pair container in 20.2.2. From the descriptions of the member +functions it appears that they must at least satisfy the requirements of +20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in +the case of the [in]equality operators also the requirements of 20.1.1 +[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable]. +</p> + +<p> +I believe that the the CopyConstructible requirement is unnecessary in +the case of 20.2.2, p2. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the Effects clause in 20.2.2, p2 from</p> + +<blockquote><p> +-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() : +first(T1()), second(T2()) {} </tt> +</p></blockquote> + +<p>to</p> + +<blockquote><p> +-2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() : +first(), second() {} </tt> +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p>The existing specification of pair's constructor appears to be a +historical artifact: there was concern that pair's members be properly +zero-initialized when they are built-in types. At one time there was +uncertainty about whether they would be zero-initialized if the +default constructor was written the obvious way. This has been +clarified by core issue 178, and there is no longer any doubt that +the straightforward implementation is correct.</p> + + + + +<hr> +<h3><a name="266"></a>266. bad_exception::~bad_exception() missing Effects clause</h3> +<p><b>Section:</b> 18.7.2.1 [bad.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-09-24</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The synopsis for std::bad_exception lists the function ~bad_exception() +but there is no description of what the function does (the Effects +clause is missing). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Remove the destructor from the class synopses of +<tt>bad_alloc</tt> (18.5.2.1 [bad.alloc]), +<tt>bad_cast</tt> (18.6.2 [bad.cast]), +<tt>bad_typeid</tt> (18.6.3 [bad.typeid]), +and <tt>bad_exception</tt> (18.7.2.1 [bad.exception]). +</p> + + +<p><b>Rationale:</b></p> +<p> +This is a general problem with the exception classes in clause 18. +The proposed resolution is to remove the destructors from the class +synopses, rather than to document the destructors' behavior, because +removing them is more consistent with how exception classes are +described in clause 19. +</p> + + + + +<hr> +<h3><a name="268"></a>268. Typo in locale synopsis</h3> +<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-10-05</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The synopsis of the class std::locale in 22.1.1 contains two typos: +the semicolons after the declarations of the default ctor +locale::locale() and the copy ctor locale::locale(const locale&) +are missing.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add the missing semicolons, i.e., change</p> + +<pre> // construct/copy/destroy: + locale() throw() + locale(const locale& other) throw() +</pre> + +<p>in the synopsis in 22.1.1 to</p> + +<pre> // construct/copy/destroy: + locale() throw(); + locale(const locale& other) throw(); +</pre> + + + + +<hr> +<h3><a name="270"></a>270. Binary search requirements overly strict</h3> +<p><b>Section:</b> 25.3.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-10-18</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#472">472</a></p> +<p><b>Discussion:</b></p> +<p> +Each of the four binary search algorithms (lower_bound, upper_bound, +equal_range, binary_search) has a form that allows the user to pass a +comparison function object. According to 25.3, paragraph 2, that +comparison function object has to be a strict weak ordering. +</p> + +<p> +This requirement is slightly too strict. Suppose we are searching +through a sequence containing objects of type X, where X is some +large record with an integer key. We might reasonably want to look +up a record by key, in which case we would want to write something +like this: +</p> +<pre> struct key_comp { + bool operator()(const X& x, int n) const { + return x.key() < n; + } + } + + std::lower_bound(first, last, 47, key_comp()); +</pre> + +<p> +key_comp is not a strict weak ordering, but there is no reason to +prohibit its use in lower_bound. +</p> + +<p> +There's no difficulty in implementing lower_bound so that it allows +the use of something like key_comp. (It will probably work unless an +implementor takes special pains to forbid it.) What's difficult is +formulating language in the standard to specify what kind of +comparison function is acceptable. We need a notion that's slightly +more general than that of a strict weak ordering, one that can encompass +a comparison function that involves different types. Expressing that +notion may be complicated. +</p> + +<p><i>Additional questions raised at the Toronto meeting:</i></p> +<ul> +<li> Do we really want to specify what ordering the implementor must + use when calling the function object? The standard gives + specific expressions when describing these algorithms, but it also + says that other expressions (with different argument order) are + equivalent.</li> +<li> If we are specifying ordering, note that the standard uses both + orderings when describing <tt>equal_range</tt>.</li> +<li> Are we talking about requiring these algorithms to work properly + when passed a binary function object whose two argument types + are not the same, or are we talking about requirements when + they are passed a binary function object with several overloaded + versions of <tt>operator()</tt>?</li> +<li> The definition of a strict weak ordering does not appear to give + any guidance on issues of overloading; it only discusses expressions, + and all of the values in these expressions are of the same type. + Some clarification would seem to be in order.</li> +</ul> + +<p><i>Additional discussion from Copenhagen:</i></p> +<ul> +<li>It was generally agreed that there is a real defect here: if +the predicate is merely required to be a Strict Weak Ordering, then +it's possible to pass in a function object with an overloaded +operator(), where the version that's actually called does something +completely inappropriate. (Such as returning a random value.)</li> + +<li>An alternative formulation was presented in a paper distributed by +David Abrahams at the meeting, "Binary Search with Heterogeneous +Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the +predicate as a Strict Weak Ordering acting on a sorted sequence, view +the predicate/value pair as something that partitions a sequence. +This is almost equivalent to saying that we should view binary search +as if we are given a unary predicate and a sequence, such that f(*p) +is true for all p below a specific point and false for all p above it. +The proposed resolution is based on that alternative formulation.</li> +</ul> + + +<p><b>Proposed resolution:</b></p> + +<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p> + +<blockquote><p> + 3 For all algorithms that take Compare, there is a version that uses + operator< instead. That is, comp(*i, *j) != false defaults to *i < + *j != false. For the algorithms to work correctly, comp has to + induce a strict weak ordering on the values. +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + 3 For all algorithms that take Compare, there is a version that uses + operator< instead. That is, comp(*i, *j) != false defaults to *i + < *j != false. For algorithms other than those described in + lib.alg.binary.search (25.3.3) to work correctly, comp has to induce + a strict weak ordering on the values. +</p></blockquote> + +<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p> + +<blockquote><p> + -6- A sequence [start, finish) is partitioned with respect to an + expression f(e) if there exists an integer n such that + for all 0 <= i < distance(start, finish), f(*(begin+i)) is true if + and only if i < n. +</p></blockquote> + +<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p> + +<blockquote><p> + -1- All of the algorithms in this section are versions of binary + search and assume that the sequence being searched is in order + according to the implied or explicit comparison function. They work + on non-random access iterators minimizing the number of + comparisons, which will be logarithmic for all types of + iterators. They are especially appropriate for random access + iterators, because these algorithms do a logarithmic number of + steps through the data structure. For non-random access iterators + they execute a linear number of steps. +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -1- All of the algorithms in this section are versions of binary + search and assume that the sequence being searched is partitioned + with respect to an expression formed by binding the search key to + an argument of the implied or explicit comparison function. They + work on non-random access iterators minimizing the number of + comparisons, which will be logarithmic for all types of + iterators. They are especially appropriate for random access + iterators, because these algorithms do a logarithmic number of + steps through the data structure. For non-random access iterators + they execute a linear number of steps. +</p></blockquote> + +<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p> + +<blockquote><p> + -1- Requires: Type T is LessThanComparable + (lib.lessthancomparable). +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -1- Requires: The elements e of [first, last) are partitioned with + respect to the expression e < value or comp(e, value) +</p></blockquote> + + +<p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p> + +<blockquote><p> + -2- Effects: Finds the first position into which value can be + inserted without violating the ordering. +</p></blockquote> + +<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p> + +<blockquote><p> + -1- Requires: Type T is LessThanComparable (lib.lessthancomparable). +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -1- Requires: The elements e of [first, last) are partitioned with + respect to the expression !(value < e) or !comp(value, e) +</p></blockquote> + +<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p> + +<blockquote><p> + -2- Effects: Finds the furthermost position into which value can be + inserted without violating the ordering. +</p></blockquote> + +<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p> + +<blockquote><p> + -1- Requires: Type T is LessThanComparable + (lib.lessthancomparable). +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -1- Requires: The elements e of [first, last) are partitioned with + respect to the expressions e < value and !(value < e) or + comp(e, value) and !comp(value, e). Also, for all elements e of + [first, last), e < value implies !(value < e) or comp(e, + value) implies !comp(value, e) +</p></blockquote> + +<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p> + +<blockquote><p> + -2- Effects: Finds the largest subrange [i, j) such that the value + can be inserted at any iterator k in it without violating the + ordering. k satisfies the corresponding conditions: !(*k < value) + && !(value < *k) or comp(*k, value) == false && comp(value, *k) == + false. +</p></blockquote> + +<p>to:</p> + +<pre> -2- Returns: + make_pair(lower_bound(first, last, value), + upper_bound(first, last, value)) + or + make_pair(lower_bound(first, last, value, comp), + upper_bound(first, last, value, comp)) +</pre> + +<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p> + +<blockquote><p> + -1- Requires: Type T is LessThanComparable + (lib.lessthancomparable). +</p></blockquote> + +<p>to:</p> + +<blockquote><p> + -1- Requires: The elements e of [first, last) are partitioned with + respect to the expressions e < value and !(value < e) or comp(e, + value) and !comp(value, e). Also, for all elements e of [first, + last), e < value implies !(value < e) or comp(e, value) implies + !comp(value, e) +</p></blockquote> + +<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p> + + +<p><i>[Redmond: Minor changes in wording. (Removed "non-negative", and +changed the "other than those described in" wording.) Also, the LWG +decided to accept the "optional" part.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The proposed resolution reinterprets binary search. Instead of +thinking about searching for a value in a sorted range, we view that +as an important special case of a more general algorithm: searching +for the partition point in a partitioned range.</p> + +<p>We also add a guarantee that the old wording did not: we ensure +that the upper bound is no earlier than the lower bound, that +the pair returned by equal_range is a valid range, and that the first +part of that pair is the lower bound.</p> + + + + + +<hr> +<h3><a name="271"></a>271. basic_iostream missing typedefs</h3> +<p><b>Section:</b> 27.6.1.5 [iostreamclass] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Class template basic_iostream has no typedefs. The typedefs it +inherits from its base classes can't be used, since (for example) +basic_iostream<T>::traits_type is ambiguous. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p>Add the following to basic_iostream's class synopsis in +27.6.1.5 [iostreamclass], immediately after <tt>public</tt>:</p> + +<pre> // types: + typedef charT char_type; + typedef typename traits::int_type int_type; + typedef typename traits::pos_type pos_type; + typedef typename traits::off_type off_type; + typedef traits traits_type; +</pre> + + + + +<hr> +<h3><a name="272"></a>272. Missing parentheses around subexpression</h3> +<p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a></p> +<p><b>Discussion:</b></p> +<p> +27.4.4.3, p4 says about the postcondition of the function: If +rdbuf()!=0 then state == rdstate(); otherwise +rdstate()==state|ios_base::badbit. +</p> + +<p> +The expression on the right-hand-side of the operator==() needs to be +parenthesized in order for the whole expression to ever evaluate to +anything but non-zero. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add parentheses like so: rdstate()==(state|ios_base::badbit). +</p> + + + + +<hr> +<h3><a name="273"></a>273. Missing ios_base qualification on members of a dependent class</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2, +27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification. +That's incorrect since the names are members of a dependent base +class (14.6.2 [temp.dep]) and thus not visible.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Qualify the names with the name of the class of which they are +members, i.e., ios_base.</p> + + + + +<hr> +<h3><a name="274"></a>274. a missing/impossible allocator 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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of +any type. But the synopsis in 20.4.1 calls for allocator<>::address() to +be overloaded on reference and const_reference, which is ill-formed for +all T = const U. In other words, this won't work: +</p> + +<p> +template class std::allocator<const int>; +</p> + +<p> +The obvious solution is to disallow specializations of allocators on +const types. However, while containers' elements are required to be +assignable (which rules out specializations on const T's), I think that +allocators might perhaps be potentially useful for const values in other +contexts. So if allocators are to allow const types a partial +specialization of std::allocator<const T> would probably have to be +provided. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p> + + <blockquote><p> + any type + </p></blockquote> + +<p>to</p> + <blockquote><p> + any non-const, non-reference type + </p></blockquote> + +<p><i>[Redmond: previous proposed resolution was "any non-const, +non-volatile, non-reference type". Got rid of the "non-volatile".]</i></p> + + + + +<p><b>Rationale:</b></p> +<p> +Two resolutions were originally proposed: one that partially +specialized std::allocator for const types, and one that said an +allocator's value type may not be const. The LWG chose the second. +The first wouldn't be appropriate, because allocators are intended for +use by containers, and const value types don't work in containers. +Encouraging the use of allocators with const value types would only +lead to unsafe code. +</p> +<p> +The original text for proposed resolution 2 was modified so that it +also forbids volatile types and reference types. +</p> + +<p><i>[Curaçao: LWG double checked and believes volatile is correctly +excluded from the PR.]</i></p> + + + + + + + +<hr> +<h3><a name="275"></a>275. Wrong type in num_get::get() overloads</h3> +<p><b>Section:</b> 22.2.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 22.2.2.1.1, we have a list of overloads for num_get<>::get(). +There are eight overloads, all of which are identical except for the +last parameter. The overloads are: +</p> +<ul> +<li> long& </li> +<li> unsigned short& </li> +<li> unsigned int& </li> +<li> unsigned long& </li> +<li> short& </li> +<li> double& </li> +<li> long double& </li> +<li> void*& </li> +</ul> + +<p> +There is a similar list, in 22.2.2.1.2, of overloads for +num_get<>::do_get(). In this list, the last parameter has +the types: +</p> +<ul> +<li> long& </li> +<li> unsigned short& </li> +<li> unsigned int& </li> +<li> unsigned long& </li> +<li> float& </li> +<li> double& </li> +<li> long double& </li> +<li> void*& </li> +</ul> + +<p> +These two lists are not identical. They should be, since +<tt>get</tt> is supposed to call <tt>do_get</tt> with exactly +the arguments it was given. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.2.1.1 [facet.num.get.members], change</p> +<pre> iter_type get(iter_type in, iter_type end, ios_base& str, + ios_base::iostate& err, short& val) const; +</pre> +<p>to</p> +<pre> iter_type get(iter_type in, iter_type end, ios_base& str, + ios_base::iostate& err, float& val) const; +</pre> + + + + +<hr> +<h3><a name="276"></a>276. Assignable 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#WP">WP</a> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-11-07</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +23.1/3 states that the objects stored in a container must be +Assignable. 23.3.1 [map], paragraph 2, +states that map satisfies all requirements for a container, while in +the same time defining value_type as pair<const Key, T> - a type +that is not Assignable. +</p> + +<p> +It should be noted that there exists a valid and non-contradictory +interpretation of the current text. The wording in 23.1/3 avoids +mentioning value_type, referring instead to "objects stored in a +container." One might argue that map does not store objects of +type map::value_type, but of map::mapped_type instead, and that the +Assignable requirement applies to map::mapped_type, not +map::value_type. +</p> + +<p> +However, this makes map a special case (other containers store objects of +type value_type) and the Assignable requirement is needlessly restrictive in +general. +</p> + +<p> +For example, the proposed resolution of active library issue +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this +means that no set operations can exploit the fact that the stored +objects are Assignable. +</p> + +<p> +This is related to, but slightly broader than, closed issue +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>23.1/3: Strike the trailing part of the sentence:</p> + <blockquote><p> + , and the additional requirements of Assignable types from 23.1/3 + </p></blockquote> +<p>so that it reads:</p> + <blockquote><p> + -3- The type of objects stored in these components must meet the + requirements of CopyConstructible types (lib.copyconstructible). + </p></blockquote> + +<p>23.1/4: Modify to make clear that this requirement is not for all +containers. Change to:</p> + +<blockquote><p> +-4- Table 64 defines the Assignable requirement. Some containers +require this property of the types to be stored in the container. T is +the type used to instantiate the container. t is a value of T, and u is +a value of (possibly const) T. +</p></blockquote> + +<p>23.1, Table 65: in the first row, change "T is Assignable" to "T is +CopyConstructible".</p> + +<p>23.2.1/2: Add sentence for Assignable requirement. Change to:</p> + +<blockquote><p> +-2- A deque satisfies all of the requirements of a container and of a +reversible container (given in tables in lib.container.requirements) and +of a sequence, including the optional sequence requirements +(lib.sequence.reqmts). In addition to the requirements on the stored +object described in 23.1[lib.container.requirements], the stored object +must also meet the requirements of Assignable. Descriptions are +provided here only for operations on deque that are not described in one +of these tables or for operations where there is additional semantic +information. +</p></blockquote> + +<p>23.2.2/2: Add Assignable requirement to specific methods of list. +Change to:</p> + +<blockquote> +<p>-2- A list satisfies all of the requirements of a container and of a +reversible container (given in two tables in lib.container.requirements) +and of a sequence, including most of the the optional sequence +requirements (lib.sequence.reqmts). The exceptions are the operator[] +and at member functions, which are not provided. + +[Footnote: These member functions are only provided by containers whose +iterators are random access iterators. --- end foonote] +</p> + +<p>list does not require the stored type T to be Assignable unless the +following methods are instantiated: + +[Footnote: Implementors are permitted but not required to take advantage +of T's Assignable properties for these methods. -- end foonote] +</p> +<pre> list<T,Allocator>& operator=(const list<T,Allocator>& x ); + template <class InputIterator> + void assign(InputIterator first, InputIterator last); + void assign(size_type n, const T& t); +</pre> + + +<p>Descriptions are provided here only for operations on list that are not +described in one of these tables or for operations where there is +additional semantic information.</p> +</blockquote> + +<p>23.2.4/2: Add sentence for Assignable requirement. Change to:</p> + +<blockquote><p> +-2- A vector satisfies all of the requirements of a container and of a +reversible container (given in two tables in lib.container.requirements) +and of a sequence, including most of the optional sequence requirements +(lib.sequence.reqmts). The exceptions are the push_front and pop_front +member functions, which are not provided. In addition to the +requirements on the stored object described in +23.1[lib.container.requirements], the stored object must also meet the +requirements of Assignable. Descriptions are provided here only for +operations on vector that are not described in one of these tables or +for operations where there is additional semantic information. +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p>list, set, multiset, map, multimap are able to store non-Assignables. +However, there is some concern about <tt>list<T></tt>: +although in general there's no reason for T to be Assignable, some +implementations of the member functions <tt>operator=</tt> and +<tt>assign</tt> do rely on that requirement. The LWG does not want +to forbid such implementations.</p> + +<p>Note that the type stored in a standard container must still satisfy +the requirements of the container's allocator; this rules out, for +example, such types as "const int". See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a> +for more details. +</p> + +<p>In principle we could also relax the "Assignable" requirement for +individual <tt>vector</tt> member functions, such as +<tt>push_back</tt>. However, the LWG did not see great value in such +selective relaxation. Doing so would remove implementors' freedom to +implement <tt>vector::push_back</tt> in terms of +<tt>vector::insert</tt>.</p> + + + + + +<hr> +<h3><a name="278"></a>278. What does iterator validity mean?</h3> +<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2000-11-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 23.2.4.4 [list.ops] states that +</p> +<pre> void splice(iterator position, list<T, Allocator>& x); +</pre> +<p> +<i>invalidates</i> all iterators and references to list <tt>x</tt>. +</p> + +<p> +But what does the C++ Standard mean by "invalidate"? You +can still dereference the iterator to a spliced list element, but +you'd better not use it to delimit a range within the original +list. For the latter operation, it has definitely lost some of its +validity. +</p> + +<p> +If we accept the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, +then we'd better clarify that a "valid" iterator need no +longer designate an element within the same container as it once did. +We then have to clarify what we mean by invalidating a past-the-end +iterator, as when a vector or string grows by reallocation. Clearly, +such an iterator has a different kind of validity. Perhaps we should +introduce separate terms for the two kinds of "validity." +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add the following text to the end of section 24.1 [iterator.requirements], +after paragraph 5:</p> +<blockquote><p> +An <i>invalid</i> iterator is an iterator that may be +singular. [Footnote: This definition applies to pointers, since +pointers are iterators. The effect of dereferencing an iterator that +has been invalidated is undefined.] +</p></blockquote> + +<p><i>[post-Copenhagen: Matt provided wording.]</i></p> + + +<p><i>[Redmond: General agreement with the intent, some objections to +the wording. Dave provided new wording.]</i></p> + + + +<p><b>Rationale:</b></p> +<p>This resolution simply defines a term that the Standard uses but + never defines, "invalid", in terms of a term that is defined, + "singular".</p> + +<p>Why do we say "may be singular", instead of "is singular"? That's + becuase a valid iterator is one that is known to be nonsingular. + Invalidating an iterator means changing it in such a way that it's + no longer known to be nonsingular. An example: inserting an + element into the middle of a vector is correctly said to invalidate + all iterators pointing into the vector. That doesn't necessarily + mean they all become singular.</p> + + + + + +<hr> +<h3><a name="280"></a>280. Comparison of reverse_iterator to const reverse_iterator</h3> +<p><b>Section:</b> 24.4.1 [reverse.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +This came from an email from Steve Cleary to Fergus in reference to +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed +this in Toronto and believed it should be a separate issue. There was +also some reservations about whether this was a worthwhile problem to +fix. +</p> + +<p> +Steve said: "Fixing reverse_iterator. std::reverse_iterator can +(and should) be changed to preserve these additional +requirements." He also said in email that it can be done without +breaking user's code: "If you take a look at my suggested +solution, reverse_iterator doesn't have to take two parameters; there +is no danger of breaking existing code, except someone taking the +address of one of the reverse_iterator global operator functions, and +I have to doubt if anyone has ever done that. . . <i>But</i>, just in +case they have, you can leave the old global functions in as well -- +they won't interfere with the two-template-argument functions. With +that, I don't see how <i>any</i> user code could break." +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +<b>Section:</b> 24.4.1.1 [reverse.iterator] +add/change the following declarations:</p> +<pre> A) Add a templated assignment operator, after the same manner + as the templated copy constructor, i.e.: + + template < class U > + reverse_iterator < Iterator >& operator=(const reverse_iterator< U >& u); + + B) Make all global functions (except the operator+) have + two template parameters instead of one, that is, for + operator ==, !=, <, >, <=, >=, - replace: + + template < class Iterator > + typename reverse_iterator< Iterator >::difference_type operator-( + const reverse_iterator< Iterator >& x, + const reverse_iterator< Iterator >& y); + + with: + + template < class Iterator1, class Iterator2 > + typename reverse_iterator < Iterator1 >::difference_type operator-( + const reverse_iterator < Iterator1 > & x, + const reverse_iterator < Iterator2 > & y); +</pre> +<p> +Also make the addition/changes for these signatures in +24.4.1.3 [reverse.iter.ops]. +</p> + +<p><i>[ +Copenhagen: The LWG is concerned that the proposed resolution +introduces new overloads. Experience shows that introducing +overloads is always risky, and that it would be inappropriate to +make this change without implementation experience. It may be +desirable to provide this feature in a different way. +]</i></p> + + +<p><i>[ +Lillehammer: We now have implementation experience, and agree that +this solution is safe and correct. +]</i></p> + + + + + + + +<hr> +<h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-02</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#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p> +<p><b>Discussion:</b></p> +<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the +requirements of <tt>LessThanComparable</tt> ( [lessthancomparable]) +and <tt>CopyConstructible</tt> (20.1.1 [utility.arg.requirements]). +Since the functions take and return their arguments and result by +const reference, I believe the <tt>CopyConstructible</tt> requirement +is unnecessary. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace +25.3.7, p1 with</p> +<p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt> +( [lessthancomparable]). +</p> +<p>and replace 25.3.7, p4 with</p> +<p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt> +( [lessthancomparable]). +</p> + + + + +<hr> +<h3><a name="282"></a>282. What types does numpunct grouping refer to?</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#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2000-12-05</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Paragraph 16 mistakenly singles out integral types for inserting +thousands_sep() characters. This conflicts with the syntax for floating +point numbers described under 22.2.3.1/2. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change paragraph 16 from:</p> + +<blockquote><p> +For integral types, punct.thousands_sep() characters are inserted into +the sequence as determined by the value returned by punct.do_grouping() +using the method described in 22.2.3.1.2 [facet.numpunct.virtuals]. +</p></blockquote> + +<p>To:</p> + +<blockquote><p> +For arithmetic types, punct.thousands_sep() characters are inserted into +the sequence as determined by the value returned by punct.do_grouping() +using the method described in 22.2.3.1.2 [facet.numpunct.virtuals]. +</p></blockquote> + +<p><i>[ +Copenhagen: Opinions were divided about whether this is actually an +inconsistency, but at best it seems to have been unintentional. This +is only an issue for floating-point output: The standard is +unambiguous that implementations must parse thousands_sep characters +when performing floating-point. The standard is also unambiguous that +this requirement does not apply to the "C" locale. +]</i></p> + + +<p><i>[ +A survey of existing practice is needed; it is believed that some +implementations do insert thousands_sep characters for floating-point +output and others fail to insert thousands_sep characters for +floating-point input even though this is unambiguously required by the +standard. +]</i></p> + + +<p><i>[Post-Curaçao: the above proposed resolution is the consensus of +Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p> + + + + + + +<hr> +<h3><a name="283"></a>283. std::replace() requirement incorrect/insufficient</h3> +<p><b>Section:</b> 25.2.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#483">483</a></p> +<p><b>Discussion:</b></p> +<p> +(revision of the further discussion) +There are a number of problems with the requires clauses for the +algorithms in 25.1 and 25.2. The requires clause of each algorithm +should describe the necessary and sufficient requirements on the inputs +to the algorithm such that the algorithm compiles and runs properly. +Many of the requires clauses fail to do this. Here is a summary of the kinds +of mistakes: +</p> + +<ol> +<li> +Use of EqualityComparable, which only puts requirements on a single +type, when in fact an equality operator is required between two +different types, typically either T and the iterator's value type +or between the value types of two different iterators. +</li> +<li> +Use of Assignable for T when in fact what was needed is Assignable +for the value_type of the iterator, and convertability from T to the +value_type of the iterator. Or for output iterators, the requirement +should be that T is writable to the iterator (output iterators do +not have value types). +</li> +</ol> + +<p> +Here is the list of algorithms that contain mistakes: +</p> + +<ul> +<li>25.1.2 std::find</li> +<li>25.1.6 std::count</li> +<li>25.1.8 std::equal</li> +<li>25.1.9 std::search, std::search_n</li> +<li>25.2.4 std::replace, std::replace_copy</li> +<li>25.2.5 std::fill</li> +<li>25.2.7 std::remove, std::remove_copy</li> +</ul> + +<p> +Also, in the requirements for EqualityComparable, the requirement that +the operator be defined for const objects is lacking. +</p> + + + +<p><b>Proposed resolution:</b></p> + +<p>20.1.1 Change p1 from</p> + +<p>In Table 28, <tt>T</tt> is a type 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>T</tt>. +</p> + +<p>to</p> + +<p> +In Table 28, <tt>T</tt> is a type 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>. +</p> + +<p>25 Between p8 and p9</p> + +<p>Add the following sentence:</p> + +<p>When the description of an algorithm gives an expression such as +<tt>*first == value</tt> for a condition, it is required that the expression +evaluate to either true or false in boolean contexts.</p> + +<p>25.1.2 Change p1 by deleting the requires clause.</p> + +<p>25.1.6 Change p1 by deleting the requires clause.</p> + +<p>25.1.9</p> + +<p>Change p4 from</p> + +<p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> +(20.1.1), type Size is convertible to integral type (4.7.12.3). +</p> + +<p>to</p> + +<p>-4- Requires: The type <tt>Size</tt> is convertible to integral +type (4.7.12.3).</p> + +<p>25.2.4 Change p1 from</p> + +<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1 ) (and, for <tt>replace()</tt>, <tt>EqualityComparable</tt> (20.1.1 )).</p> + +<p>to</p> + +<p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p> + +<p>and change p4 from</p> + +<p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and, +for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt> +(20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result + +(last - first))</tt> shall not overlap.</p> + +<p>to</p> + +<p>-4- Requires: The results of the expressions <tt>*first</tt> and +<tt>new_value</tt> must be writable to the result output iterator. The +ranges <tt>[first, last)</tt> and <tt>[result, result + (last - +first))</tt> shall not overlap.</p> + + +<p>25.2.5 Change p1 from</p> + +<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The +type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p> + +<p>to</p> + +<p>-1- Requires: The expression <tt>value</tt> must be is writable to +the output iterator. The type <tt>Size</tt> is convertible to an +integral type (4.7.12.3).</p> + +<p>25.2.7 Change p1 from</p> + +<p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p> + +<p>to</p> + +<p> +-1- Requires: The value type of the iterator must be +<tt>Assignable</tt> (23.1). +</p> + + + +<p><b>Rationale:</b></p> +<p> +The general idea of the proposed solution is to remove the faulty +requires clauses and let the returns and effects clauses speak for +themselves. That is, the returns clauses contain expressions that must +be valid, and therefore already imply the correct requirements. In +addition, a sentence is added at the beginning of chapter 25 saying +that expressions given as conditions must evaluate to true or false in +a boolean context. An alternative would be to say that the type of +these condition expressions must be literally bool, but that would be +imposing a greater restriction that what the standard currently says +(which is convertible to bool). +</p> + + + + + +<hr> +<h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3> +<p><b>Section:</b> 20.6.7 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The example in 20.6.7 [comparisons], p6 shows how to use the C +library function <tt>strcmp()</tt> with the function pointer adapter +<tt>ptr_fun()</tt>. But since it's unspecified whether the C library +functions have <tt>extern "C"</tt> or <tt>extern +"C++"</tt> linkage [17.4.2.2 [using.linkage]], and since +function pointers with different the language linkage specifications +(7.5 [dcl.link]) are incompatible, whether this example is +well-formed is unspecified. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 20.6.7 [comparisons] paragraph 6 from:</p> +<blockquote> + <p>[<i>Example:</i></p> + <pre> replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++"); + </pre> + <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p> +</blockquote> + + +<p>to:</p> +<blockquote> + <p>[<i>Example:</i></p> + <pre> int compare(const char*, const char*); + replace_if(v.begin(), v.end(), + not1(bind2nd(ptr_fun(compare), "abc")), "def"); + </pre> + <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p> +</blockquote> + +<p>Also, remove footnote 215 in that same paragraph.</p> + +<p><i>[Copenhagen: Minor change in the proposed resolution. Since this +issue deals in part with C and C++ linkage, it was believed to be too +confusing for the strings in the example to be "C" and "C++". +]</i></p> + + +<p><i>[Redmond: More minor changes. Got rid of the footnote (which +seems to make a sweeping normative requirement, even though footnotes +aren't normative), and changed the sentence after the footnote so that +it corresponds to the new code fragment.]</i></p> + + + + + + +<hr> +<h3><a name="285"></a>285. minor editorial errors in fstream ctors</h3> +<p><b>Section:</b> 27.8.1.7 [ifstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-31</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.8.1.7 [ifstream.cons], p2, 27.8.1.11 [ofstream.cons], p2, and +27.8.1.15 [fstream.cons], p2 say about the effects of each constructor: +</p> + +<p>... If that function returns a null pointer, calls +<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>). +</p> + +<p>The parenthetical note doesn't apply since the ctors cannot throw an +exception due to the requirement in 27.4.4.1 [basic.ios.cons], p3 +that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Strike the parenthetical note from the Effects clause in each of the +paragraphs mentioned above. +</p> + + + + +<hr> +<h3><a name="286"></a>286. <cstdlib> requirements missing size_t typedef</h3> +<p><b>Section:</b> 25.4 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The <cstdlib> header file contains prototypes for bsearch and +qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other +prototypes (C++ Standard section 21.4 paragraph 1 table 49) that +require the typedef size_t. Yet size_t is not listed in the +<cstdlib> synopsis table 78 in section 25.4. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the type size_t to Table 78 (section 25.4) and add +the type size_t <cstdlib> to Table 97 (section C.2). +</p> + + +<p><b>Rationale:</b></p> +<p>Since size_t is in <stdlib.h>, it must also be in <cstdlib>.</p> + + + + + +<hr> +<h3><a name="288"></a>288. <cerrno> requirements missing macro EILSEQ</h3> +<p><b>Section:</b> 19.3 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list +of macros defined in <errno.h> is adjusted to include a new +macro, EILSEQ" +</p> + +<p> +ISO/IEC 14882:1998(E) section 19.3 does not refer +to the above amendment. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Update Table 26 (section 19.3) "Header <cerrno> synopsis" +and Table 95 (section C.2) "Standard Macros" to include EILSEQ. +</p> + + + + + +<hr> +<h3><a name="291"></a>291. Underspecification of set algorithms</h3> +<p><b>Section:</b> 25.3.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <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.set.operations">issues</a> in [alg.set.operations].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The standard library contains four algorithms that compute set +operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>, +<tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>. Each +of these algorithms takes two sorted ranges as inputs, and writes the +output of the appropriate set operation to an output range. The elements +in the output range are sorted. +</p> + +<p> +The ordinary mathematical definitions are generalized so that they +apply to ranges containing multiple copies of a given element. Two +elements are considered to be "the same" if, according to an +ordering relation provided by the user, neither one is less than the +other. So, for example, if one input range contains five copies of an +element and another contains three, the output range of <tt>set_union</tt> +will contain five copies, the output range of +<tt>set_intersection</tt> will contain three, the output range of +<tt>set_difference</tt> will contain two, and the output range of +<tt>set_symmetric_difference</tt> will contain two. +</p> + +<p> +Because two elements can be "the same" for the purposes +of these set algorithms, without being identical in other respects +(consider, for example, strings under case-insensitive comparison), +this raises a number of unanswered questions: +</p> + +<ul> +<li>If we're copying an element that's present in both of the +input ranges, which one do we copy it from?</li> +<li>If there are <i>n</i> copies of an element in the relevant +input range, and the output range will contain fewer copies (say +<i>m</i>) which ones do we choose? The first <i>m</i>, or the last +<i>m</i>, or something else?</li> +<li>Are these operations stable? That is, does a run of equivalent +elements appear in the output range in the same order as as it +appeared in the input range(s)?</li> +</ul> + +<p> +The standard should either answer these questions, or explicitly +say that the answers are unspecified. I prefer the former option, +since, as far as I know, all existing implementations behave the +same way. +</p> + + + +<p><b>Proposed resolution:</b></p> + +<p>Add the following to the end of 25.3.5.2 [set.union] paragraph 5:</p> +<blockquote><p> +If [first1, last1) contains <i>m</i> elements that are equivalent to +each other and [first2, last2) contains <i>n</i> elements that are +equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements +will be copied to the output range: all <i>m</i> of these elements +from [first1, last1), and the last max(<i>n-m</i>, 0) of them from +[first2, last2), in that order. +</p></blockquote> + +<p>Add the following to the end of 25.3.5.3 [set.intersection] paragraph 5:</p> +<blockquote><p> +If [first1, last1) contains <i>m</i> elements that are equivalent to each +other and [first2, last2) contains <i>n</i> elements that are +equivalent to them, the first min(<i>m</i>, <i>n</i>) of those +elements from [first1, last1) are copied to the output range. +</p></blockquote> + +<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 [set.difference] +paragraph 4:</p> +<blockquote><p> +If [first1, last1) contains <i>m</i> elements that are equivalent to each +other and [first2, last2) contains <i>n</i> elements that are +equivalent to them, the last max(<i>m-n</i>, 0) elements from +[first1, last1) are copied to the output range. +</p></blockquote> + +<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 [set.symmetric.difference] +paragraph 4:</p> +<blockquote><p> +If [first1, last1) contains <i>m</i> elements that are equivalent to +each other and [first2, last2) contains <i>n</i> elements that are +equivalent to them, then |<i>m - n</i>| of those elements will be +copied to the output range: the last <i>m - n</i> of these elements +from [first1, last1) if <i>m</i> > <i>n</i>, and the last <i>n - +m</i> of these elements from [first2, last2) if <i>m</i> < <i>n</i>. +</p></blockquote> + +<p><i>[Santa Cruz: it's believed that this language is clearer than + what's in the Standard. However, it's also believed that the + Standard may already make these guarantees (although not quite in + these words). Bill and Howard will check and see whether they think + that some or all of these changes may be redundant. If so, we may + close this issue as NAD.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>For simple cases, these descriptions are equivalent to what's + already in the Standard. For more complicated cases, they describe + the behavior of existing implementations.</p> + + + + + +<hr> +<h3><a name="292"></a>292. effects of a.copyfmt (a)</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-05</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The Effects clause of the member function <tt>copyfmt()</tt> in +27.4.4.2, p15 doesn't consider the case where the left-hand side +argument is identical to the argument on the right-hand side, that is +<tt>(this == &rhs)</tt>. If the two arguments are identical there +is no need to copy any of the data members or call any callbacks +registered with <tt>register_callback()</tt>. Also, as Howard Hinnant +points out in message c++std-lib-8149 it appears to be incorrect to +allow the object to fire <tt>erase_event</tt> followed by +<tt>copyfmt_event</tt> since the callback handling the latter event +may inadvertently attempt to access memory freed by the former. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the Effects clause in 27.4.4.2, p15 from</p> + +<blockquote><p> +<b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt> +the corresponding member objects of <tt>rhs</tt>, except that... +</p></blockquote> + +<p>to</p> + +<blockquote><p> +<b>-15- Effects:</b>If <tt>(this == &rhs)</tt> does nothing. Otherwise +assigns to the member objects of <tt>*this</tt> the corresponding member +objects of <tt>rhs</tt>, except that... +</p></blockquote> + + + + +<hr> +<h3><a name="294"></a>294. User defined macros and standard headers</h3> +<p><b>Section:</b> 17.4.3.2.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> James Kanze <b>Date:</b> 2001-01-11</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Paragraph 2 of 17.4.3.2.1 [macro.names] reads: "A +translation unit that includes a header shall not contain any macros +that define names declared in that header." As I read this, it +would mean that the following program is legal:</p> + +<pre> #define npos 3.14 + #include <sstream> +</pre> + +<p>since npos is not defined in <sstream>. It is, however, defined +in <string>, and it is hard to imagine an implementation in +which <sstream> didn't include <string>.</p> + +<p>I think that this phrase was probably formulated before it was +decided that a standard header may freely include other standard +headers. The phrase would be perfectly appropriate for C, for +example. In light of 17.4.4.1 [res.on.headers] paragraph 1, however, +it isn't stringent enough.</p> + + +<p><b>Proposed resolution:</b></p> +<p>For 17.4.3.2.1 [macro.names], replace the current wording, which reads:</p> +<blockquote> + <p>Each name defined as a macro in a header is reserved to the + implementation for any use if the translation unit includes + the header.168)</p> + + <p>A translation unit that includes a header shall not contain any + macros that define names declared or defined in that header. Nor shall + such a translation unit define macros for names lexically + identical to keywords.</p> + + <p>168) It is not permissible to remove a library macro definition by + using the #undef directive.</p> +</blockquote> + +<p>with the wording:</p> + +<blockquote> + <p>A translation unit that includes a standard library header shall not + #define or #undef names declared in any standard library header.</p> + + <p>A translation unit shall not #define or #undef names lexically + identical to keywords.</p> +</blockquote> + +<p><i>[Lillehammer: Beman provided new wording]</i></p> + + + + + + +<hr> +<h3><a name="295"></a>295. Is abs defined in <cmath>?</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Jens Maurer <b>Date:</b> 2001-01-12</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Table 80 lists the contents of the <cmath> header. It does not +list <tt>abs()</tt>. However, 26.5, paragraph 6, which lists added +signatures present in <cmath>, does say that several overloads +of <tt>abs()</tt> should be defined in <cmath>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add <tt>abs</tt> to Table 80. Also, remove the parenthetical list +of functions "(abs(), div(), rand(), srand())" from 26.5 [numarray], +paragraph 1. +</p> + +<p><i>[Copenhagen: Modified proposed resolution so that it also gets +rid of that vestigial list of functions in paragraph 1.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>All this DR does is fix a typo; it's uncontroversial. A +separate question is whether we're doing the right thing in +putting some overloads in <cmath> that we aren't also +putting in <cstdlib>. That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p> + + + + + +<hr> +<h3><a name="297"></a>297. const_mem_fun_t<>::argument_type should be const T*</h3> +<p><b>Section:</b> 20.6.8 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-06</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and +<tt>const_mem_fun1_t</tt> +in 20.5.8, p9 derive from <tt>unary_function<T*, S></tt>, and +<tt>binary_function<T*, +A, S></tt>, respectively. Consequently, their <tt>argument_type</tt>, and +<tt>first_argument_type</tt> +members, respectively, are both defined to be <tt>T*</tt> (non-const). +However, their function call member operator takes a <tt>const T*</tt> +argument. It is my opinion that <tt>argument_type</tt> should be <tt>const +T*</tt> instead, so that one can easily refer to it in generic code. The +example below derived from existing code fails to compile due to the +discrepancy: +</p> + +<p><tt>template <class T></tt> +<br><tt>void foo (typename T::argument_type arg) // #1</tt> +<br><tt>{</tt> +<br><tt> typename T::result_type (T::*pf) (typename +T::argument_type) +const = // #2</tt> +<br><tt> &T::operator();</tt> +<br><tt>}</tt> +</p> + +<p><tt>struct X { /* ... */ };</tt></p> + +<p><tt>int main ()</tt> +<br><tt>{</tt> +<br><tt> const X x;</tt> +<br><tt> foo<std::const_mem_fun_t<void, X> +>(&x); +// #3</tt> +<br><tt>}</tt> +</p> + +<p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument +<br>#2 the type of the pointer is incompatible with the type of the member +function +<br>#3 the address of a constant being passed to a function taking a non-const +<tt>X*</tt> +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace the top portion of the definition of the class template +const_mem_fun_t in 20.5.8, p8 +</p> +<p><tt>template <class S, class T> class const_mem_fun_t</tt> +<br><tt> : public +unary_function<T*, S> {</tt> +</p> +<p>with</p> +<p><tt>template <class S, class T> class const_mem_fun_t</tt> +<br><tt> : public +unary_function<<b>const</b> T*, S> {</tt> +</p> +<p>Also replace the top portion of the definition of the class template +const_mem_fun1_t in 20.5.8, p9</p> +<p><tt>template <class S, class T, class A> class const_mem_fun1_t</tt> +<br><tt> : public +binary_function<T*, A, S> {</tt> +</p> +<p>with</p> +<p><tt>template <class S, class T, class A> class const_mem_fun1_t</tt> +<br><tt> : public +binary_function<<b>const</b> T*, A, S> {</tt> +</p> + + +<p><b>Rationale:</b></p> +<p>This is simply a contradiction: the <tt>argument_type</tt> typedef, +and the argument type itself, are not the same.</p> + + + + + +<hr> +<h3><a name="298"></a>298. ::operator delete[] requirement incorrect/insufficient</h3> +<p><b>Section:</b> 18.5.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> John A. Pedretti <b>Date:</b> 2001-01-10</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 - +namely that for non-null value of <i>ptr</i>, the operator reclaims storage +allocated by the earlier call to the default <tt>operator new[]</tt> - is not +correct in all cases. Since the specified <tt>operator new[]</tt> default +behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be +replaced, along with <tt>operator delete</tt>, by the user, to implement their +own memory management, the specified default behavior of<tt> operator +delete[]</tt> must be to call <tt>operator delete</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 18.5.1.2, p12 from</p> +<blockquote><p> +<b>-12-</b> <b>Default behavior:</b></p> +<ul> +<li> +For a null value of <i><tt>ptr</tt></i> , does nothing. +</li> +<li> +Any other value of <i><tt>ptr</tt></i> shall be a value returned +earlier by a call to the default <tt>operator new[](std::size_t)</tt>. +[Footnote: The value must not have been invalidated by an intervening +call to <tt>operator delete[](void*)</tt> (17.4.3.8 [res.on.arguments]). +--- end footnote] +For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage +allocated by the earlier call to the default <tt>operator new[]</tt>. +</li> +</ul> +</blockquote> + +<p>to</p> + +<blockquote><p> +<b>-12-</b> <b>Default behavior: </b>Calls <tt>operator +delete(</tt><i>ptr</i>) +or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively. +</p></blockquote> +<p>and expunge paragraph 13.</p> + + + + +<hr> +<h3><a name="300"></a>300. list::merge() specification incomplete</h3> +<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> John Pedretti <b>Date:</b> 2001-01-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The "Effects" clause for list::merge() (23.2.4.4 [list.ops], p23) +appears to be incomplete: it doesn't cover the case where the argument +list is identical to *this (i.e., this == &x). The requirement in the +note in p24 (below) is that x be empty after the merge which is surely +unintended in this case. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 23.2.4.4 [list.ops], replace paragraps 23-25 with:</p> +<blockquote> +<p> +23 Effects: if (&x == this) does nothing; otherwise, merges the two +sorted ranges [begin(), end()) and [x.begin(), x.end()). The result +is a range in which the elements will be sorted in non-decreasing +order according to the ordering defined by comp; that is, for every +iterator i in the range other than the first, the condition comp(*i, +*(i - 1)) will be false. +</p> + +<p> +24 Notes: Stable: if (&x != this), then for equivalent elements in the +two original ranges, the elements from the original range [begin(), +end()) always precede the elements from the original range [x.begin(), +x.end()). If (&x != this) the range [x.begin(), x.end()) is empty +after the merge. +</p> + +<p> +25 Complexity: At most size() + x.size() - 1 applications of comp if +(&x ! = this); otherwise, no applications of comp are performed. If +an exception is thrown other than by a comparison there are no +effects. +</p> + +</blockquote> + +<p><i>[Copenhagen: The original proposed resolution did not fix all of +the problems in 23.2.4.4 [list.ops], p22-25. Three different +paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>. +Changing p23, without changing the other two, appears to introduce +contradictions. Additionally, "merges the argument list into the +list" is excessively vague.]</i></p> + + +<p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p> + + + + + + + +<hr> +<h3><a name="301"></a>301. basic_string template ctor effects clause omits allocator argument</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-27</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The effects clause for the basic_string template ctor in 21.3.1, p15 +leaves out the third argument of type Allocator. I believe this to be +a mistake. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace</p> + +<blockquote> + <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral + type, equivalent to</p> + + <blockquote><p><tt>basic_string(static_cast<size_type>(begin), + static_cast<value_type>(end))</tt></p></blockquote> +</blockquote> + +<p>with</p> + +<blockquote> + <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral + type, equivalent to</p> + + <blockquote><p><tt>basic_string(static_cast<size_type>(begin), + static_cast<value_type>(end), <b>a</b>)</tt></p></blockquote> +</blockquote> + + + + +<hr> +<h3><a name="303"></a>303. Bitset input operator underspecified</h3> +<p><b>Section:</b> 23.3.5.3 [bitset.operators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-02-05</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator +"Extracts up to <i>N</i> (single-byte) characters from +<i>is</i>.", where <i>is</i> is a stream of type +<tt>basic_istream<charT, traits></tt>. +</p> + +<p> +The standard does not say what it means to extract single byte +characters from a stream whose character type, <tt>charT</tt>, is in +general not a single-byte character type. Existing implementations +differ. +</p> + +<p> +A reasonable solution will probably involve <tt>widen()</tt> and/or +<tt>narrow()</tt>, since they are the supplied mechanism for +converting a single character between <tt>char</tt> and +arbitrary <tt>charT</tt>. +</p> + +<p>Narrowing the input characters is not the same as widening the +literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some +locales in which more than one wide character maps to the narrow +character <tt>'0'</tt>. Narrowing means that alternate +representations may be used for bitset input, widening means that +they may not be.</p> + +<p>Note that for numeric input, <tt>num_get<></tt> +(22.2.2.1.2/8) compares input characters to widened version of narrow +character literals.</p> + +<p>From Pete Becker, in c++std-lib-8224:</p> +<blockquote> +<p> +Different writing systems can have different representations for the +digits that represent 0 and 1. For example, in the Unicode representation +of the Devanagari script (used in many of the Indic languages) the digit 0 +is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those +into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and +0x0031 for for the Latin representations of '0' and '1', as well as code +points for the same numeric values in several other scripts (Tamil has no +character for 0, but does have the digits 1-9), and any of these values +would also be narrowed to '0' and '1'. +</p> + +<p>...</p> + +<p> +It's fairly common to intermix both native and Latin +representations of numbers in a document. So I think the rule has to be +that if a wide character represents a digit whose value is 0 then the bit +should be cleared; if it represents a digit whose value is 1 then the bit +should be set; otherwise throw an exception. So in a Devanagari locale, +both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031 +would set it. Widen can't do that. It would pick one of those two values, +and exclude the other one. +</p> + +</blockquote> + +<p>From Jens Maurer, in c++std-lib-8233:</p> + +<blockquote> +<p> +Whatever we decide, I would find it most surprising if +bitset conversion worked differently from int conversion +with regard to alternate local representations of +numbers. +</p> + +<p>Thus, I think the options are:</p> +<ul> + <li> Have a new defect issue for 22.2.2.1.2/8 so that it will +require the use of narrow().</li> + + <li> Have a defect issue for bitset() which describes clearly +that widen() is to be used.</li> +</ul> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + <p>Replace the first two sentences of paragraph 5 with:</p> + + <blockquote><p> + Extracts up to <i>N</i> characters from <i>is</i>. Stores these + characters in a temporary object <i>str</i> of type + <tt>basic_string<charT, traits></tt>, then evaluates the + expression <tt><i>x</i> = bitset<N>(<i>str</i>)</tt>. + </p></blockquote> + + <p>Replace the third bullet item in paragraph 5 with:</p> + <ul><li> + the next input character is neither <tt><i>is</i>.widen(0)</tt> + nor <tt><i>is</i>.widen(1)</tt> (in which case the input character + is not extracted). + </li></ul> + + + +<p><b>Rationale:</b></p> +<p>Input for <tt>bitset</tt> should work the same way as numeric +input. Using <tt>widen</tt> does mean that alternative digit +representations will not be recognized, but this was a known +consequence of the design choice.</p> + + + + + +<hr> +<h3><a name="305"></a>305. Default behavior of codecvt<wchar_t, char, mbstate_t>::length()</h3> +<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-01-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>22.2.1.5/3 introduces codecvt in part with:</p> + +<blockquote><p> + codecvt<wchar_t,char,mbstate_t> converts between the native + character sets for tiny and wide characters. Instantiations on + mbstate_t perform conversion between encodings known to the library + implementor. +</p></blockquote> + +<p>But 22.2.1.5.2/10 describes do_length in part with:</p> + +<blockquote><p> + ... codecvt<wchar_t, char, mbstate_t> ... return(s) the lesser of max and + (from_end-from). +</p></blockquote> + +<p> +The semantics of do_in and do_length are linked. What one does must +be consistent with what the other does. 22.2.1.5/3 leads me to +believe that the vendor is allowed to choose the algorithm that +codecvt<wchar_t,char,mbstate_t>::do_in performs so that it makes +his customers happy on a given platform. But 22.2.1.5.2/10 explicitly +says what codecvt<wchar_t,char,mbstate_t>::do_length must +return. And thus indirectly specifies the algorithm that +codecvt<wchar_t,char,mbstate_t>::do_in must perform. I believe +that this is not what was intended and is a defect. +</p> + +<p>Discussion from the -lib reflector: + +<br>This proposal would have the effect of making the semantics of +all of the virtual functions in <tt>codecvt<wchar_t, char, +mbstate_t></tt> implementation specified. Is that what we want, or +do we want to mandate specific behavior for the base class virtuals +and leave the implementation specified behavior for the codecvt_byname +derived class? The tradeoff is that former allows implementors to +write a base class that actually does something useful, while the +latter gives users a way to get known and specified---albeit +useless---behavior, and is consistent with the way the standard +handles other facets. It is not clear what the original intention +was.</p> + +<p> +Nathan has suggest a compromise: a character that is a widened version +of the characters in the basic execution character set must be +converted to a one-byte sequence, but there is no such requirement +for characters that are not part of the basic execution character set. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 22.2.1.5.2/5 from: +</p> +<p> +The instantiations required in Table 51 (lib.locale.category), namely +codecvt<wchar_t,char,mbstate_t> and +codecvt<char,char,mbstate_t>, store no characters. Stores no more +than (to_limit-to) destination elements. It always leaves the to_next +pointer pointing one beyond the last element successfully stored. +</p> +<p> +to: +</p> +<p> +Stores no more than (to_limit-to) destination elements, and leaves the +to_next pointer pointing one beyond the last element successfully +stored. codecvt<char,char,mbstate_t> stores no characters. +</p> + +<p>Change 22.2.1.5.2/10 from:</p> + +<blockquote><p> +-10- Returns: (from_next-from) where from_next is the largest value in +the range [from,from_end] such that the sequence of values in the +range [from,from_next) represents max or fewer valid complete +characters of type internT. The instantiations required in Table 51 +(21.1.1.1.1), namely codecvt<wchar_t, char, mbstate_t> and +codecvt<char, char, mbstate_t>, return the lesser of max and +(from_end-from). +</p></blockquote> + +<p>to:</p> + +<blockquote><p> +-10- Returns: (from_next-from) where from_next is the largest value in +the range [from,from_end] such that the sequence of values in the range +[from,from_next) represents max or fewer valid complete characters of +type internT. The instantiation codecvt<char, char, mbstate_t> returns +the lesser of max and (from_end-from). +</p></blockquote> + +<p><i>[Redmond: Nathan suggested an alternative resolution: same as +above, but require that, in the default encoding, a character from the +basic execution character set would map to a single external +character. The straw poll was 8-1 in favor of the proposed +resolution.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The default encoding should be whatever users of a given platform +would expect to be the most natural. This varies from platform to +platform. In many cases there is a preexisting C library, and users +would expect the default encoding to be whatever C uses in the default +"C" locale. We could impose a guarantee like the one Nathan suggested +(a character from the basic execution character set must map to a +single external character), but this would rule out important +encodings that are in common use: it would rule out JIS, for +example, and it would rule out a fixed-width encoding of UCS-4.</p> + +<p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida; +"shift-JIS" changed to "JIS".]</i></p> + + + + + + + +<hr> +<h3><a name="306"></a>306. offsetof macro and non-POD types</h3> +<p><b>Section:</b> 18.1 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-02-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p> + +<p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt> +accepts a restricted set of <i>type</i> arguments in this +International Standard. <i>type</i> shall be a POD structure or a POD +union (clause 9). The result of applying the offsetof macro to a field +that is a static data member or a function member is +undefined."</p> + +<p>For the POD requirement, it doesn't say "no diagnostic +required" or "undefined behavior". I read 1.4 [intro.compliance], paragraph 1, to mean that a diagnostic is required. +It's not clear whether this requirement was intended. While it's +possible to provide such a diagnostic, the extra complication doesn't +seem to add any value. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD +structure or a POD union the results are undefined."</p> + +<p><i>[Copenhagen: straw poll was 7-4 in favor. It was generally +agreed that requiring a diagnostic was inadvertent, but some LWG +members thought that diagnostics should be required whenever +possible.]</i></p> + + + + + + +<hr> +<h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3> +<p><b>Section:</b> 23.2.4 [list] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-03-13</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>From reflector message c++std-lib-8330. See also lib-8317.</p> + +<p> +The standard is currently inconsistent in 23.2.4.2 [list.capacity] +paragraph 1 and 23.2.4.3 [list.modifiers] paragraph 1. +23.2.3.3/1, for example, says: +</p> + +<blockquote><p> +-1- Any sequence supporting operations back(), push_back() and pop_back() +can be used to instantiate stack. In particular, vector (lib.vector), list +(lib.list) and deque (lib.deque) can be used. +</p></blockquote> + +<p>But this is false: vector<bool> can not be used, because the +container adaptors return a T& rather than using the underlying +container's reference type.</p> + +<p>This is a contradiction that can be fixed by:</p> + +<ol> +<li>Modifying these paragraphs to say that vector<bool> + is an exception.</li> +<li>Removing the vector<bool> specialization.</li> +<li>Changing the return types of stack and priority_queue to use + reference typedef's.</li> +</ol> + +<p> +I propose 3. This does not preclude option 2 if we choose to do it +later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>); the issues are independent. Option +3 offers a small step towards support for proxied containers. This +small step fixes a current contradiction, is easy for vendors to +implement, is already implemented in at least one popular lib, and +does not break any code. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p>Summary: Add reference and const_reference typedefs to queue, +priority_queue and stack. Change return types of "value_type&" to +"reference". Change return types of "const value_type&" to +"const_reference". Details:</p> + +<p>Change 23.2.3.1/1 from:</p> + +<pre> namespace std { + template <class T, class Container = deque<T> > + class queue { + public: + typedef typename Container::value_type value_type; + typedef typename Container::size_type size_type; + typedef Container container_type; + protected: + Container c; + + public: + explicit queue(const Container& = Container()); + + bool empty() const { return c.empty(); } + size_type size() const { return c.size(); } + value_type& front() { return c.front(); } + const value_type& front() const { return c.front(); } + value_type& back() { return c.back(); } + const value_type& back() const { return c.back(); } + void push(const value_type& x) { c.push_back(x); } + void pop() { c.pop_front(); } + }; +</pre> + +<p>to:</p> + +<pre> namespace std { + template <class T, class Container = deque<T> > + class queue { + public: + typedef typename Container::value_type value_type; + typedef typename Container::reference reference; + typedef typename Container::const_reference const_reference; + typedef typename Container::value_type value_type; + typedef typename Container::size_type size_type; + typedef Container container_type; + protected: + Container c; + + public: + explicit queue(const Container& = Container()); + + bool empty() const { return c.empty(); } + size_type size() const { return c.size(); } + reference front() { return c.front(); } + const_reference front() const { return c.front(); } + reference back() { return c.back(); } + const_reference back() const { return c.back(); } + void push(const value_type& x) { c.push_back(x); } + void pop() { c.pop_front(); } + }; +</pre> + +<p>Change 23.2.3.2/1 from:</p> + +<pre> namespace std { + template <class T, class Container = vector<T>, + class Compare = less<typename Container::value_type> > + class priority_queue { + public: + typedef typename Container::value_type value_type; + typedef typename Container::size_type size_type; + typedef Container container_type; + protected: + Container c; + Compare comp; + + public: + explicit priority_queue(const Compare& x = Compare(), + const Container& = Container()); + template <class InputIterator> + priority_queue(InputIterator first, InputIterator last, + const Compare& x = Compare(), + const Container& = Container()); + + bool empty() const { return c.empty(); } + size_type size() const { return c.size(); } + const value_type& top() const { return c.front(); } + void push(const value_type& x); + void pop(); + }; + // no equality is provided + } +</pre> + +<p>to:</p> + +<pre> namespace std { + template <class T, class Container = vector<T>, + class Compare = less<typename Container::value_type> > + class priority_queue { + public: + typedef typename Container::value_type value_type; + typedef typename Container::reference reference; + typedef typename Container::const_reference const_reference; + typedef typename Container::size_type size_type; + typedef Container container_type; + protected: + Container c; + Compare comp; + + public: + explicit priority_queue(const Compare& x = Compare(), + const Container& = Container()); + template <class InputIterator> + priority_queue(InputIterator first, InputIterator last, + const Compare& x = Compare(), + const Container& = Container()); + + bool empty() const { return c.empty(); } + size_type size() const { return c.size(); } + const_reference top() const { return c.front(); } + void push(const value_type& x); + void pop(); + }; + // no equality is provided + } +</pre> + +<p>And change 23.2.3.3/1 from:</p> + +<pre> namespace std { + template <class T, class Container = deque<T> > + class stack { + public: + typedef typename Container::value_type value_type; + typedef typename Container::size_type size_type; + typedef Container container_type; + protected: + Container c; + + public: + explicit stack(const Container& = Container()); + + bool empty() const { return c.empty(); } + size_type size() const { return c.size(); } + value_type& top() { return c.back(); } + const value_type& top() const { return c.back(); } + void push(const value_type& x) { c.push_back(x); } + void pop() { c.pop_back(); } + }; + + template <class T, class Container> + bool operator==(const stack<T, Container>& x, + const stack<T, Container>& y); + template <class T, class Container> + bool operator< (const stack<T, Container>& x, + const stack<T, Container>& y); + template <class T, class Container> + bool operator!=(const stack<T, Container>& x, + const stack<T, Container>& y); + template <class T, class Container> + bool operator> (const stack<T, Container>& x, + const stack<T, Container>& y); + template <class T, class Container> + bool operator>=(const stack<T, Container>& x, + const stack<T, Container>& y); + template <class T, class Container> + bool operator<=(const stack<T, Container>& x, + const stack<T, Container>& y); + } +</pre> + +<p>to:</p> + +<pre> namespace std { + template <class T, class Container = deque<T> > + class stack { + public: + typedef typename Container::value_type value_type; + typedef typename Container::reference reference; + typedef typename Container::const_reference const_reference; + typedef typename Container::size_type size_type; + typedef Container container_type; + protected: + Container c; + + public: + explicit stack(const Container& = Container()); + + bool empty() const { return c.empty(); } + size_type size() const { return c.size(); } + reference top() { return c.back(); } + const_reference top() const { return c.back(); } + void push(const value_type& x) { c.push_back(x); } + void pop() { c.pop_back(); } + }; + + template <class T, class Container> + bool operator==(const stack<T, Container>& x, + const stack<T, Container>& y); + template <class T, class Container> + bool operator< (const stack<T, Container>& x, + const stack<T, Container>& y); + template <class T, class Container> + bool operator!=(const stack<T, Container>& x, + const stack<T, Container>& y); + template <class T, class Container> + bool operator> (const stack<T, Container>& x, + const stack<T, Container>& y); + template <class T, class Container> + bool operator>=(const stack<T, Container>& x, + const stack<T, Container>& y); + template <class T, class Container> + bool operator<=(const stack<T, Container>& x, + const stack<T, Container>& y); + } +</pre> + +<p><i>[Copenhagen: This change was discussed before the IS was released +and it was deliberately not adopted. Nevertheless, the LWG believes +(straw poll: 10-2) that it is a genuine defect.]</i></p> + + + + + + +<hr> +<h3><a name="308"></a>308. Table 82 mentions unrelated headers</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-15</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Table 82 in section 27 mentions the header <cstdlib> for String +streams (27.7 [string.streams]) and the headers <cstdio> and +<cwchar> for File streams (27.8 [file.streams]). It's not clear +why these headers are mentioned in this context since they do not +define any of the library entities described by the +subclauses. According to 17.4.1.1 [contents], only such headers +are to be listed in the summary. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove <cstdlib> and <cwchar> from +Table 82.</p> + +<p><i>[Copenhagen: changed the proposed resolution slightly. The +original proposed resolution also said to remove <cstdio> from +Table 82. However, <cstdio> is mentioned several times within +section 27.8 [file.streams], including 27.8.2 [c.files].]</i></p> + + + + + + +<hr> +<h3><a name="310"></a>310. Is errno a macro?</h3> +<p><b>Section:</b> 17.4.1.2 [headers], 19.3 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-03-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + Exactly how should errno be declared in a conforming C++ header? + </p> + + <p> + The C standard says in 7.1.4 that it is unspecified whether errno is a + macro or an identifier with external linkage. In some implementations + it can be either, depending on compile-time options. (E.g., on + Solaris in multi-threading mode, errno is a macro that expands to a + function call, but is an extern int otherwise. "Unspecified" allows + such variability.) + </p> + + <p>The C++ standard:</p> + <ul> + <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li> + <li>17.4.3.1.3 footnote 166 says errno is reserved as an external + name (true), and implies that it is an identifier.</li> + <li>19.3 simply lists errno as a macro (by what reasoning?) and goes + on to say that the contents of of C++ <errno.h> are the + same as in C, begging the question.</li> + <li>C.2, table 95 lists errno as a macro, without comment.</li> + </ul> + + <p>I find no other references to errno.</p> + + <p>We should either explicitly say that errno must be a macro, even + though it need not be a macro in C, or else explicitly leave it + unspecified. We also need to say something about namespace std. + A user who includes <cerrno> needs to know whether to write + <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or + else <cerrno> is useless.</p> + + <p>Two acceptable fixes:</p> + <ul> + <li><p>errno must be a macro. This is trivially satisfied by adding<br> + #define errno (::std::errno)<br> + to the headers if errno is not already a macro. You then always + write errno without any scope qualification, and it always expands + to a correct reference. Since it is always a macro, you know to + avoid using errno as a local identifer.</p></li> + <li><p>errno is in the global namespace. This fix is inferior, because + ::errno is not guaranteed to be well-formed.</p></li> + </ul> + + <p><i>[ + This issue was first raised in 1999, but it slipped through + the cracks. + ]</i></p> + + + +<p><b>Proposed resolution:</b></p> + <p>Change the Note in section 17.4.1.2p5 from</p> + + <blockquote><p> + Note: the names defined as macros in C include the following: + assert, errno, offsetof, setjmp, va_arg, va_end, and va_start. + </p></blockquote> + + <p>to</p> + + <blockquote><p> + Note: the names defined as macros in C include the following: + assert, offsetof, setjmp, va_arg, va_end, and va_start. + </p></blockquote> + + <p>In section 19.3, change paragraph 2 from</p> + + <blockquote><p> + The contents are the same as the Standard C library header + <errno.h>. + </p></blockquote> + + <p>to</p> + + <blockquote><p> + The contents are the same as the Standard C library header + <errno.h>, except that errno shall be defined as a macro. + </p></blockquote> + + +<p><b>Rationale:</b></p> +<p>C++ must not leave it up to the implementation to decide whether or +not a name is a macro; it must explicitly specify exactly which names +are required to be macros. The only one that really works is for it +to be a macro.</p> + +<p><i>[Curaçao: additional rationale added.]</i></p> + + + + + + + +<hr> +<h3><a name="311"></a>311. Incorrect wording in basic_ostream class synopsis</h3> +<p><b>Section:</b> 27.6.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-03-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>In 27.6.2.1 [ostream], the synopsis of class basic_ostream says:</p> + +<pre> // partial specializationss + template<class traits> + basic_ostream<char,traits>& operator<<( basic_ostream<char,traits>&, + const char * ); +</pre> + +<p>Problems:</p> +<ul> +<li>Too many 's's at the end of "specializationss" </li> +<li>This is an overload, not a partial specialization</li> +</ul> + + + +<p><b>Proposed resolution:</b></p> +<p>In the synopsis in 27.6.2.1 [ostream], remove the +<i>// partial specializationss</i> comment. Also remove the same +comment (correctly spelled, but still incorrect) from the synopsis in +27.6.2.6.4 [ostream.inserters.character]. +</p> + +<p><i>[ +Pre-Redmond: added 27.6.2.6.4 [ostream.inserters.character] because of Martin's +comment in c++std-lib-8939. +]</i></p> + + + + + + + +<hr> +<h3><a name="312"></a>312. Table 27 is missing headers</h3> +<p><b>Section:</b> 20 [utilities] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-29</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Table 27 in section 20 lists the header <memory> (only) for +Memory (lib.memory) but neglects to mention the headers +<cstdlib> and <cstring> that are discussed in 20.5.5 [meta.rel].</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add <cstdlib> and <cstring> to Table 27, in the same row +as <memory>.</p> + + + + + +<hr> +<h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3> +<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-05-01</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +23.2.4.4 [list.ops], Para 21 describes the complexity of +list::unique as: "If the range (last - first) is not empty, exactly +(last - first) -1 applications of the corresponding predicate, +otherwise no applications of the predicate)". +</p> + +<p> +"(last - first)" is not a range. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the "range" from (last - first) to [first, last). +</p> + + + + +<hr> +<h3><a name="316"></a>316. Vague text in Table 69</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Table 69 says this about a_uniq.insert(t):</p> + +<blockquote><p> +inserts t if and only if there is no element in the container with key +equivalent to the key of t. The bool component of the returned pair +indicates whether the insertion takes place and the iterator component of the +pair points to the element with key equivalent to the key of t. +</p></blockquote> + +<p>The description should be more specific about exactly how the bool component +indicates whether the insertion takes place.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the text in question to</p> + +<blockquote><p> +...The bool component of the returned pair is true if and only if the insertion +takes place... +</p></blockquote> + + + + + +<hr> +<h3><a name="317"></a>317. Instantiation vs. specialization of facets</h3> +<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The localization section of the standard refers to specializations of +the facet templates as instantiations even though the required facets +are typically specialized rather than explicitly (or implicitly) +instantiated. In the case of ctype<char> and +ctype_byname<char> (and the wchar_t versions), these facets are +actually required to be specialized. The terminology should be +corrected to make it clear that the standard doesn't mandate explicit +instantiation (the term specialization encompasses both explicit +instantiations and specializations). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In the following paragraphs, replace all occurrences of the word +instantiation or instantiations with specialization or specializations, +respectively: +</p> + +<blockquote><p> +22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5, +22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, +22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and +Footnote 242. +</p></blockquote> + +<p>And change the text in 22.1.1.1.1, p4 from</p> + +<blockquote><p> + An implementation is required to provide those instantiations + for facet templates identified as members of a category, and + for those shown in Table 52: +</p></blockquote> + +<p>to</p> + +<blockquote><p> + An implementation is required to provide those specializations... +</p></blockquote> + +<p><i>[Nathan will review these changes, and will look for places where +explicit specialization is necessary.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>This is a simple matter of outdated language. The language to +describe templates was clarified during the standardization process, +but the wording in clause 22 was never updated to reflect that +change.</p> + + + + + + + +<hr> +<h3><a name="318"></a>318. Misleading comment in definition of numpunct_byname</h3> +<p><b>Section:</b> 22.2.3.2 [locale.numpunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-12</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The definition of the numpunct_byname template contains the following +comment:</p> + +<pre> namespace std { + template <class charT> + class numpunct_byname : public numpunct<charT> { + // this class is specialized for char and wchar_t. + ... +</pre> + +<p>There is no documentation of the specializations and it seems +conceivable that an implementation will not explicitly specialize the +template at all, but simply provide the primary template.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove the comment from the text in 22.2.3.2 and from the proposed +resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p> + + + + +<hr> +<h3><a name="319"></a>319. Storage allocation wording confuses "Required behavior", "Requires"</h3> +<p><b>Section:</b> 18.5.1.1 [new.delete.single], 18.5.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2001-05-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The standard specifies 17.3.1.3 [structure.specifications] that "Required +behavior" elements describe "the semantics of a function definition +provided by either the implementation or a C++ program."</p> + +<p>The standard specifies 17.3.1.3 [structure.specifications] that "Requires" +elements describe "the preconditions for calling the function."</p> + +<p>In the sections noted below, the current wording specifies +"Required Behavior" for what are actually preconditions, and thus +should be specified as "Requires".</p> + + + +<p><b>Proposed resolution:</b></p> + +<p>In 18.5.1.1 [new.delete.single] Para 12 Change:</p> +<blockquote> + <p>Required behavior: accept a value of ptr that is null or that was + returned by an earlier call ...</p> +</blockquote> +<p>to:</p> +<blockquote> + <p>Requires: the value of ptr is null or the value returned by an + earlier call ...</p> +</blockquote> + +<p>In 18.5.1.2 [new.delete.array] Para 11 Change:</p> +<blockquote> + <p>Required behavior: accept a value of ptr that is null or that was + returned by an earlier call ...</p> +</blockquote> +<p>to:</p> +<blockquote> + <p>Requires: the value of ptr is null or the value returned by an + earlier call ...</p> +</blockquote> + + + + + +<hr> +<h3><a name="320"></a>320. list::assign overspecified</h3> +<p><b>Section:</b> 23.2.4.1 [list.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-05-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 23.2.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have +the "effects" of a call to erase followed by a call to insert. +</p> + +<p> +I would like to document that implementers have the freedom to implement +assign by other methods, as long as the end result is the same and the +exception guarantee is as good or better than the basic guarantee. +</p> + +<p> +The motivation for this is to use T's assignment operator to recycle +existing nodes in the list instead of erasing them and reallocating +them with new values. It is also worth noting that, with careful +coding, most common cases of assign (everything but assignment with +true input iterators) can elevate the exception safety to strong if +T's assignment has a nothrow guarantee (with no extra memory cost). +Metrowerks does this. However I do not propose that this subtlety be +standardized. It is a QoI issue. </p> + +<p>Existing practise: +Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 23.2.4.1 [list.cons]/7 from:</p> + +<blockquote> +<p>Effects:</p> + +<pre> erase(begin(), end()); + insert(begin(), first, last); +</pre> +</blockquote> + +<p>to:</p> + +<blockquote> +<p>Effects: Replaces the contents of the list with the range [first, last).</p> +</blockquote> + +<p>In 23.1.3 [sequence.reqmts], in Table 67 (sequence requirements), +add two new rows:</p> +<pre> a.assign(i,j) void pre: i,j are not iterators into a. + Replaces elements in a with a copy + of [i, j). + + a.assign(n,t) void pre: t is not a reference into a. + Replaces elements in a with n copies + of t. +</pre> + +<p>Change 23.2.4.1 [list.cons]/8 from:</p> + +<blockquote> +<p>Effects:</p> +<pre> erase(begin(), end()); + insert(begin(), n, t); +</pre> +</blockquote> +<p>to:</p> + +<blockquote> +<p>Effects: Replaces the contents of the list with n copies of t.</p> +</blockquote> + +<p><i>[Redmond: Proposed resolution was changed slightly. Previous +version made explicit statement about exception safety, which wasn't +consistent with the way exception safety is expressed elsewhere. +Also, the change in the sequence requirements is new. Without that +change, the proposed resolution would have required that assignment of +a subrange would have to work. That too would have been +overspecification; it would effectively mandate that assignment use a +temporary. Howard provided wording. +]</i></p> + + +<p><i>[Curaçao: Made editorial improvement in wording; changed +"Replaces elements in a with copies of elements in [i, j)." +with "Replaces the elements of a with a copy of [i, j)." +Changes not deemed serious enough to requre rereview.]</i></p> + + + + + + + +<hr> +<h3><a name="321"></a>321. Typo in num_get</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#WP">WP</a> + <b>Submitter:</b> Kevin Djang <b>Date:</b> 2001-05-17</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 22.2.2.1.2 at p7 states that "A length specifier is added to +the conversion function, if needed, as indicated in Table 56." +However, Table 56 uses the term "length modifier", not "length +specifier". +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 22.2.2.1.2 at p7, change the text "A length specifier is added ..." +to be "A length modifier is added ..." +</p> + + +<p><b>Rationale:</b></p> +<p>C uses the term "length modifier". We should be consistent.</p> + + + + + + +<hr> +<h3><a name="322"></a>322. iterator and const_iterator should have the same value type</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#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-05-17</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It's widely assumed that, if X is a container, +iterator_traits<X::iterator>::value_type and +iterator_traits<X::const_iterator>::value_type should both be +X::value_type. However, this is nowhere stated. The language in +Table 65 is not precise about the iterators' value types (it predates +iterator_traits), and could even be interpreted as saying that +iterator_traits<X::const_iterator>::value_type should be "const +X::value_type". +</p> + +<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In Table 65 ("Container Requirements"), change the return type for +X::iterator to "iterator type whose value type is T". Change the +return type for X::const_iterator to "constant iterator type whose +value type is T".</p> + + +<p><b>Rationale:</b></p> +<p> +This belongs as a container requirement, rather than an iterator +requirement, because the whole notion of iterator/const_iterator +pairs is specific to containers' iterator. +</p> +<p> +It is existing practice that (for example) +iterator_traits<list<int>::const_iterator>::value_type +is "int", rather than "const int". This is consistent with +the way that const pointers are handled: the standard already +requires that iterator_traits<const int*>::value_type is int. +</p> + + + + + +<hr> +<h3><a name="324"></a>324. Do output iterators have value types?</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#WP">WP</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-07</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>Table 73 suggests that output iterators have value types. It +requires the expression "*a = t". Additionally, although Table 73 +never lists "a = t" or "X(a) = t" in the "expressions" column, it +contains a note saying that "a = t" and "X(a) = t" have equivalent +(but nowhere specified!) semantics.</p> + +<p>According to 24.1/9, t is supposed to be "a value of value type +T":</p> + + <blockquote><p> + In the following sections, a and b denote values of X, n denotes a + value of the difference type Distance, u, tmp, and m denote + identifiers, r denotes a value of X&, t denotes a value of + value type T. + </p></blockquote> + +<p>Two other parts of the standard that are relevant to whether +output iterators have value types:</p> + +<ul> + <li>24.1/1 says "All iterators i support the expression *i, + resulting in a value of some class, enumeration, or built-in type + T, called the value type of the iterator".</li> + + <li> + 24.3.1/1, which says "In the case of an output iterator, the types + iterator_traits<Iterator>::difference_type + iterator_traits<Iterator>::value_type are both defined as void." + </li> +</ul> + +<p>The first of these passages suggests that "*i" is supposed to +return a useful value, which contradicts the note in 24.1.2/2 saying +that the only valid use of "*i" for output iterators is in an +expression of the form "*i = t". The second of these passages appears +to contradict Table 73, because it suggests that "*i"'s return value +should be void. The second passage is also broken in the case of a an +iterator type, like non-const pointers, that satisfies both the output +iterator requirements and the forward iterator requirements.</p> + +<p>What should the standard say about <tt>*i</tt>'s return value when +i is an output iterator, and what should it say about that t is in the +expression "*i = t"? Finally, should the standard say anything about +output iterators' pointer and reference types?</p> + + + +<p><b>Proposed resolution:</b></p> +<p>24.1 p1, change</p> + +<blockquote> +<p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting +in a value of some class, enumeration, or built-in type <tt>T</tt>, +called the value type of the iterator.</p> +</blockquote> + +<p>to</p> + +<blockquote> +<p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>, +resulting in a value of some class, enumeration, or built-in type +<tt>T</tt>, called the value type of the iterator. All output +iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a +value of some type that is in the set of types that are <i>writable</i> to +the particular iterator type of <tt>i</tt>. +</p> +</blockquote> + +<p>24.1 p9, add</p> + +<blockquote> +<p><tt>o</tt> denotes a value of some type that is writable to the +output iterator. +</p> +</blockquote> + +<p>Table 73, change</p> + +<blockquote> +<pre>*a = t +</pre> +</blockquote> + +<p>to</p> + +<blockquote> +<pre>*r = o +</pre> +</blockquote> + +<p>and change</p> + +<blockquote> +<pre>*r++ = t +</pre> +</blockquote> + +<p>to</p> + +<blockquote> +<pre>*r++ = o +</pre> +</blockquote> + +<p><i>[post-Redmond: Jeremy provided wording]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The LWG considered two options: change all of the language that +seems to imply that output iterators have value types, thus making it +clear that output iterators have no value types, or else define value +types for output iterator consistently. The LWG chose the former +option, because it seems clear that output iterators were never +intended to have value types. This was a deliberate design decision, +and any language suggesting otherwise is simply a mistake.</p> + +<p>A future revision of the standard may wish to revisit this design +decision.</p> + + + + + +<hr> +<h3><a name="325"></a>325. Misleading text in moneypunct<>::do_grouping</h3> +<p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The Returns clause in 22.2.6.3.2, p3 says about +moneypunct<charT>::do_grouping() +</p> + +<blockquote><p> + Returns: A pattern defined identically as the result of + numpunct<charT>::do_grouping().241) +</p></blockquote> + +<p>Footnote 241 then reads</p> + +<blockquote><p> + This is most commonly the value "\003" (not "3"). +</p></blockquote> + +<p> +The returns clause seems to imply that the two member functions must +return an identical value which in reality may or may not be true, +since the facets are usually implemented in terms of struct std::lconv +and return the value of the grouping and mon_grouping, respectively. +The footnote also implies that the member function of the moneypunct +facet (rather than the overridden virtual functions in moneypunct_byname) +most commonly return "\003", which contradicts the C standard which +specifies the value of "" for the (most common) C locale. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p> + +<blockquote><p> + Returns: A pattern defined identically as, but not necessarily + equal to, the result of numpunct<charT>::do_grouping().241) +</p></blockquote> + +<p>and replace the text in Footnote 241 with the following:</p> + +<blockquote><p> + To specify grouping by 3s the value is "\003", not "3". +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p> +The fundamental problem is that the description of the locale facet +virtuals serves two purposes: describing the behavior of the base +class, and describing the meaning of and constraints on the behavior +in arbitrary derived classes. The new wording makes that separation a +little bit clearer. The footnote (which is nonnormative) is not +supposed to say what the grouping is in the "C" locale or in any other +locale. It is just a reminder that the values are interpreted as small +integers, not ASCII characters. +</p> + + + + +<hr> +<h3><a name="327"></a>327. Typo in time_get facet in table 52</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#WP">WP</a> + <b>Submitter:</b> Tiki Wan <b>Date:</b> 2001-07-06</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#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#447">447</a></p> +<p><b>Discussion:</b></p> +<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and +<tt>time_get_byname</tt> are listed incorrectly in table 52, +required instantiations. In both cases the second template +parameter is given as OutputIterator. It should instead be +InputIterator, since these are input facets.</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In table 52, required instantiations, in +22.1.1.1.1 [locale.category], change</p> +<pre> time_get<wchar_t, OutputIterator> + time_get_byname<wchar_t, OutputIterator> +</pre> +<p>to</p> +<pre> time_get<wchar_t, InputIterator> + time_get_byname<wchar_t, InputIterator> +</pre> + +<p><i>[Redmond: Very minor change in proposed resolution. Original had +a typo, wchart instead of wchar_t.]</i></p> + + + + + + +<hr> +<h3><a name="328"></a>328. Bad sprintf format modifier in money_put<>::do_put()</h3> +<p><b>Section:</b> 22.2.6.2.2 [locale.money.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-07</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The sprintf format string , "%.01f" (that's the digit one), in the +description of the do_put() member functions of the money_put facet in +22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong +for values of type long double, and second, the precision of 01 +doesn't seem to make sense. What was most likely intended was +"%.0Lf"., that is a precision of zero followed by the L length +modifier.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the format string to "%.0Lf".</p> + + +<p><b>Rationale:</b></p><p>Fixes an obvious typo</p> + + + + +<hr> +<h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3> +<p><b>Section:</b> 23.2.6.2 [vector.capacity], 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-07-13</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +There is an apparent contradiction about which circumstances can cause +a reallocation of a vector in Section 23.2.6.2 [vector.capacity] and +section 23.2.6.4 [vector.modifiers]. +</p> + +<p>23.2.6.2 [vector.capacity],p5 says:</p> +<blockquote><p> +Notes: Reallocation invalidates all the references, pointers, and iterators +referring to the elements in the sequence. It is guaranteed that no +reallocation takes place during insertions that happen after a call to +reserve() until the time when an insertion would make the size of the vector +greater than the size specified in the most recent call to reserve(). +</p></blockquote> + +<p>Which implies if I do</p> + +<pre> std::vector<int> vec; + vec.reserve(23); + vec.reserve(0); + vec.insert(vec.end(),1); +</pre> + +<p>then the implementation may reallocate the vector for the insert, +as the size specified in the previous call to reserve was zero.</p> + +<p>However, the previous paragraphs (23.2.6.2 [vector.capacity], p1-2) state:</p> +<blockquote> +<p> +(capacity) Returns: The total number of elements the vector +can hold without requiring reallocation +</p> +<p> +...After reserve(), capacity() is greater or equal to the +argument of reserve if reallocation happens; and equal to the previous value +of capacity() otherwise... +</p> +</blockquote> + +<p> +This implies that vec.capacity() is still 23, and so the insert() +should not require a reallocation, as vec.size() is 0. This is backed +up by 23.2.6.4 [vector.modifiers], p1: +</p> +<blockquote><p> +(insert) Notes: Causes reallocation if the new size is greater than the old +capacity. +</p></blockquote> + +<p> +Though this doesn't rule out reallocation if the new size is less +than the old capacity, I think the intent is clear. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p>Change the wording of 23.2.6.2 [vector.capacity] paragraph 5 to:</p> + +<blockquote><p> +Notes: Reallocation invalidates all the references, pointers, and +iterators referring to the elements in the sequence. It is guaranteed +that no reallocation takes place during insertions that happen after a +call to reserve() until the time when an insertion would make the size +of the vector greater than the value of capacity(). +</p></blockquote> + +<p><i>[Redmond: original proposed resolution was modified slightly. In +the original, the guarantee was that there would be no reallocation +until the size would be greater than the value of capacity() after the +most recent call to reserve(). The LWG did not believe that the +"after the most recent call to reserve()" added any useful +information.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>There was general agreement that, when reserve() is called twice in +succession and the argument to the second invocation is smaller than +the argument to the first, the intent was for the second invocation to +have no effect. Wording implying that such cases have an effect on +reallocation guarantees was inadvertant.</p> + + + + + +<hr> +<h3><a name="331"></a>331. bad declaration of destructor for ios_base::failure</h3> +<p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +With the change in 17.4.4.9 [res.on.exception.handling] to state + "An implementation may strengthen the exception-specification for a + non-virtual function by removing listed exceptions." +(issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>) +and the following declaration of ~failure() in ios_base::failure +</p> +<pre> namespace std { + class ios_base::failure : public exception { + public: + ... + virtual ~failure(); + ... + }; + } +</pre> +<p>the class failure cannot be implemented since in 18.6.1 [type.info] the destructor of class exception has an empty +exception specification:</p> +<pre> namespace std { + class exception { + public: + ... + virtual ~exception() throw(); + ... + }; + } +</pre> + + +<p><b>Proposed resolution:</b></p> +<p>Remove the declaration of ~failure().</p> + + +<p><b>Rationale:</b></p> +<p>The proposed resolution is consistent with the way that destructors +of other classes derived from <tt>exception</tt> are handled.</p> + + + + + + + +<hr> +<h3><a name="333"></a>333. does endl imply synchronization with the device?</h3> +<p><b>Section:</b> 27.6.2.8 [ostream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>A footnote in 27.6.2.8 [ostream.manip] states:</p> +<blockquote><p> + [Footnote: The effect of executing cout << endl is to insert a + newline character in the output sequence controlled by cout, then + synchronize it with any external file with which it might be + associated. --- end foonote] +</p></blockquote> + +<p> +Does the term "file" here refer to the external device? +This leads to some implementation ambiguity on systems with fully +buffered files where a newline does not cause a flush to the device. +</p> + +<p> +Choosing to sync with the device leads to significant performance +penalties for each call to endl, while not sync-ing leads to +errors under special circumstances. +</p> + +<p> +I could not find any other statement that explicitly defined +the behavior one way or the other. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove footnote 300 from section 27.6.2.8 [ostream.manip].</p> + + +<p><b>Rationale:</b></p> +<p>We already have normative text saying what <tt>endl</tt> does: it +inserts a newline character and calls <tt>flush</tt>. This footnote +is at best redundant, at worst (as this issue says) misleading, +because it appears to make promises about what <tt>flush</tt> +does.</p> + + + + + + + +<hr> +<h3><a name="334"></a>334. map::operator[] specification forces inefficient implementation</h3> +<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Andrea Griffini <b>Date:</b> 2001-09-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current standard describes map::operator[] using a +code example. That code example is however quite +inefficient because it requires several useless copies +of both the passed key_type value and of default +constructed mapped_type instances. +My opinion is that was not meant by the comitee to +require all those temporary copies. +</p> + +<p>Currently map::operator[] behaviour is specified as: </p> +<pre> Returns: + (*((insert(make_pair(x, T()))).first)).second. +</pre> + +<p> +This specification however uses make_pair that is a +template function of which parameters in this case +will be deduced being of type const key_type& and +const T&. This will create a pair<key_type,T> that +isn't the correct type expected by map::insert so +another copy will be required using the template +conversion constructor available in pair to build +the required pair<const key_type,T> instance. +</p> + +<p>If we consider calling of key_type copy constructor +and mapped_type default constructor and copy +constructor as observable behaviour (as I think we +should) then the standard is in this place requiring +two copies of a key_type element plus a default +construction and two copy construction of a mapped_type +(supposing the addressed element is already present +in the map; otherwise at least another copy +construction for each type). +</p> + +<p>A simple (half) solution would be replacing the description with:</p> +<pre> Returns: + (*((insert(value_type(x, T()))).first)).second. +</pre> + +<p>This will remove the wrong typed pair construction that +requires one extra copy of both key and value.</p> + +<p>However still the using of map::insert requires temporary +objects while the operation, from a logical point of view, +doesn't require any. </p> + +<p>I think that a better solution would be leaving free an +implementer to use a different approach than map::insert +that, because of its interface, forces default constructed +temporaries and copies in this case. +The best solution in my opinion would be just requiring +map::operator[] to return a reference to the mapped_type +part of the contained element creating a default element +with the specified key if no such an element is already +present in the container. Also a logarithmic complexity +requirement should be specified for the operation. +</p> + +<p> +This would allow library implementers to write alternative +implementations not using map::insert and reaching optimal +performance in both cases of the addressed element being +present or absent from the map (no temporaries at all and +just the creation of a new pair inside the container if +the element isn't present). +Some implementer has already taken this option but I think +that the current wording of the standard rules that as +non-conforming. +</p> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Replace 23.3.1.2 [map.access] paragraph 1 with +</p> +<blockquote> +<p> +-1- Effects: If there is no key equivalent to x in the map, inserts +value_type(x, T()) into the map. +</p> +<p> +-2- Returns: A reference to the mapped_type corresponding to x in *this. +</p> +<p> +-3- Complexity: logarithmic. +</p> +</blockquote> + +<p><i>[This is the second option mentioned above. Howard provided +wording. We may also wish to have a blanket statement somewhere in +clause 17 saying that we do not intend the semantics of sample code +fragments to be interpreted as specifing exactly how many copies are +made. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a> for a similar problem.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p> +This is the second solution described above; as noted, it is +consistent with existing practice. +</p> + +<p>Note that we now need to specify the complexity explicitly, because +we are no longer defining <tt>operator[]</tt> in terms of +<tt>insert</tt>.</p> + + + + + +<hr> +<h3><a name="335"></a>335. minor issue with char_traits, table 37</h3> +<p><b>Section:</b> 21.1.1 [char.traits.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-09-06</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Table 37, in 21.1.1 [char.traits.require], descibes char_traits::assign +as: +</p> +<pre> X::assign(c,d) assigns c = d. +</pre> + +<p>And para 1 says:</p> + +<blockquote><p> + [...] c and d denote values of type CharT [...] +</p></blockquote> + +<p> +Naturally, if c and d are <i>values</i>, then the assignment is +(effectively) meaningless. It's clearly intended that (in the case of +assign, at least), 'c' is intended to be a reference type. +</p> + +<p>I did a quick survey of the four implementations I happened to have +lying around, and sure enough they all have signatures:</p> +<pre> assign( charT&, const charT& ); +</pre> + +<p>(or the equivalent). It's also described this way in Nico's book. +(Not to mention the synopses of char_traits<char> in 21.1.3.1 +and char_traits<wchar_t> in 21.1.3.2...) +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add the following to 21.1.1 para 1:</p> +<blockquote><p> + r denotes an lvalue of CharT +</p></blockquote> + +<p>and change the description of assign in the table to:</p> +<pre> X::assign(r,d) assigns r = d +</pre> + + + + + +<hr> +<h3><a name="336"></a>336. Clause 17 lack of references to deprecated headers</h3> +<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-05</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>From c++std-edit-873:</p> + +<p>17.4.1.2 [headers], Table 11. In this table, the header +<strstream> is missing.</p> + +<p>This shows a general problem: The whole clause 17 refers quite +often to clauses 18 through 27, but D.7 is also a part of the standard +library (though a deprecated one).</p> + + + +<p><b>Proposed resolution:</b></p> + +<p>To 17.4.1.2 [headers] Table 11, C++ Library Headers, add +"<strstream>".</p> + +<p>In the following places, change "clauses 17 through 27" to "clauses +17 through 27 and Annex D":</p> + +<ul> +<li>1.2 [intro.refs] Normative references/1/footnote 1</li> +<li>1.3 [intro.defs] Definitions/1</li> +<li>7 [dcl.dcl] Library introduction/9</li> +<li>17.3 [description] Method of description (Informative)/1</li> +<li>17.3.2.1.3 [character.seq] Character sequences/1/bullet 2</li> +<li>17.3.2.2 [functions.within.classes] Functions within classes/1</li> +<li>17.3.2.3 [objects.within.classes] Private members/1/(2 places)</li> +<li>17.4 [requirements] Library-wide requirements/1</li> +<li>17.4.1.2 [headers] Headers/4</li> +<li>17.4.3.5 [replacement.functions] Replacement functions/1</li> +<li>17.4.4.3 [global.functions] Global or non-member functions/2</li> +<li>17.4.4.7 [protection.within.classes] Protection within classes/1</li> +</ul> + + + + + + + +<hr> +<h3><a name="337"></a>337. replace_copy_if's template parameter should be InputIterator</h3> +<p><b>Section:</b> 25.2.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-07</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>From c++std-edit-876:</p> + +<p> +In section 25.2.5 [alg.replace] before p4: The name of the first +parameter of template replace_copy_if should be "InputIterator" +instead of "Iterator". According to 17.3.2.1 [type.descriptions] p1 the +parameter name conveys real normative meaning. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p> + + + + + +<hr> +<h3><a name="338"></a>338. is whitespace allowed between `-' and a digit?</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +From Stage 2 processing in 22.2.2.1.2 [facet.num.get.virtuals], p8 and 9 (the +original text or the text corrected by the proposed resolution of +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed +within a number, but 22.2.3.1 [locale.numpunct], p2, which gives the +format for integer and floating point values, says that whitespace is +optional between a plusminus and a sign. +</p> + +<p> +The text needs to be clarified to either consistently allow or +disallow whitespace between a plusminus and a sign. It might be +worthwhile to consider the fact that the C library stdio facility does +not permit whitespace embedded in numbers and neither does the C or +C++ core language (the syntax of integer-literals is given in 2.13.1 +[lex.icon], that of floating-point-literals in 2.13.3 [lex.fcon] of the +C++ standard). +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the first part of 22.2.3.1 [locale.numpunct] paragraph 2 from:</p> +<blockquote> +<p> +The syntax for number formats is as follows, where <tt>digit</tt> +represents the radix set specified by the <tt>fmtflags</tt> argument +value, <tt>whitespace</tt> is as determined by the facet +<tt>ctype<charT></tt> (22.2.1.1), and <tt>thousands-sep</tt> and +<tt>decimal-point</tt> are the results of corresponding +<tt>numpunct<charT></tt> members. Integer values have the +format: +</p> +<pre> integer ::= [sign] units + sign ::= plusminus [whitespace] + plusminus ::= '+' | '-' + units ::= digits [thousands-sep units] + digits ::= digit [digits] +</pre> +</blockquote> +<p>to:</p> +<blockquote> +<p> +The syntax for number formats is as follows, where <tt>digit</tt> +represents the radix set specified by the <tt>fmtflags</tt> argument +value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the +results of corresponding <tt>numpunct<charT></tt> members. +Integer values have the format: +</p> +<pre> integer ::= [sign] units + sign ::= plusminus + plusminus ::= '+' | '-' + units ::= digits [thousands-sep units] + digits ::= digit [digits] +</pre> +</blockquote> + + +<p><b>Rationale:</b></p> +<p>It's not clear whether the format described in 22.2.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the +standard says how, or whether, it's used. However, there's no reason +for it to differ gratuitously from the very specific description of +numeric processing in 22.2.2.1.2 [facet.num.get.virtuals]. The proposed +resolution removes all mention of "whitespace" from that format.</p> + + + + + +<hr> +<h3><a name="339"></a>339. definition of bitmask type restricted to clause 27</h3> +<p><b>Section:</b> 22.2.1 [category.ctype], 17.3.2.1.2 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>The ctype_category::mask type is declared to be an enum in 22.2.1 +[category.ctype] with p1 then stating that it is a bitmask type, most +likely referring to the definition of bitmask type in 17.3.2.1.2 +[bitmask.types], p1. However, the said definition only applies to +clause 27, making the reference in 22.2.1 somewhat dubious. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Clarify 17.3.2.1.2, p1 by changing the current text from</p> + <blockquote><p> + Several types defined in clause 27 are bitmask types. Each bitmask type + can be implemented as an enumerated type that overloads certain operators, + as an integer type, or as a bitset (23.3.5 [template.bitset]). + </p></blockquote> +<p>to read</p> + <blockquote><p> + Several types defined in clauses lib.language.support through + lib.input.output and Annex D are bitmask types. Each bitmask type can + be implemented as an enumerated type that overloads certain operators, + as an integer type, or as a bitset (lib.template.bitset). + </p></blockquote> + +<p> +Additionally, change the definition in 22.2.1 to adopt the same +convention as in clause 27 by replacing the existing text with the +following (note, in particluar, the cross-reference to 17.3.2.1.2 in +22.2.1, p1): +</p> + +<blockquote> +<p>22.2.1 The ctype category [lib.category.ctype]</p> +<pre>namespace std { + class ctype_base { + public: + typedef <b><i>T</i></b> mask; + + // numeric values are for exposition only. + static const mask space = 1 << 0; + static const mask print = 1 << 1; + static const mask cntrl = 1 << 2; + static const mask upper = 1 << 3; + static const mask lower = 1 << 4; + static const mask alpha = 1 << 5; + static const mask digit = 1 << 6; + static const mask punct = 1 << 7; + static const mask xdigit = 1 << 8; + static const mask alnum = alpha | digit; + static const mask graph = alnum | punct; + }; +} +</pre> + +<p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 [bitmask.types]).</p> +</blockquote> + +<p><i>[Curaçao: The LWG notes that T above should be bold-italics to be +consistent with the rest of the standard.]</i></p> + + + + + + + + + +<hr> +<h3><a name="340"></a>340. interpretation of <tt>has_facet<Facet>(loc)</tt></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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-18</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It's unclear whether 22.1.1.1.1, p3 says that +<tt>has_facet<Facet>(loc)</tt> returns true for any <tt>Facet</tt> +from Table 51 or whether it includes Table 52 as well: +</p> + +<blockquote><p> +For any locale <tt>loc</tt> either constructed, or returned by +locale::classic(), and any facet <tt>Facet</tt> that is a member of a +standard category, <tt>has_facet<Facet>(loc)</tt> is true. Each +locale member function which takes a <tt>locale::category</tt> +argument operates on the corresponding set of facets. +</p></blockquote> + +<p> +It seems that it comes down to which facets are considered to be members of a +standard category. Intuitively, I would classify all the facets in Table 52 as +members of their respective standard categories, but there are an unbounded set +of them... +</p> + +<p> +The paragraph implies that, for instance, <tt>has_facet<num_put<C, +OutputIterator> >(loc)</tt> must always return true. I don't think that's +possible. If it were, then <tt>use_facet<num_put<C, OutputIterator> +>(loc)</tt> would have to return a reference to a distinct object for each +valid specialization of <tt>num_put<C, OutputIteratory></tt>, which is +clearly impossible. +</p> + +<p> +On the other hand, if none of the facets in Table 52 is a member of a standard +category then none of the locale member functions that operate on entire +categories of facets will work properly. +</p> + +<p> +It seems that what p3 should mention that it's required (permitted?) +to hold only for specializations of <tt>Facet</tt> from Table 52 on +<tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and +<tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of +{ +{i,o}<tt>streambuf_iterator</tt><{<tt>char</tt>,<tt>wchar_t</tt>}<tt>></tt> +}. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.1.1.1.1 [locale.category], paragraph 3, change +"that is a member of a standard category" to "shown in Table 51".</p> + + +<p><b>Rationale:</b></p> +<p>The facets in Table 52 are an unbounded set. Locales should not be +required to contain an infinite number of facets.</p> + +<p>It's not necessary to talk about which values of InputIterator and +OutputIterator must be supported. Table 51 already contains a +complete list of the ones we need.</p> + + + + + + +<hr> +<h3><a name="341"></a>341. Vector reallocation and swap</h3> +<p><b>Section:</b> 23.2.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-09-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>It is a common idiom to reduce the capacity of a vector by swapping it with +an empty one:</p> +<pre> std::vector<SomeType> vec; + // fill vec with data + std::vector<SomeType>().swap(vec); + // vec is now empty, with minimal capacity +</pre> + +<p>However, the wording of 23.2.6.2 [vector.capacity]paragraph 5 prevents +the capacity of a vector being reduced, following a call to +reserve(). This invalidates the idiom, as swap() is thus prevented +from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this. Consequently, the example above +requires the temporary to be expanded to cater for the contents of +vec, and the contents be copied across. This is a linear-time +operation.</p> + +<p>However, the container requirements state that swap must have constant +complexity (23.1 [container.requirements] note to table 65).</p> + +<p>This is an important issue, as reallocation affects the validity of +references and iterators.</p> + +<p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then +references and iterators remain valid after a call to swap, if they refer to +an element before the new end() of the vector into which they originally +pointed, in which case they refer to the element at the same index position. +Iterators and references that referred to an element whose index position +was beyond the new end of the vector are invalidated.</p> + +<p>If the note to table 65 is taken as the desired intent, then there are two +possibilities with regard to iterators and references:</p> + +<ol> +<li>All Iterators and references into both vectors are invalidated.</li> +<li>Iterators and references into either vector remain valid, and remain +pointing to the same element. Consequently iterators and references that +referred to one vector now refer to the other, and vice-versa.</li> +</ol> + + +<p><b>Proposed resolution:</b></p> +<p>Add a new paragraph after 23.2.6.2 [vector.capacity] paragraph 5:</p> +<blockquote> +<pre> void swap(vector<T,Allocator>& x); +</pre> +<p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt> +with that of <tt>x</tt>.</p> +<p><b>Complexity:</b> Constant time.</p> +</blockquote> + +<p><i>[This solves the problem reported for this issue. We may also +have a problem with a circular definition of swap() for other +containers.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p> +swap should be constant time. The clear intent is that it should just +do pointer twiddling, and that it should exchange all properties of +the two vectors, including their reallocation guarantees. +</p> + + + + + +<hr> +<h3><a name="345"></a>345. type tm in <cwchar></h3> +<p><b>Section:</b> 21.5 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Clark Nelson <b>Date:</b> 2001-10-19</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>C99, and presumably amendment 1 to C90, specify that <wchar.h> +declares struct tm as an incomplete type. However, table 48 in 21.5 +[c.strings] does not mention the type tm as being declared in +<cwchar>. Is this omission intentional or accidental? +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In section 21.5 [c.strings], add "tm" to table 48.</p> + + + + + +<hr> +<h3><a name="346"></a>346. Some iterator member functions should be const</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#WP">WP</a> + <b>Submitter:</b> Jeremy Siek <b>Date:</b> 2001-10-20</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Iterator member functions and operators that do not change the state +of the iterator should be defined as const member functions or as +functions that take iterators either by const reference or by +value. The standard does not explicitly state which functions should +be const. Since this a fairly common mistake, the following changes +are suggested to make this explicit.</p> + +<p>The tables almost indicate constness properly through naming: r +for non-const and a,b for const iterators. The following changes +make this more explicit and also fix a couple problems.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 24.1 [iterator.requirements] Change the first section of p9 from +"In the following sections, a and b denote values of X..." to +"In the following sections, a and b denote values of type const X...".</p> + +<p>In Table 73, change</p> +<pre> a->m U& ... +</pre> + +<p>to</p> + +<pre> a->m const U& ... + r->m U& ... +</pre> + +<p>In Table 73 expression column, change</p> + +<pre> *a = t +</pre> + +<p>to</p> + +<pre> *r = t +</pre> + +<p><i>[Redmond: The container requirements should be reviewed to see if +the same problem appears there.]</i></p> + + + + + + + +<hr> +<h3><a name="347"></a>347. locale::category and bitmask requirements</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#WP">WP</a> + <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Date:</b> 2001-10-23</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 22.1.1.1.1 [locale.category] paragraph 1, the category members +are described as bitmask elements. In fact, the bitmask requirements +in 17.3.2.1.2 [bitmask.types] don't seem quite right: <tt>none</tt> +and <tt>all</tt> are bitmask constants, not bitmask elements.</p> + +<p>In particular, the requirements for <tt>none</tt> interact poorly +with the requirement that the LC_* constants from the C library must +be recognizable as C++ locale category constants. LC_* values should +not be mixed with these values to make category values.</p> + +<p>We have two options for the proposed resolution. Informally: +option 1 removes the requirement that LC_* values be recognized as +category arguments. Option 2 changes the category type so that this +requirement is implementable, by allowing <tt>none</tt> to be some +value such as 0x1000 instead of 0.</p> + +<p>Nathan writes: "I believe my proposed resolution [Option 2] merely +re-expresses the status quo more clearly, without introducing any +changes beyond resolving the DR.</p> + + + +<p><b>Proposed resolution:</b></p> +<p>Replace the first two paragraphs of 22.1.1.1 [locale.types] with:</p> +<blockquote> +<pre> typedef int category; +</pre> + +<p>Valid category values include the <tt>locale</tt> member bitmask +elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>, +<tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which +represents a single locale category. In addition, <tt>locale</tt> member +bitmask constant <tt>none</tt> is defined as zero and represents no +category. And locale member bitmask constant <tt>all</tt> is defined such that +the expression</p> +<pre> (collate | ctype | monetary | numeric | time | messages | all) == all +</pre> +<p> +is <tt>true</tt>, and represents the union of all categories. Further +the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each +represent a single category, represents the union of the two +categories. +</p> + +<p> +<tt>locale</tt> member functions expecting a <tt>category</tt> +argument require one of the <tt>category</tt> values defined above, or +the union of two or more such values. Such a <tt>category</tt> +argument identifies a set of locale categories. Each locale category, +in turn, identifies a set of locale facets, including at least those +shown in Table 51: +</p> +</blockquote> +<p><i>[Curaçao: need input from locale experts.]</i></p> + + + + +<p><b>Rationale:</b></p> + +<p>The LWG considered, and rejected, an alternate proposal (described + as "Option 2" in the discussion). The main reason for rejecting it + was that library implementors were concerened about implementation + difficult, given that getting a C++ library to work smoothly with a + separately written C library is already a delicate business. Some + library implementers were also concerned about the issue of adding + extra locale categories.</p> + +<blockquote> +<p><b>Option 2:</b> <br> +Replace the first paragraph of 22.1.1.1 [locale.types] with:</p> +<blockquote> +<p> +Valid category values include the enumerated values. In addition, the +result of applying commutative operators | and & to any two valid +values is valid, and results in the setwise union and intersection, +respectively, of the argument categories. The values <tt>all</tt> and +<tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the +expressions <tt>(cat | all == all)</tt>, <tt>(cat & all == cat)</tt>, +<tt>(cat | none == cat)</tt> and <tt>(cat & none == none)</tt> are +true. For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the +remaining enumerated values, <tt>(cat1 & cat2 == none)</tt> is true. +For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result +of <tt>(cat1 & ~cat2)</tt> is valid, and equals the setwise union of +those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>. +[Footnote: it is not required that <tt>all</tt> equal the setwise union +of the other enumerated values; implementations may add extra categories.] +</p> +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="349"></a>349. Minor typographical error in ostream_iterator</h3> +<p><b>Section:</b> 24.5.2 [ostream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-24</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>24.5.2 [lib.ostream.iterator] states:</p> +<pre> [...] + + private: + // basic_ostream<charT,traits>* out_stream; exposition only + // const char* delim; exposition only +</pre> + +<p>Whilst it's clearly marked "exposition only", I suspect 'delim' +should be of type 'const charT*'.</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 24.5.2 [ostream.iterator], replace <tt>const char* delim</tt> with +<tt>const charT* delim</tt>. +</p> + + + + + +<hr> +<h3><a name="352"></a>352. missing fpos requirements</h3> +<p><b>Section:</b> 21.1.2 [char.traits.typedefs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<i>(1)</i> +There are no requirements on the <tt>stateT</tt> template parameter of +<tt>fpos</tt> listed in 27.4.3. The interface appears to require that +the type be at least Assignable and CopyConstructible (27.4.3.1, p1), +and I think also DefaultConstructible (to implement the operations in +Table 88). +</p> +<p> +21.1.2, p3, however, only requires that +<tt>char_traits<charT>::state_type</tt> meet the requirements of +CopyConstructible types. +</p> +<p> +<i>(2)</i> +Additionally, the <tt>stateT</tt> template argument has no +corresponding typedef in fpos which might make it difficult to use in +generic code. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Modify 21.1.2, p4 from +</p> +<p> + Requires: <tt>state_type</tt> shall meet the requirements of + CopyConstructible types (20.1.3). +</p> +<p> + Requires: state_type shall meet the requirements of Assignable + (23.1, p4), CopyConstructible (20.1.3), and + DefaultConstructible (20.1.4) types. +</p> + + + +<p><b>Rationale:</b></p> +<p>The LWG feels this is two issues, as indicated above. The first is +a defect---std::basic_fstream is unimplementable without these +additional requirements---and the proposed resolution fixes it. The +second is questionable; who would use that typedef? The class +template fpos is used only in a very few places, all of which know the +state type already. Unless motivation is provided, the second should +be considered NAD.</p> + + + + + +<hr> +<h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Hans Aberg <b>Date:</b> 2001-12-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Discussions in the thread "Associative container lower/upper bound +requirements" on comp.std.c++ suggests that there is a defect in the +C++ standard, Table 69 of section 23.1.2, "Associative containers", +[lib.associative.reqmts]. It currently says:</p> + +<blockquote> +<p> +a.find(k): returns an iterator pointing to an element with the key equivalent to +k, or a.end() if such an element is not found. +</p> + +<p> +a.lower_bound(k): returns an iterator pointing to the first element with +key not less than k. +</p> + +<p> +a.upper_bound(k): returns an iterator pointing to the first element with +key greater than k. +</p> +</blockquote> + +<p> +We have "or a.end() if such an element is not found" for +<tt>find</tt>, but not for <tt>upper_bound</tt> or +<tt>lower_bound</tt>. As the text stands, one would be forced to +insert a new element into the container and return an iterator to that +in case the sought iterator does not exist, which does not seem to be +the intention (and not possible with the "const" versions). +</p> + + +<p><b>Proposed resolution:</b></p> + +<p>Change Table 69 of section 23.1.4 [associative.reqmts] indicated entries +to:</p> + +<blockquote> +<p> +a.lower_bound(k): returns an iterator pointing to the first element with +key not less than k, or a.end() if such an element is not found. +</p> + +<p> +a.upper_bound(k): returns an iterator pointing to the first element with +key greater than k, or a.end() if such an element is not found. +</p> +</blockquote> + +<p><i>[Curaçao: LWG reviewed PR.]</i></p> + + + + + + + + +<hr> +<h3><a name="355"></a>355. Operational semantics for a.back()</h3> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 2002-01-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>Table 68 "Optional Sequence Operations" in 23.1.1/12 +specifies operational semantics for "a.back()" as +"*--a.end()", which may be ill-formed <i>[because calling +operator-- on a temporary (the return) of a built-in type is +ill-formed]</i>, provided a.end() returns a simple pointer rvalue +(this is almost always the case for std::vector::end(), for +example). Thus, the specification is not only incorrect, it +demonstrates a dangerous construct: "--a.end()" may +successfully compile and run as intended, but after changing the type +of the container or the mode of compilation it may produce +compile-time error. </p> + + + +<p><b>Proposed resolution:</b></p> +<p>Change the specification in table 68 "Optional Sequence +Operations" in 23.1.1/12 for "a.back()" from</p> + + +<blockquote><pre>*--a.end() +</pre></blockquote> + +<p>to</p> + +<blockquote><pre> { iterator tmp = a.end(); --tmp; return *tmp; } +</pre></blockquote> + +<p>and the specification for "a.pop_back()" from</p> + +<blockquote><pre>a.erase(--a.end()) +</pre></blockquote> + +<p>to</p> + +<blockquote><pre> { iterator tmp = a.end(); --tmp; a.erase(tmp); } +</pre></blockquote> + +<p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp = +a.end(); return *--tmp; }" to "*a.rbegin()", and from +"{ X::iterator tmp = a.end(); a.erase(--tmp); }" to +"a.erase(rbegin())".]</i></p> + + +<p><i>[There is a second possible defect; table 68 "Optional +Sequence Operations" in the "Operational Semantics" +column uses operations present only in the "Reversible +Container" requirements, yet there is no stated dependency +between these separate requirements tables. Ask in Santa Cruz if the +LWG would like a new issue opened.]</i></p> + + +<p><i>[Santa Cruz: the proposed resolution is even worse than what's in + the current standard: erase is undefined for reverse iterator. If + we're going to make the change, we need to define a temporary and + use operator--. Additionally, we don't know how prevalent this is: + do we need to make this change in more than one place? Martin has + volunteered to review the standard and see if this problem occurs + elsewhere.]</i></p> + + +<p><i>[Oxford: Matt provided new wording to address the concerns raised + in Santa Cruz. It does not appear that this problem appears + anywhere else in clauses 23 or 24.]</i></p> + + +<p><i>[Kona: In definition of operational semantics of back(), change +"*tmp" to "return *tmp;"]</i></p> + + + + + + + +<hr> +<h3><a name="358"></a>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt></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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I don't think <tt>thousands_sep</tt> is being treated correctly after +decimal_point has been seen. Since grouping applies only to the +integral part of the number, the first such occurrence should, IMO, +terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12 +and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be +interpreted in the fractional part of a number.) +</p> + +<p> +The easiest change I can think of that resolves this issue would be +something like below. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the first sentence of 22.2.2.1.2, p9 from +</p> + +<blockquote><p> + If discard is true then the position of the character is + remembered, but the character is otherwise ignored. If it is not + discarded, then a check is made to determine if c is allowed as + the next character of an input field of the conversion specifier + returned by stage 1. If so it is accumulated. +</p></blockquote> + +<p>to</p> + +<blockquote><p> + If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been + accumulated, then the position of the character is remembered, but + the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has + already been accumulated, the character is discarded and Stage 2 + terminates. ... +</p></blockquote> + + + +<p><b>Rationale:</b></p> +<p>We believe this reflects the intent of the Standard. Thousands sep + characters after the decimal point are not useful in any locale. + Some formatting conventions do group digits that follow the decimal + point, but they usually introduce a different grouping character + instead of reusing the thousand sep character. If we want to add + support for such conventions, we need to do so explicitly.</p> + + + + + + +<hr> +<h3><a name="359"></a>359. num_put<>::do_put (..., bool) undocumented</h3> +<p><b>Section:</b> 22.2.2.2.1 [facet.num.put.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>22.2.2.2.1, p1:</p> + + <pre> iter_type put (iter_type out, ios_base& str, char_type fill, + bool val) const; + ... + + 1 Returns: do_put (out, str, fill, val). + </pre> + +<p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere, +however, 22.2.2.2.2, p23:</p> + +<blockquote> +<pre>iter_type put (iter_type out, ios_base& str, char_type fill, + bool val) const; +</pre> + + + <p>Effects: If (str.flags() & ios_base::boolalpha) == 0 then do + out = do_put(out, str, fill, (int)val) + Otherwise do</p> +<pre> string_type s = + val ? use_facet<ctype<charT> >(loc).truename() + : use_facet<ctype<charT> >(loc).falsename(); +</pre> + <p>and then insert the characters of s into out. <i>out</i>.</p> +</blockquote> + +<p> +This means that the bool overload of <tt>do_put()</tt> will never be called, +which contradicts the first paragraph. Perhaps the declaration +should read <tt>do_put()</tt>, and not <tt>put()</tt>? +</p> + +<p> +Note also that there is no <b>Returns</b> clause for this function, which +should probably be corrected, just as should the second occurrence +of <i>"out."</i> in the text. +</p> + +<p> +I think the least invasive change to fix it would be something like +the following: +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.2.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove + the <tt>bool</tt> overload.</p> + +<p> +In 22.2.2.2.2 [facet.num.put.virtuals], p23, make the following changes +</p> + +<blockquote><p> + Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration + of the member function. +</p></blockquote> + +<blockquote><p> + Change the <b>Effects</b> clause to a <b>Returns</b> clause (to + avoid the requirement to call <tt>do_put(..., int)</tt> from <tt> + do_put (..., bool))</tt> + like so: +</p></blockquote> + +<blockquote><p> + 23 <b>Returns</b>: If <tt>(str.flags() & + ios_base::boolalpha) == 0</tt> then + <tt>do_put (out, str, fill, (long)val)</tt> + Otherwise the function obtains a string <tt>s</tt> as if by</p> +<pre> string_type s = + val ? use_facet<ctype<charT> >(loc).truename() + : use_facet<ctype<charT> >(loc).falsename(); +</pre> + <p>and then inserts each character <tt>c</tt> of s into out via + <tt>*out++ = c</tt> + and returns <tt>out</tt>.</p> +</blockquote> + + + +<p><b>Rationale:</b></p><p> +This fixes a couple of obvious typos, and also fixes what appears to +be a requirement of gratuitous inefficiency. +</p> + + + + +<hr> +<h3><a name="360"></a>360. locale mandates inefficient implementation</h3> +<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +22.1.1, p7 (copied below) allows iostream formatters and extractors +to make assumptions about the values returned from facet members. +However, such assumptions are apparently not guaranteed to hold +in other cases (e.g., when the facet members are being called directly +rather than as a result of iostream calls, or between successive +calls to the same iostream functions with no interevening calls to +<tt>imbue()</tt>, or even when the facet member functions are called +from other member functions of other facets). This restriction +prevents locale from being implemented efficiently. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the first sentence in 22.1.1, p7 from</p> +<blockquote><p> + In successive calls to a locale facet member function during + a call to an iostream inserter or extractor or a streambuf member + function, the returned result shall be identical. [Note: This + implies that such results may safely be reused without calling + the locale facet member function again, and that member functions + of iostream classes cannot safely call <tt>imbue()</tt> + themselves, except as specified elsewhere. --end note] +</p></blockquote> + +<p>to</p> + +<blockquote><p> + In successive calls to a locale facet member function on a facet + object installed in the same locale, the returned result shall be + identical. ... +</p></blockquote> + + + +<p><b>Rationale:</b></p> +<p>This change is reasonable becuase it clarifies the intent of this + part of the standard.</p> + + + + + +<hr> +<h3><a name="362"></a>362. bind1st/bind2nd type safety</h3> +<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Andrew Demkin <b>Date:</b> 2002-04-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The definition of bind1st() (D.8 [depr.lib.binders]) can result in +the construction of an unsafe binding between incompatible pointer +types. For example, given a function whose first parameter type is +'pointer to T', it's possible without error to bind an argument of +type 'pointer to U' when U does not derive from T: +</p> +<pre> foo(T*, int); + + struct T {}; + struct U {}; + + U u; + + int* p; + int* q; + + for_each(p, q, bind1st(ptr_fun(foo), &u)); // unsafe binding +</pre> + +<p> +The definition of bind1st() includes a functional-style conversion to +map its argument to the expected argument type of the bound function +(see below): +</p> +<pre> typename Operation::first_argument_type(x) +</pre> + +<p>A functional-style conversion (D.8 [depr.lib.binders]) is defined to +be +semantically equivalent to an explicit cast expression (D.8 +[depr.lib.binders]), which may (according to 5.4, paragraph 5) be +interpreted +as a reinterpret_cast, thus masking the error. +</p> + +<p>The problem and proposed change also apply to D.8 [depr.lib.binders].</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add this sentence to the end of D.8 [depr.lib.binders]/1: + "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in + favor of <tt>std::tr1::bind</tt>."</p> + +<p>(Notes to editor: (1) when and if tr1::bind is incorporated into + the standard, "std::tr1::bind" should be changed to "std::bind". (2) + 20.5.6 should probably be moved to Annex D.</p> + + +<p><b>Rationale:</b></p> +<p>There is no point in fixing bind1st and bind2nd. tr1::bind is a + superior solution. It solves this problem and others.</p> + + + + + +<hr> +<h3><a name="363"></a>363. Missing exception specification in 27.4.2.1.1</h3> +<p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Walter Brown and Marc Paterno <b>Date:</b> 2002-05-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The destructor of ios_base::failure should have an empty throw +specification, because the destructor of its base class, exception, is +declared in this way. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change the destructor to</p> +<pre> virtual ~failure() throw(); +</pre> + + +<p><b>Rationale:</b></p> +<p>Fixes an obvious glitch. This is almost editorial.</p> + + + + + +<hr> +<h3><a name="364"></a>364. Inconsistent wording in 27.5.2.4.2</h3> +<p><b>Section:</b> 27.5.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +27.5.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects +clause for seekoff. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Make this paragraph, the Effects clause for setbuf, consistent in wording +with the Effects clause for seekoff in paragraph 3 by amending paragraph 1 +to indicate the purpose of setbuf: +</p> + +<p>Original text:</p> + +<blockquote><p> +1 Effects: Performs an operation that is defined separately for each +class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4). +</p></blockquote> + +<p>Proposed text:</p> + +<blockquote><p> +1 Effects: Influences stream buffering in a way that is defined separately +for each class derived from basic_streambuf in this clause +(27.7.1.3, 27.8.1.4). +</p></blockquote> + + + +<p><b>Rationale:</b></p> +<p>The LWG doesn't believe there is any normative difference between + the existing wording and what's in the proposed resolution, but the + change may make the intent clearer.</p> + + + + + +<hr> +<h3><a name="365"></a>365. Lack of const-qualification in clause 27</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#WP">WP</a> + <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Some stream and streambuf member functions are declared non-const, +even thought they appear only to report information rather than to +change an object's logical state. They should be declared const. See +document N1360 for details and rationale. +</p> + +<p>The list of member functions under discussion: <tt>in_avail</tt>, +<tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p> + +<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p> + + + +<p><b>Proposed resolution:</b></p> +<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p> +<p>Replace</p> +<pre> bool is_open(); +</pre> +<p>with</p> +<pre> bool is_open() const; +</pre> + + +<p><b>Rationale:</b></p> +<p>Of the changes proposed in N1360, the only one that is safe is +changing the filestreams' is_open to const. The LWG believed that +this was NAD the first time it considered this issue (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a>), but now thinks otherwise. The corresponding streambuf +member function, after all,is already const.</p> + +<p>The other proposed changes are less safe, because some streambuf +functions that appear merely to report a value do actually perform +mutating operations. It's not even clear that they should be +considered "logically const", because streambuf has two interfaces, a +public one and a protected one. These functions may, and often do, +change the state as exposed by the protected interface, even if the +state exposed by the public interface is unchanged.</p> + +<p>Note that implementers can make this change in a binary compatible +way by providing both overloads; this would be a conforming extension.</p> + + + + + + +<hr> +<h3><a name="369"></a>369. io stream objects and static ctors</h3> +<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 2002-07-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Is it safe to use standard iostream objects from constructors of +static objects? Are standard iostream objects constructed and are +their associations established at that time? +</p> + +<p>Surpisingly enough, Standard does NOT require that.</p> + +<p> +27.3/2 [lib.iostream.objects] guarantees that standard iostream +objects are constructed and their associations are established before +the body of main() begins execution. It also refers to ios_base::Init +class as the panacea for constructors of static objects. +</p> + +<p> +However, there's nothing in 27.3 [lib.iostream.objects], +in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init], +that would require implementations to allow access to standard +iostream objects from constructors of static objects. +</p> + +<p>Details:</p> + +<p>Core text refers to some magic object ios_base::Init, which will +be discussed below:</p> + +<blockquote><p> + "The [standard iostream] objects are constructed, and their + associations are established at some time prior to or during + first time an object of class basic_ios<charT,traits>::Init + is constructed, and in any case before the body of main + begins execution." (27.3/2 [lib.iostream.objects]) +</p></blockquote> + +<p> +The first <i>non-normative</i> footnote encourages implementations +to initialize standard iostream objects earlier than required. +</p> + +<p>However, the second <i>non-normative</i> footnote makes an explicit +and unsupported claim:</p> + +<blockquote><p> + "Constructors and destructors for static objects can access these + [standard iostream] objects to read input from stdin or write output + to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects]) +</p></blockquote> + +<p> +The only bit of magic is related to that ios_base::Init class. AFAIK, +the rationale behind ios_base::Init was to bring an instance of this +class to each translation unit which #included <iostream> or +related header. Such an inclusion would support the claim of footnote +quoted above, because in order to use some standard iostream object it +is necessary to #include <iostream>. +</p> + +<p> +However, while Standard explicitly describes ios_base::Init as +an appropriate class for doing the trick, I failed to found a +mention of an _instance_ of ios_base::Init in Standard. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p>Add to 27.3 [iostream.objects], p2, immediately before the last sentence +of the paragraph, the following two sentences:</p> + +<blockquote><p> +If a translation unit includes <iostream>, or explicitly +constructs an ios_base::Init object, these stream objects shall +be constructed before dynamic initialization of non-local +objects defined later in that translation unit, and these stream +objects shall be destroyed after the destruction of dynamically +initialized non-local objects defined later in that translation unit. +</p></blockquote> + +<p><i>[Lillehammer: Matt provided wording.]</i></p> + +<p><i>[Mont Tremblant: Matt provided revised wording.]</i></p> + + + +<p><b>Rationale:</b></p> +<p> +The original proposed resolution unconditionally required +implementations to define an ios_base::Init object of some +implementation-defined name in the header <iostream>. That's an +overspecification. First, defining the object may be unnecessary +and even detrimental to performance if an implementation can +guarantee that the 8 standard iostream objects will be initialized +before any other user-defined object in a program. Second, there +is no need to require implementations to document the name of the +object.</p> + +<p> +The new proposed resolution gives users guidance on what they need to +do to ensure that stream objects are constructed during startup.</p> + + + + + +<hr> +<h3><a name="370"></a>370. Minor error in basic_istream::get</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#WP">WP</a> + <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-07-15</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Defect report for description of basic_istream::get (section +27.6.1.3 [istream.unformatted]), paragraph 15. The description for the +get function +with the following signature:</p> + +<pre> basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>& + sb); +</pre> + +<p>is incorrect. It reads</p> + +<blockquote><p> + Effects: Calls get(s,n,widen('\n')) +</p></blockquote> + +<p>which I believe should be:</p> + +<blockquote><p> + Effects: Calls get(sb,widen('\n')) +</p></blockquote> + + +<p><b>Proposed resolution:</b></p> +<p>Change the <b>Effects</b> paragraph to:</p> +<blockquote><p> + Effects: Calls get(sb,this->widen('\n')) +</p></blockquote> + +<p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen' + with 'this->widen'.]</i></p> + + + + +<p><b>Rationale:</b></p><p>Fixes an obvious typo.</p> + + + + +<hr> +<h3><a name="371"></a>371. Stability of multiset and multimap member functions</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#WP">WP</a> + <b>Submitter:</b> Frank Compagner <b>Date:</b> 2002-07-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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The requirements for multiset and multimap containers (23.1 +[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts], +23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of +the stability of the required (mutating) member functions. It appears +the standard allows these functions to reorder equivalent elements of +the container at will, yet the pervasive red-black tree implementation +appears to provide stable behaviour. +</p> + +<p>This is of most concern when considering the behaviour of erase(). +A stability requirement would guarantee the correct working of the +following 'idiom' that removes elements based on a certain predicate +function. +</p> + +<pre> multimap<int, int> m; + multimap<int, int>::iterator i = m.begin(); + while (i != m.end()) { + if (pred(i)) + m.erase (i++); + else + ++i; + } +</pre> + +<p> +Although clause 23.1.2/8 guarantees that i remains a valid iterator +througout this loop, absence of the stability requirement could +potentially result in elements being skipped. This would make +this code incorrect, and, furthermore, means that there is no way +of erasing these elements without iterating first over the entire +container, and second over the elements to be erased. This would +be unfortunate, and have a negative impact on both performance and +code simplicity. +</p> + +<p> +If the stability requirement is intended, it should be made explicit +(probably through an extra paragraph in clause 23.1.2). +</p> +<p> +If it turns out stability cannot be guaranteed, i'd argue that a +remark or footnote is called for (also somewhere in clause 23.1.2) to +warn against relying on stable behaviour (as demonstrated by the code +above). If most implementations will display stable behaviour, any +problems emerging on an implementation without stable behaviour will +be hard to track down by users. This would also make the need for an +erase_if() member function that much greater. +</p> + +<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p> + + + +<p><b>Proposed resolution:</b></p> + +<p>Add the following to the end of 23.1.4 [associative.reqmts] paragraph 4: +"For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt> + are <i>stable</i>: they preserve the relative ordering of equivalent + elements.</p> + +<p><i>[Lillehammer: Matt provided wording]</i></p> + +<p><i>[Joe Gottman points out that the provided wording does not address +multimap and multiset. N1780 also addresses this issue and suggests +wording.]</i></p> + + +<p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The LWG agrees that this guarantee is necessary for common user + idioms to work, and that all existing implementations provide this + property. Note that this resolution guarantees stability for + multimap and multiset, not for all associative containers in + general.</p> + + + + + + +<hr> +<h3><a name="373"></a>373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?</h3> +<p><b>Section:</b> 27.6.1.2.1 [istream.formatted.reqmts], 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#WP">WP</a> + <b>Submitter:</b> Keith Baker <b>Date:</b> 2002-07-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts] +(exception()&badbit) != 0 is used in testing for rethrow, yet +exception() is the constructor to class std::exception in 18.6.1 [type.info] that has no return type. Should member function +exceptions() found in 27.4.4 [ios] be used instead? +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts], change +"(exception()&badbit) != 0" to "(exceptions()&badbit) != 0". +</p> + + +<p><b>Rationale:</b></p> +<p>Fixes an obvious typo.</p> + + + + + +<hr> +<h3><a name="375"></a>375. basic_ios should be ios_base in 27.7.1.3</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#WP">WP</a> + <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In Section 27.7.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph +14 all contain references to "basic_ios::" which should be +"ios_base::". +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change all references to "basic_ios" in Table 90, Table 91, and +paragraph 14 to "ios_base". +</p> + + +<p><b>Rationale:</b></p><p>Fixes an obvious typo.</p> + + + + +<hr> +<h3><a name="376"></a>376. basic_streambuf semantics</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#WP">WP</a> + <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In Section 27.7.1.4 [stringbuf.virtuals], Table 90, the implication is that +the four conditions should be mutually exclusive, but they are not. +The first two cases, as written, are subcases of the third.</p> + +<p> +As written, it is unclear what should be the result if cases 1 and 2 +are both true, but case 3 is false. +</p> + + + +<p><b>Proposed resolution:</b></p> + +<p>Rewrite these conditions as:</p> +<blockquote> +<p> + (which & (ios_base::in|ios_base::out)) == ios_base::in +</p> + +<p> + (which & (ios_base::in|ios_base::out)) == ios_base::out +</p> + +<p> + (which & (ios_base::in|ios_base::out)) == +(ios_base::in|ios_base::out) + and way == either ios_base::beg or ios_base::end +</p> + +<p>Otherwise</p> +</blockquote> + + + +<p><b>Rationale:</b></p> +<p>It's clear what we wanted to say, we just failed to say it. This + fixes it.</p> + + + + + +<hr> +<h3><a name="379"></a>379. nonsensical ctype::do_widen() requirement</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense. +</p> +<pre> charT do_widen (char c) const; + + -11- Effects: Applies the simplest reasonable transformation from + a char value or sequence of char values to the corresponding + charT value or values. The only characters for which unique + transformations are required are those in the basic source + character set (2.2). For any named ctype category with a + ctype<charT> facet ctw and valid ctype_base::mask value + M (is(M, c) || !ctw.is(M, do_widen(c))) is true. +</pre> +<p> +Shouldn't the last sentence instead read +</p> +<pre> For any named ctype category with a ctype<char> facet ctc + and valid ctype_base::mask value M + (ctc.is(M, c) || !is(M, do_widen(c))) is true. +</pre> +<p> +I.e., if the narrow character c is not a member of a class of +characters then neither is the widened form of c. (To paraphrase +footnote 224.) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Replace the last sentence of 22.2.1.1.2 [locale.ctype.virtuals], p11 with the +following text: +</p> +<pre> For any named ctype category with a ctype<char> facet ctc + and valid ctype_base::mask value M, + (ctc.is(M, c) || !is(M, do_widen(c))) is true. +</pre> + +<p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The LWG believes this is just a typo, and that this is the correct fix.</p> + + + + + +<hr> +<h3><a name="380"></a>380. typos in codecvt tables 53 and 54</h3> +<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Tables 53 and 54 in 22.2.1.5 [locale.codecvt.byname] are both titled "convert +result values," when surely "do_in/do_out result values" must have +been intended for Table 53 and "do_unshift result values" for Table +54. +</p> +<p> +Table 54, row 3 says that the meaning of partial is "more characters +needed to be supplied to complete termination." The function is not +supplied any characters, it is given a buffer which it fills with +characters or, more precisely, destination elements (i.e., an escape +sequence). So partial means that space for more than (to_limit - to) +destination elements was needed to terminate a sequence given the +value of state. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the title of Table 53 to "do_in/do_out result values" and +the title of Table 54 to "do_unshift result values." +</p> +<p> +Change the text in Table 54, row 3 (the <b>partial</b> row), under the +heading Meaning, to "space for more than (to_limit - to) destination +elements was needed to terminate a sequence given the value of state." +</p> + + + + +<hr> +<h3><a name="381"></a>381. detection of invalid mbstate_t in codecvt</h3> +<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +All but one codecvt member functions that take a state_type argument +list as one of their preconditions that the state_type argument have +a valid value. However, according to 22.2.1.5.2, p6, +codecvt::do_unshift() is the only codecvt member that is supposed to +return error if the state_type object is invalid. +</p> + +<p> +It seems to me that the treatment of state_type by all codecvt member +functions should be the same and the current requirements should be +changed. Since the detection of invalid state_type values may be +difficult in general or computationally expensive in some specific +cases, I propose the following: +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add a new paragraph before 22.2.1.5.2, p5, and after the function +declaration below +</p> +<pre> result do_unshift(stateT& state, + externT* to, externT* to_limit, externT*& to_next) const; +</pre> +<p> +as follows: +</p> +<pre> Requires: (to <= to_end) well defined and true; state initialized, + if at the beginning of a sequence, or else equal to the result of + converting the preceding characters in the sequence. +</pre> +<p> +and change the text in Table 54, row 4, the <b>error</b> row, under +the heading Meaning, from +</p> +<pre> state has invalid value +</pre> +<p> +to +</p> +<pre> an unspecified error has occurred +</pre> + + +<p><b>Rationale:</b></p> +<p>The intent is that implementations should not be required to detect +invalid state values; such a requirement appears nowhere else. An +invalid state value is a precondition violation, <i>i.e.</i> undefined +behavior. Implementations that do choose to detect invalid state +values, or that choose to detect any other kind of error, may return +<b>error</b> as an indication.</p> + + + + + +<hr> +<h3><a name="383"></a>383. Bidirectional iterator assertion typo</h3> +<p><b>Section:</b> 24.1.4 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Date:</b> 2002-10-17</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Following a discussion on the boost list regarding end iterators and +the possibility of performing operator--() on them, it seems to me +that there is a typo in the standard. This typo has nothing to do +with that discussion. +</p> + +<p> +I have checked this newsgroup, as well as attempted a search of the +Active/Defect/Closed Issues List on the site for the words "s is +derefer" so I believe this has not been proposed before. Furthermore, +the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> on section +24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> is not related to this issue. +</p> + +<p> +The standard makes the following assertion on bidirectional iterators, +in section 24.1.4 [lib.bidirectional.iterators], Table 75: +</p> + +<pre> operational assertion/note +expression return type semantics pre/post-condition + +--r X& pre: there exists s such + that r == ++s. + post: s is dereferenceable. + --(++r) == r. + --r == --s implies r == s. + &r == &--r. +</pre> + +<p> +(See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.) +</p> + +<p> +In particular, "s is dereferenceable" seems to be in error. It seems +that the intention was to say "r is dereferenceable". +</p> + +<p> +If it were to say "r is dereferenceable" it would +make perfect sense. Since s must be dereferenceable prior to +operator++, then the natural result of operator-- (to undo operator++) +would be to make r dereferenceable. Furthermore, without other +assertions, and basing only on precondition and postconditions, we +could not otherwise know this. So it is also interesting information. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the guarantee to "postcondition: r is dereferenceable." +</p> + + +<p><b>Rationale:</b></p><p>Fixes an obvious typo</p> + + + + +<hr> +<h3><a name="384"></a>384. equal_range has unimplementable runtime complexity</h3> +<p><b>Section:</b> 25.3.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Hans Bos <b>Date:</b> 2002-10-18</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 25.3.3.3 [equal.range] +states that at most 2 * log(last - first) + 1 +comparisons are allowed for equal_range. +</p> + +<p>It is not possible to implement equal_range with these constraints.</p> + +<p>In a range of one element as in:</p> +<pre> int x = 1; + equal_range(&x, &x + 1, 1) +</pre> + +<p>it is easy to see that at least 2 comparison operations are needed.</p> + +<p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p> + +<p>I have checked a few libraries and they all use the same (nonconforming) +algorithm for equal_range that has a complexity of</p> +<pre> 2* log(distance(first, last)) + 2. +</pre> +<p>I guess this is the algorithm that the standard assumes for equal_range.</p> + +<p> +It is easy to see that 2 * log(distance) + 2 comparisons are enough +since equal range can be implemented with lower_bound and upper_bound +(both log(distance) + 1). +</p> + +<p> +I think it is better to require something like 2log(distance) + O(1) (or +even logarithmic as multiset::equal_range). +Then an implementation has more room to optimize for certain cases (e.g. +have log(distance) characteristics when at most match is found in the range +but 2log(distance) + 4 for the worst case). +</p> + + + +<p><b>Proposed resolution:</b></p> +<p>In 25.3.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt> +to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> + +<p>In 25.3.3.2 [upper.bound]/4, change <tt>log(last - first) + 1</tt> +to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> + +<p>In 25.3.3.3 [equal.range]/4, change <tt>2*log(last - first) + 1</tt> +to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> + +<p><i>[Matt provided wording]</i></p> + + + +<p><b>Rationale:</b></p> +<p>The LWG considered just saying <i>O</i>(log n) for all three, but + decided that threw away too much valuable information. The fact + that lower_bound is twice as fast as equal_range is important. + However, it's better to allow an arbitrary additive constant than to + specify an exact count. An exact count would have to + involve <tt>floor</tt> or <tt>ceil</tt>. It would be too easy to + get this wrong, and don't provide any substantial value for users.</p> + + + + +<hr> +<h3><a name="386"></a>386. Reverse iterator's operator[] has impossible return type</h3> +<p><b>Section:</b> 24.4.1.3.11 [reverse.iter.op-=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p>In 24.4.1.3.11 [reverse.iter.op-=], <tt>reverse_iterator<>::operator[]</tt> +is specified as having a return type of <tt>reverse_iterator::reference</tt>, +which is the same as <tt>iterator_traits<Iterator>::reference</tt>. +(Where <tt>Iterator</tt> is the underlying iterator type.)</p> + +<p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't + necessarily have a return type + of <tt>iterator_traits<Iterator>::reference</tt>. Its + return type is merely required to be convertible + to <tt>Iterator</tt>'s value type. The return type specified for + reverse_iterator's operator[] would thus appear to be impossible.</p> + +<p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, the type of + <tt>a[n]</tt> will continue to be required (for random access + iterators) to be convertible to the value type, and also <tt>a[n] = + t</tt> will be a valid expression. Implementations of + <tt>reverse_iterator</tt> will likely need to return a proxy from + <tt>operator[]</tt> to meet these requirements. As mentioned in the + comment from Dave Abrahams, the simplest way to specify that + <tt>reverse_iterator</tt> meet this requirement to just mandate + it and leave the return type of <tt>operator[]</tt> unspecified.</p> + + + +<p><b>Proposed resolution:</b></p> + +<p>In 24.4.1.2 [reverse.iter.requirements] change:</p> + +<blockquote> +<pre>reference operator[](difference_type n) const; +</pre> +</blockquote> + +<p>to:</p> + +<blockquote> +<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.1.5 [random.access.iterators] +</pre> +</blockquote> + + + + +<p><i>[ +Comments from Dave Abrahams: IMO we should resolve 386 by just saying + that the return type of reverse_iterator's operator[] is + unspecified, allowing the random access iterator requirements to + impose an appropriate return type. If we accept 299's proposed + resolution (and I think we should), the return type will be + readable and writable, which is about as good as we can do. +]</i></p> + + + + + + +<hr> +<h3><a name="389"></a>389. Const overload of valarray::operator[] returns by value</h3> +<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#valarray.access">issues</a> in [valarray.access].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a></p> +<p><b>Discussion:</b></p> +<p>Consider the following program:</p> +<pre> #include <iostream> + #include <ostream> + #include <vector> + #include <valarray> + #include <algorithm> + #include <iterator> + template<typename Array> + void print(const Array& a) + { + using namespace std; + typedef typename Array::value_type T; + copy(&a[0], &a[0] + a.size(), + ostream_iterator<T>(std::cout, " ")); + } + template<typename T, unsigned N> + unsigned size(T(&)[N]) { return N; } + int main() + { + double array[] = { 0.89, 9.3, 7, 6.23 }; + std::vector<double> v(array, array + size(array)); + std::valarray<double> w(array, size(array)); + print(v); // #1 + std::cout << std::endl; + print(w); // #2 + std::cout << std::endl; + } +</pre> + +<p>While the call numbered #1 succeeds, the call numbered #2 fails +because the const version of the member function +valarray<T>::operator[](size_t) returns a value instead of a +const-reference. That seems to be so for no apparent reason, no +benefit. Not only does that defeats users' expectation but it also +does hinder existing software (written either in C or Fortran) +integration within programs written in C++. There is no reason why +subscripting an expression of type valarray<T> that is const-qualified +should not return a const T&.</p> + + +<p><b>Proposed resolution:</b></p> +<p>In the class synopsis in 26.5.2 [template.valarray], and in +26.5.2.3 [valarray.access] just above paragraph 1, change</p> +<pre> T operator[](size_t const); +</pre> +<p>to</p> +<pre> const T& operator[](size_t const); +</pre> + +<p><i>[Kona: fixed a minor typo: put semicolon at the end of the line + wehre it belongs.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>Return by value seems to serve no purpose. Valaray was explicitly +designed to have a specified layout so that it could easily be +integrated with libraries in other languages, and return by value +defeats that purpose. It is believed that this change will have no +impact on allowable optimizations.</p> + + + + + +<hr> +<h3><a name="391"></a>391. non-member functions specified as const</h3> +<p><b>Section:</b> 22.1.3.2 [conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> James Kanze <b>Date:</b> 2002-12-10</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The specifications of toupper and tolower both specify the functions as +const, althought they are not member functions, and are not specified as +const in the header file synopsis in section 22.1 [locales]. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 22.1.3.2 [conversions], remove <tt>const</tt> from the function + declarations of std::toupper and std::tolower</p> + + +<p><b>Rationale:</b></p><p>Fixes an obvious typo</p> + + + + +<hr> +<h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> James Kanze <b>Date:</b> 2003-01-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 26.7 [c.math], the C++ standard refers to the C standard for the +definition of rand(); in the C standard, it is written that "The +implementation shall behave as if no library function calls the rand +function." +</p> + +<p> +In 25.2.12 [alg.random.shuffle], there is no specification as to +how the two parameter version of the function generates its random +value. I believe that all current implementations in fact call rand() +(in contradiction with the requirement avove); if an implementation does +not call rand(), there is the question of how whatever random generator +it does use is seeded. Something is missing. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +In [lib.c.math], add a paragraph specifying that the C definition of +rand shal be modified to say that "Unless otherwise specified, the +implementation shall behave as if no library function calls the rand +function." +</p> + +<p> +In [lib.alg.random.shuffle], add a sentence to the effect that "In +the two argument form of the function, the underlying source of +random numbers is implementation defined. [Note: in particular, an +implementation is permitted to use <tt>rand</tt>.] +</p> + + +<p><b>Rationale:</b></p> +<p>The original proposed resolution proposed requiring the + two-argument from of <tt>random_shuffle</tt> to + use <tt>rand</tt>. We don't want to do that, because some existing + implementations already use something else: gcc + uses <tt>lrand48</tt>, for example. Using <tt>rand</tt> presents a + problem if the number of elements in the sequence is greater than + RAND_MAX.</p> + + + + + +<hr> +<h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3> +<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +20.7.5.1 [allocator.members] allocator members, contains +the following 3 lines: +</p> + +<pre> 12 Returns: new((void *) p) T( val) + void destroy(pointer p); + 13 Returns: ((T*) p)->~T() +</pre> + +<p> +The type cast "(T*) p" in the last line is redundant cause +we know that std::allocator<T>::pointer is a typedef for T*. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Replace "((T*) p)" with "p". +</p> + + +<p><b>Rationale:</b></p><p>Just a typo, this is really editorial.</p> + + + + +<hr> +<h3><a name="401"></a>401. incorrect type casts in table 32 in lib.allocator.requirements</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#WP">WP</a> + <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I think that in par2 of [default.con.req] the last two +lines of table 32 contain two incorrect type casts. The lines are ... +</p> + +<pre> a.construct(p,t) Effect: new((void*)p) T(t) + a.destroy(p) Effect: ((T*)p)?->~T() +</pre> + +<p> +.... with the prerequisits coming from the preceding two paragraphs, especially +from table 31: +</p> + +<pre> alloc<T> a ;// an allocator for T + alloc<T>::pointer p ;// random access iterator + // (may be different from T*) + alloc<T>::reference r = *p;// T& + T const& t ; +</pre> + +<p> +For that two type casts ("(void*)p" and "(T*)p") to be well-formed +this would require then conversions to T* and void* for all +alloc<T>::pointer, so it would implicitely introduce extra +requirements for alloc<T>::pointer, additionally to the only +current requirement (being a random access iterator). +</p> + + +<p><b>Proposed resolution:</b></p> + +<p> +Accept proposed wording from +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 1. +</p> + +<p> +Note: Actually I would prefer to replace "((T*)p)?->dtor_name" with +"p?->dtor_name", but AFAICS this is not possible cause of an omission +in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002). +</p> + +<p><i>[Kona: The LWG thinks this is somewhere on the border between + Open and NAD. The intend is clear: <tt>construct</tt> constructs an + object at the location <i>p</i>. It's reading too much into the + description to think that literally calling <tt>new</tt> is + required. Tweaking this description is low priority until we can do + a thorough review of allocators, and, in particular, allocators with + non-default pointer types.]</i></p> + + +<p><i>[ +Batavia: Proposed resolution changed to less code and more description. +]</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> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which +was subsequently split out into a separate paper N2436 for the purposes of voting. +The resolution in N2436 addresses this issue. The LWG voted to accelerate this +issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + + + +<hr> +<h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3> +<p><b>Section:</b> 20.1.2 [allocator.requirements], 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +This applies to the new expression that is contained in both par12 of +20.7.5.1 [allocator.members] and in par2 (table 32) of [default.con.req]. +I think this new expression is wrong, involving unintended side +effects. +</p> + + +<p>20.7.5.1 [allocator.members] contains the following 3 lines:</p> + +<pre> 11 Returns: the largest value N for which the call allocate(N,0) might succeed. + void construct(pointer p, const_reference val); + 12 Returns: new((void *) p) T( val) +</pre> + + +<p> [default.con.req] in table 32 has the following line:</p> +<pre> a.construct(p,t) Effect: new((void*)p) T(t) +</pre> + +<p> +.... with the prerequisits coming from the preceding two paragraphs, +especially from table 31: +</p> + +<pre> alloc<T> a ;// an allocator for T + alloc<T>::pointer p ;// random access iterator + // (may be different from T*) + alloc<T>::reference r = *p;// T& + T const& t ; +</pre> + +<p> +Cause of using "new" but not "::new", any existing "T::operator new" +function will hide the global placement new function. When there is no +"T::operator new" with adequate signature, +every_alloc<T>::construct(..) is ill-formed, and most +std::container<T,every_alloc<T>> use it; a workaround +would be adding placement new and delete functions with adequate +signature and semantic to class T, but class T might come from another +party. Maybe even worse is the case when T has placement new and +delete functions with adequate signature but with "unknown" semantic: +I dont like to speculate about it, but whoever implements +any_container<T,any_alloc> and wants to use construct(..) +probably must think about it. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Replace "new" with "::new" in both cases. +</p> + + + + + + + +<hr> +<h3><a name="403"></a>403. basic_string::swap should not throw exceptions</h3> +<p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2003-03-25</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +std::basic_string, 21.3 [basic.string] paragraph 2 says that +basic_string "conforms to the requirements of a Sequence, as specified +in (23.1.1)." The sequence requirements specified in (23.1.1) to not +include any prohibition on swap members throwing exceptions. +</p> + +<p> +Section 23.1 [container.requirements] paragraph 10 does limit conditions under +which exceptions may be thrown, but applies only to "all container +types defined in this clause" and so excludes basic_string::swap +because it is defined elsewhere. +</p> + +<p> +Eric Niebler points out that 21.3 [basic.string] paragraph 5 explicitly +permits basic_string::swap to invalidates iterators, which is +disallowed by 23.1 [container.requirements] paragraph 10. Thus the standard would +be contradictory if it were read or extended to read as having +basic_string meet 23.1 [container.requirements] paragraph 10 requirements. +</p> + +<p> +Yet several LWG members have expressed the belief that the original +intent was that basic_string::swap should not throw exceptions as +specified by 23.1 [container.requirements] paragraph 10, and that the standard is +unclear on this issue. The complexity of basic_string::swap is +specified as "constant time", indicating the intent was to avoid +copying (which could cause a bad_alloc or other exception). An +important use of swap is to ensure that exceptions are not thrown in +exception-safe code. +</p> + +<p> +Note: There remains long standing concern over whether or not it is +possible to reasonably meet the 23.1 [container.requirements] paragraph 10 swap +requirements when allocators are unequal. The specification of +basic_string::swap exception requirements is in no way intended to +address, prejudice, or otherwise impact that concern. +</p> + + + + + + + +<p><b>Proposed resolution:</b></p> +<p> +In 21.3.6.8 [string::swap], add a throws clause: +</p> + +<p> +Throws: Shall not throw exceptions. +</p> + + + + + +<hr> +<h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3> +<p><b>Section:</b> 17.4.3.5 [replacement.functions], 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-04-24</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The eight basic dynamic memory allocation functions (single-object +and array versions of ::operator new and ::operator delete, in the +ordinary and nothrow forms) are replaceable. A C++ program may +provide an alternative definition for any of them, which will be used +in preference to the implementation's definition. +</p> + +<p> +Three different parts of the standard mention requirements on +replacement functions: 17.4.3.5 [replacement.functions], 18.5.1.1 [new.delete.single] +and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto]. +</p> + +<p>None of these three places say whether a replacement function may + be declared inline. 18.5.1.1 [new.delete.single] paragraph 2 specifies a + signature for the replacement function, but that's not enough: + the <tt>inline</tt> specifier is not part of a function's signature. + One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which + requires that "an inline function shall be defined in every + translation unit in which it is used," but this may not be quite + specific enough either. We should either explicitly allow or + explicitly forbid inline replacement memory allocation + functions.</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add a new sentence to the end of 17.4.3.5 [replacement.functions] paragraph 3: +"The program's definitions shall not be specified as <tt>inline</tt>. +No diagnostic is required." +</p> + +<p><i>[Kona: added "no diagnostic is required"]</i></p> + + + + +<p><b>Rationale:</b></p> +<p> +The fact that <tt>inline</tt> isn't mentioned appears to have been +nothing more than an oversight. Existing implementations do not +permit inline functions as replacement memory allocation functions. +Providing this functionality would be difficult in some cases, and is +believed to be of limited value. +</p> + + + + + +<hr> +<h3><a name="405"></a>405. qsort and POD</h3> +<p><b>Section:</b> 25.4 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Ray Lischner <b>Date:</b> 2003-04-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 25.4 [alg.c.library] describes bsearch and qsort, from the C +standard library. Paragraph 4 does not list any restrictions on qsort, +but it should limit the base parameter to point to POD. Presumably, +qsort sorts the array by copying bytes, which requires POD. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 25.4 [alg.c.library] paragraph 4, just after the declarations and +before the nonnormative note, add these words: "both of which have the +same behavior as the original declaration. The behavior is undefined +unless the objects in the array pointed to by <i>base</i> are of POD +type." +</p> + +<p><i>[Something along these lines is clearly necessary. Matt + provided wording.]</i></p> + + + + + + +<hr> +<h3><a name="406"></a>406. vector::insert(s) exception safety</h3> +<p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-04-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p> +There is a possible defect in the standard: the standard text was +never intended to prevent arbitrary ForwardIterators, whose operations +may throw exceptions, from being passed, and it also wasn't intended +to require a temporary buffer in the case where ForwardIterators were +passed (and I think most implementations don't use one). As is, the +standard appears to impose requirements that aren't met by any +existing implementation. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace 23.2.6.4 [vector.modifiers] paragraph 1 with:</p> +<blockquote><p> + 1- Notes: Causes reallocation if the new size is greater than the + old capacity. If no reallocation happens, all the iterators and + references before the insertion point remain valid. If an exception + is thrown other than by the copy constructor or assignment operator + of T or by any InputIterator operation there are no effects. +</p></blockquote> + +<p><i>[We probably need to say something similar for deque.]</i></p> + + + + + + + +<hr> +<h3><a name="407"></a>407. Can singular iterators be destroyed?</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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Clause 24.1 [iterator.requirements], paragraph 5, says that the only expression +that is defined for a singular iterator is "an assignment of a +non-singular value to an iterator that holds a singular value". This +means that destroying a singular iterator (e.g. letting an automatic +variable go out of scope) is technically undefined behavior. This +seems overly strict, and probably unintentional. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the sentence in question to "... the only exceptions are +destroying an iterator that holds a singular value, or the assignment +of a non-singular value to an iterator that holds a singular value." +</p> + + + + + +<hr> +<h3><a name="409"></a>409. Closing an fstream should clear error state</h3> +<p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> + <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p> +A strict reading of 27.8.1 [fstreams] shows that opening or +closing a basic_[io]fstream does not affect the error bits. This +means, for example, that if you read through a file up to EOF, and +then close the stream and reopen it at the beginning of the file, +the EOF bit in the stream's error state is still set. This is +counterintuitive. +</p> +<p> +The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, +and put in a footnote to clarify that the strict reading was indeed +correct. We did that because we believed the standard was +unambiguous and consistent, and that we should not make architectural +changes in a TC. Now that we're working on a new revision of the +language, those considerations no longer apply. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p>Change 27.8.1.9 [ifstream.members], para. 3 from:</p> + +<blockquote><p> +Calls rdbuf()->open(s,mode|in). If that function returns a null +pointer, calls setstate(failbit) (which may throw ios_base::failure +[Footnote: (lib.iostate.flags)]. +</p></blockquote> + +<p>to:</p> + +<blockquote><p>Calls rdbuf()->open(s,mode|in). If that function +returns a null pointer, calls setstate(failbit) (which may throw +ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear(). +</p></blockquote> + +<p>Change 27.8.1.13 [ofstream.members], para. 3 from:</p> + +<blockquote><p>Calls rdbuf()->open(s,mode|out). If that function +returns a null pointer, calls setstate(failbit) (which may throw +ios_base::failure [Footnote: (lib.iostate.flags)). +</p></blockquote> + +<p>to:</p> + +<blockquote><p>Calls rdbuf()->open(s,mode|out). If that function +returns a null pointer, calls setstate(failbit) (which may throw +ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear(). +</p></blockquote> + +<p>Change 27.8.1.17 [fstream.members], para. 3 from:</p> + +<blockquote><p>Calls rdbuf()->open(s,mode), If that function returns +a null pointer, calls setstate(failbit), (which may throw +ios_base::failure). (lib.iostate.flags) ) +</p></blockquote> + +<p>to:</p> + +<blockquote><p>Calls rdbuf()->open(s,mode), If that function returns +a null pointer, calls setstate(failbit), (which may throw +ios_base::failure). (lib.iostate.flags) ), else calls clear(). +</p></blockquote> + + + +<p><i>[Kona: the LWG agrees this is a good idea. Post-Kona: Bill +provided wording. He suggests having open, not close, clear the error +flags.]</i></p> + + +<p><i>[Post-Sydney: Howard provided a new proposed resolution. The + old one didn't make sense because it proposed to fix this at the + level of basic_filebuf, which doesn't have access to the stream's + error state. Howard's proposed resolution fixes this at the level + of the three fstream class template instead.]</i></p> + + + + + + + + +<hr> +<h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3> +<p><b>Section:</b> 23.2.4.1 [list.cons], 23.2.4.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Hans Bos <b>Date:</b> 2003-06-07</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Sections 23.2.4.1 [list.cons] and 23.2.4.3 [list.modifiers] list +comparison operators (==, !=, <, <=, >, =>) for queue and +stack. Only the semantics for queue::operator== (23.2.4.1 [list.cons] par2) and queue::operator< (23.2.4.1 [list.cons] +par3) are defined. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p>Add the following new paragraphs after 23.2.4.1 [list.cons] + paragraph 3:</p> + +<blockquote> + +<pre> operator!= +</pre> +<p>Returns: <tt>x.c != y.c</tt></p> + +<pre> operator> +</pre> +<p>Returns: <tt>x.c > y.c</tt></p> + +<pre> operator<= +</pre> +<p>Returns: <tt>x.c <= y.c</tt></p> + +<pre> operator>= +</pre> +<p>Returns: <tt>x.c >= y.c</tt></p> + +</blockquote> + +<p>Add the following paragraphs at the end of 23.2.4.3 [list.modifiers]:</p> + +<blockquote> + +<pre> operator== +</pre> +<p>Returns: <tt>x.c == y.c</tt></p> + +<pre> operator< +</pre> +<p>Returns: <tt>x.c < y.c</tt></p> + +<pre> operator!= +</pre> +<p>Returns: <tt>x.c != y.c</tt></p> + +<pre> operator> +</pre> +<p>Returns: <tt>x.c > y.c</tt></p> + +<pre> operator<= +</pre> +<p>Returns: <tt>x.c <= y.c</tt></p> + +<pre> operator>= +</pre> +<p>Returns: <tt>x.c >= y.c</tt></p> + +</blockquote> + + +<p><i>[Kona: Matt provided wording.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>There isn't any real doubt about what these operators are +supposed to do, but we ought to spell it out.</p> + + + + + +<hr> +<h3><a name="411"></a>411. Wrong names of set member functions</h3> +<p><b>Section:</b> 25.3.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Frey <b>Date:</b> 2003-07-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +25.3.5 [alg.set.operations] paragraph 1 reads: +"The semantics of the set operations are generalized to multisets in a +standard way by defining union() to contain the maximum number of +occurrences of every element, intersection() to contain the minimum, and +so on." +</p> + +<p> +This is wrong. The name of the functions are set_union() and +set_intersection(), not union() and intersection(). +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change that sentence to use the correct names.</p> + + + + + +<hr> +<h3><a name="412"></a>412. Typo in 27.4.4.3</h3> +<p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-07-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#429">429</a></p> +<p><b>Discussion:</b></p> +<p> +The Effects clause in 27.4.4.3 [iostate.flags] paragraph 5 says that the +function only throws if the respective bits are already set prior to +the function call. That's obviously not the intent. The typo ought to +be corrected and the text reworded as: "If (<i>state</i> & +exceptions()) == 0, returns. ..." +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 27.4.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() & +exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit)) +& exceptions()) == 0". +</p> + +<p><i>[Kona: the original proposed resolution wasn't quite right. We + really do mean rdstate(); the ambiguity is that the wording in the + standard doesn't make it clear whether we mean rdstate() before + setting the new state, or rdsate() after setting it. We intend the + latter, of course. Post-Kona: Martin provided wording.]</i></p> + + + + + + + +<hr> +<h3><a name="413"></a>413. Proposed resolution to LDR#64 still wrong</h3> +<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> + <b>Submitter:</b> Bo Persson <b>Date:</b> 2003-07-13</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The second sentence of the proposed resolution says: +</p> + +<p> +"If it inserted no characters because it caught an exception thrown +while extracting characters from sb and ..." +</p> + +<p> +However, we are not extracting from sb, but extracting from the +basic_istream (*this) and inserting into sb. I can't really tell if +"extracting" or "sb" is a typo. +</p> + +<p><i>[ +Sydney: Definitely a real issue. We are, indeed, extracting characters +from an istream and not from sb. The problem was there in the FDIS and +wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was +to have *this instead of sb. We're talking about the exception flag +state of a basic_istream object, and there's only one basic_istream +object in this discussion, so that would be a consistent +interpretation. (But we need to be careful: the exception policy of +this member function must be consistent with that of other +extractors.) PJP will provide wording. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p>Change the sentence from:</p> + +<blockquote><p> +If it inserted no characters because it caught an exception thrown +while extracting characters from sb and failbit is on in exceptions(), +then the caught exception is rethrown. +</p></blockquote> + +<p>to:</p> + +<blockquote><p> +If it inserted no characters because it caught an exception thrown +while extracting characters from *this and failbit is on in exceptions(), +then the caught exception is rethrown. +</p></blockquote> + + + + + +<hr> +<h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3> +<p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-08-19</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Consider the following code fragment: +</p> +<blockquote> +<pre>int A[8] = { 1,3,5,7,9,8,4,2 }; +std::vector<int> v(A, A+8); + +std::vector<int>::iterator i1 = v.begin() + 3; +std::vector<int>::iterator i2 = v.begin() + 4; +v.erase(i1); +</pre> +</blockquote> + +<p> +Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2, +both, or neither? +</p> + +<p> +On all existing implementations that I know of, the status of i1 and +i2 is the same: both of them will be iterators that point to some +elements of the vector (albeit not the same elements they did +before). You won't get a crash if you use them. Depending on +exactly what you mean by "invalidate", you might say that neither one +has been invalidated because they still point to <i>something</i>, +or you might say that both have been invalidated because in both +cases the elements they point to have been changed out from under the +iterator. +</p> + +<p> +The standard doesn't say either of those things. It says that erase +invalidates all iterators and references "after the point of the +erase". This doesn't include i1, since it's at the point of the +erase instead of after it. I can't think of any sensible definition +of invalidation by which one can say that i2 is invalidated but i1 +isn't. +</p> + +<p> +(This issue is important if you try to reason about iterator validity +based only on the guarantees in the standard, rather than reasoning +from typical implementation techniques. Strict debugging modes, +which some programmers find useful, do not use typical implementation +techniques.) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 23.2.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the +iterators and references after the point of the erase" to +"Invalidates iterators and references at or after the point of the +erase". +</p> + + +<p><b>Rationale:</b></p> +<p>I believe this was essentially a typographical error, and that it + was taken for granted that erasing an element invalidates iterators + that point to it. The effects clause in question treats iterators + and references in parallel, and it would seem counterintuitive to + say that a reference to an erased value remains valid.</p> + + + + + +<hr> +<h3><a name="415"></a>415. behavior of std::ws</h3> +<p><b>Section:</b> 27.6.1.4 [istream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +According to 27.6.1.4, the ws() manipulator is not required to construct +the sentry object. The manipulator is also not a member function so the +text in 27.6.1, p1 through 4 that describes the exception policy for +istream member functions does not apply. That seems inconsistent with +the rest of extractors and all the other input functions (i.e., ws will +not cause a tied stream to be flushed before extraction, it doesn't check +the stream's exceptions or catch exceptions thrown during input, and it +doesn't affect the stream's gcount). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to 27.6.1.4 [istream.manip], immediately before the first sentence +of paragraph 1, the following text: +</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 is.gcount(). After constructing a sentry + object... + </p></blockquote> + +<p><i>[Post-Kona: Martin provided wording]</i></p> + + + + + + +<hr> +<h3><a name="416"></a>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3> +<p><b>Section:</b> 18.2.2 [c.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +Given two overloads of the function foo(), one taking an argument of type +int and the other taking a long, which one will the call foo(LONG_MAX) +resolve to? The expected answer should be foo(long), but whether that +is true depends on the #defintion of the LONG_MAX macro, specifically +its type. This issue is about the fact that the type of these macros +is not actually required to be the same as the the type each respective +limit. +<br> + +Section 18.2.2 of the C++ Standard does not specify the exact types of +the XXX_MIN and XXX_MAX macros #defined in the <climits> and <limits.h> +headers such as INT_MAX and LONG_MAX and instead defers to the C standard. +<br> + +Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of +these constants] shall be replaced by constant expressions suitable for use +in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, +the following shall be replaced by expressions that have the same type as +would an expression that is an object of the corresponding type converted +according to the integer promotions." +<br> + +The "corresponding type converted according to the integer promotions" for +LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long +converted to the first of the following set of types that can represent it: +int, long int, long long int. So on an implementation where (sizeof(long) +== sizeof(int)) this type is actually int, while on an implementation where +(sizeof(long) > sizeof(int)) holds this type will be long. +<br> + +This is not an issue in C since the type of the macro cannot be detected +by any conforming C program, but it presents a portability problem in C++ +where the actual type is easily detectable by overload resolution. + + </p> +<p><i>[Kona: the LWG does not believe this is a defect. The C macro + definitions are what they are; we've got a better + mechanism, <tt>std::numeric_limits</tt>, that is specified more + precisely than the C limit macros. At most we should add a + nonnormative note recommending that users who care about the exact + types of limit quantities should use <limits> instead of + <climits>.]</i></p> + + + + +<p><b>Proposed resolution:</b></p> + +<p> +Change 18.2.2 [c.limits], paragraph 2: +</p> + +<blockquote><p> +-2- The contents are the same as the Standard C library header <tt><limits.h></tt>. +<ins>[<i>Note:</i> The types of the macros in <tt><climits></tt> are not guaranteed +to match the type to which they refer.<i>--end note</i>]</ins> +</p></blockquote> + + + + + +<hr> +<h3><a name="420"></a>420. is std::FILE a complete type?</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#WP">WP</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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +7.19.1, p2, of C99 requires that the FILE type only be declared in +<stdio.h>. None of the (implementation-defined) members of the +struct is mentioned anywhere for obvious reasons. +</p> + +<p> +C++ says in 27.8.1, p2 that FILE is a type that's defined in <cstdio>. Is +it really the intent that FILE be a complete type or is an implementation +allowed to just declare it without providing a full definition? +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In the first sentence of 27.8.1 [fstreams] paragraph 2, change + "defined" to "declared".</p> + + +<p><b>Rationale:</b></p> +<p>We don't want to impose any restrictions beyond what the C standard + already says. We don't want to make anything implementation defined, + because that imposes new requirements in implementations.</p> + + + + + +<hr> +<h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3> +<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#reserved.names">issues</a> in [reserved.names].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It has been suggested that 17.4.3.1, p1 may or may not allow programs to +explicitly specialize members of standard templates on user-defined types. +The answer to the question might have an impact where library requirements +are given using the "as if" rule. I.e., if programs are allowed to specialize +member functions they will be able to detect an implementation's strict +conformance to Effects clauses that describe the behavior of the function +in terms of the other member function (the one explicitly specialized by +the program) by relying on the "as if" rule. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p> + Add the following sentence to 17.4.3.2 [reserved.names], p1: +</p> + +<blockquote><p> +It is undefined for a C++ program to add declarations or definitions to +namespace std or namespaces within namespace <tt>std</tt> unless otherwise specified. A +program may add template specializations for any standard library template to +namespace <tt>std</tt>. Such a specialization (complete or partial) of a standard library +template results in undefined behavior unless the declaration depends on a +user-defined type of external linkage and unless the specialization meets the +standard library requirements for the original template.<sup>168)</sup> +<ins>A program has undefined behavior if it declares</ins> +</p> +<ul> +<li><ins>an explicit specialization of any member function of a standard + library class template, or</ins></li> +<li><ins>an explicit specialization of any member function template of a + standard library class or class template, or</ins></li> +<li><ins>an explicit or partial specialization of any member class + template of a standard library class or class template.</ins></li> +</ul> +<p> +A program may explicitly instantiate any templates in the standard library only +if the declaration depends on the name of a user-defined type of external +linkage and the instantiation meets the standard library requirements for the +original template. +</p></blockquote> + +<p><i>[Kona: straw poll was 6-1 that user programs should not be + allowed to specialize individual member functions of standard + library class templates, and that doing so invokes undefined + behavior. Post-Kona: Martin provided wording.]</i></p> + + +<p><i>[Sydney: The LWG agrees that the standard shouldn't permit users +to specialize individual member functions unless they specialize the +whole class, but we're not sure these words say what we want them to; +they could be read as prohibiting the specialization of any standard +library class templates. We need to consult with CWG to make sure we +use the right wording.]</i></p> + + + + + + +<hr> +<h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3> +<p><b>Section:</b> 20.7.8 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The standard is not clear about the requirements on the value returned from +a call to get_temporary_buffer(0). In particular, it fails to specify whether +the call should return a distinct pointer each time it is called (like +operator new), or whether the value is unspecified (as if returned by +malloc). The standard also fails to mention what the required behavior +is when the argument is less than 0. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 20.5.3 [meta.help] paragraph 2 from "...or a pair of 0 +values if no storage can be obtained" to "...or a pair of 0 values if +no storage can be obtained or if <i>n</i> <= 0."</p> +<p><i>[Kona: Matt provided wording]</i></p> + + + + + +<hr> +<h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3> +<p><b>Section:</b> 25.1.12 [alg.search], 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#WP">WP</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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The complexity requirements for these function templates are incorrect +(or don't even make sense) for negative n:</p> + +<p>25.1.9, p7 (search_n): +<br> +Complexity: At most (last1 - first1) * count applications +of the corresponding predicate.</p> + +<p>25.2.5, p3 (fill_n): +<br> +Complexity: Exactly last - first (or n) assignments.</p> + +<p>25.2.6, p3 (generate_n): +<br> +Complexity: Exactly last - first (or n) assignments.</p> + +<p> +In addition, the Requirements or the Effects clauses for the latter two +templates don't say anything about the behavior when n is negative. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 25.1.9, p7 to</p> + +<blockquote><p> +Complexity: At most (last1 - first1) * count applications +of the corresponding predicate if count is positive, +or 0 otherwise. +</p></blockquote> + +<p>Change 25.2.5, p2 to</p> +<blockquote><p> +Effects: Assigns value through all the iterators in the range [first, +last), or [first, first + n) if n is positive, none otherwise. +</p></blockquote> + +<p>Change 25.2.5, p3 to:</p> +<blockquote><p> +Complexity: Exactly last - first (or n if n is positive, +or 0 otherwise) assignments. +</p></blockquote> + +<p> +Change 25.2.6, p1 +to (notice the correction for the misspelled "through"): +</p> +<blockquote><p> +Effects: Invokes the function object genand assigns the return +value of gen through all the iterators in the range [first, last), +or [first, first + n) if n is positive, or [first, first) +otherwise. +</p></blockquote> + +<p>Change 25.2.6, p3 to:</p> +<blockquote><p> +Complexity: Exactly last - first (or n if n is positive, +or 0 otherwise) assignments. +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p>Informally, we want to say that whenever we see a negative number + we treat it the same as if it were zero. We believe the above + changes do that (although they may not be the minimal way of saying + so). The LWG considered and rejected the alternative of saying that + negative numbers are undefined behavior.</p> + + + + + +<hr> +<h3><a name="428"></a>428. string::erase(iterator) validity</h3> +<p><b>Section:</b> 21.3.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#string::erase">issues</a> in [string::erase].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q) +that q must be a valid dereferenceable iterator into the sequence a. +</p> + +<p> +However, 21.3.5.5, p5 describing string::erase(p) only requires that +p be a valid iterator. +</p> + +<p> +This may be interepreted as a relaxation of the general requirement, +which is most likely not the intent. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Remove 21.3.6.5 [string::erase] paragraph 5.</p> + + +<p><b>Rationale:</b></p> +<p>The LWG considered two options: changing the string requirements to + match the general container requirements, or just removing the + erroneous string requirements altogether. The LWG chose the latter + option, on the grounds that duplicating text always risks the + possibility that it might be duplicated incorrectly.</p> + + + + + +<hr> +<h3><a name="432"></a>432. stringbuf::overflow() makes only one write position available</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#WP">WP</a> + <b>Submitter:</b> Christian W Brock <b>Date:</b> 2003-09-24</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.7.1.3 par 8 says:</p> +<blockquote><p> +Notes: The function can make a write position available only if + ( mode & ios_base::out) != 0. To make a write position + available, the function reallocates (or initially allocates) an + array object with a sufficient number of elements to hold the + current array object (if any), plus one additional write position. + If ( mode & ios_base::in) != 0, the function alters the read end + pointer egptr() to point just past the new write position (as + does the write end pointer epptr()). +</p></blockquote> + +<p> +The sentences "plus one additional write position." and especially + "(as does the write end pointer epptr())" COULD by interpreted + (and is interpreted by at least my library vendor) as: +</p> + +<blockquote><p> + post-condition: epptr() == pptr()+1 +</p></blockquote> + +<p> +This WOULD force sputc() to call the virtual overflow() each time. +</p> + +<p>The proposed change also affects Defect Report 169.</p> + + + +<p><b>Proposed resolution:</b></p> +<p>27.7.1.1/2 Change:</p> + +<blockquote><p> +2- Notes: The function allocates no array object. +</p></blockquote> + +<p> +to: +</p> + +<blockquote><p> +2- Postcondition: str() == "". +</p></blockquote> + +<p> +27.7.1.1/3 Change: +</p> + +<blockquote> +<p> +-3- Effects: Constructs an object of class basic_stringbuf, +initializing the base class with basic_streambuf() +(lib.streambuf.cons), and initializing mode with which . Then copies +the content of str into the basic_stringbuf underlying character +sequence and initializes the input and output sequences according to +which. If which & ios_base::out is true, initializes the output +sequence with the underlying sequence. If which & ios_base::in is +true, initializes the input sequence with the underlying sequence. +</p> +</blockquote> + +<p>to:</p> + +<blockquote> +<p> +-3- Effects: Constructs an object of class basic_stringbuf, +initializing the base class with basic_streambuf() +(lib.streambuf.cons), and initializing mode with which. Then copies +the content of str into the basic_stringbuf underlying character +sequence. If which & ios_base::out is true, initializes the output +sequence such that pbase() points to the first underlying character, +epptr() points one past the last underlying character, and if (which & +ios_base::ate) is true, pptr() is set equal to +epptr() else pptr() is set equal to pbase(). If which & ios_base::in +is true, initializes the input sequence such that eback() and gptr() +point to the first underlying character and egptr() points one past +the last underlying character. +</p> +</blockquote> + +<p>27.7.1.2/1 Change:</p> + +<blockquote> +<p> +-1- Returns: A basic_string object whose content is equal to the +basic_stringbuf underlying character sequence. If the buffer is only +created in input mode, the underlying character sequence is equal to +the input sequence; otherwise, it is equal to the output sequence. In +case of an empty underlying character sequence, the function returns +basic_string<charT,traits,Allocator>(). +</p> +</blockquote> + +<p>to:</p> + +<blockquote> +<p> +-1- Returns: A basic_string object whose content is equal to the +basic_stringbuf underlying character sequence. If the basic_stringbuf +was created only in input mode, the resultant basic_string contains +the character sequence in the range [eback(), egptr()). If the +basic_stringbuf was created with (which & ios_base::out) being true +then the resultant basic_string contains the character sequence in the +range [pbase(), high_mark) where high_mark represents the position one +past the highest initialized character in the buffer. Characters can +be initialized either through writing to the stream, or by +constructing the basic_stringbuf with a basic_string, or by calling +the str(basic_string) member function. In the case of calling the +str(basic_string) member function, all characters initialized prior to +the call are now considered uninitialized (except for those +characters re-initialized by the new basic_string). Otherwise the +basic_stringbuf has been created in neither input nor output mode and +a zero length basic_string is returned. +</p> +</blockquote> + +<p> +27.7.1.2/2 Change: +</p> + +<blockquote> +<p> +-2- Effects: If the basic_stringbuf's underlying character sequence is +not empty, deallocates it. Then copies the content of s into the +basic_stringbuf underlying character sequence and initializes the +input and output sequences according to the mode stored when creating +the basic_stringbuf object. If (mode&ios_base::out) is true, then +initializes the output sequence with the underlying sequence. If +(mode&ios_base::in) is true, then initializes the input sequence with +the underlying sequence. +</p> +</blockquote> + +<p>to:</p> + +<blockquote> +<p> +-2- Effects: Copies the content of s into the basic_stringbuf +underlying character sequence. If mode & ios_base::out is true, +initializes the output sequence such that pbase() points to the first +underlying character, epptr() points one past the last underlying +character, and if (mode & ios_base::ate) is true, +pptr() is set equal to epptr() else pptr() is set equal to pbase(). If +mode & ios_base::in is true, initializes the input sequence such that +eback() and gptr() point to the first underlying character and egptr() +points one past the last underlying character. +</p> +</blockquote> + +<p>Remove 27.2.1.2/3. (Same rationale as issue 238: incorrect and unnecessary.)</p> + +<p>27.7.1.3/1 Change:</p> + +<blockquote> +<p> +1- Returns: If the input sequence has a read position available, +returns traits::to_int_type(*gptr()). Otherwise, returns +traits::eof(). +</p> +</blockquote> + +<p>to:</p> + +<blockquote> +<p> +1- Returns: If the input sequence has a read position available, +returns traits::to_int_type(*gptr()). Otherwise, returns +traits::eof(). Any character in the underlying buffer which has been +initialized is considered to be part of the input sequence. +</p> +</blockquote> + +<p>27.7.1.3/9 Change:</p> + +<blockquote> +<p> +-9- Notes: The function can make a write position available only if ( +mode & ios_base::out) != 0. To make a write position available, the +function reallocates (or initially allocates) an array object with a +sufficient number of elements to hold the current array object (if +any), plus one additional write position. If ( mode & ios_base::in) != +0, the function alters the read end pointer egptr() to point just past +the new write position (as does the write end pointer epptr()). +</p> +</blockquote> + +<p>to:</p> + +<blockquote> +<p> +-9- The function can make a write position available only if ( mode & +ios_base::out) != 0. To make a write position available, the function +reallocates (or initially allocates) an array object with a sufficient +number of elements to hold the current array object (if any), plus one +additional write position. If ( mode & ios_base::in) != 0, the +function alters the read end pointer egptr() to point just past the +new write position. +</p> +</blockquote> + +<p>27.7.1.3/12 Change:</p> + +<blockquote> +<p> +-12- _ If (newoff + off) < 0, or (xend - xbeg) < (newoff + off), the +positioning operation fails. Otherwise, the function assigns xbeg + +newoff + off to the next pointer xnext . +</p> +</blockquote> + +<p>to:</p> + +<blockquote> +<p> +-12- _ If (newoff + off) < 0, or if (newoff + off) refers to an +uninitialized character (as defined in 27.7.1.3 [stringbuf.members] +paragraph 1), the positioning operation fails. Otherwise, the function +assigns xbeg + newoff + off to the next pointer xnext . +</p> +</blockquote> + +<p><i>[post-Kona: Howard provided wording. At Kona the LWG agreed that + something along these lines was a good idea, but the original + proposed resolution didn't say enough about the effect of various + member functions on the underlying character sequences.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The current basic_stringbuf description is over-constrained in such +a way as to prohibit vendors from making this the high-performance +in-memory stream it was meant to be. The fundamental problem is that +the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are +observable from a derived client, and the current description +restricts the range [pbase(), epptr()) from being grown geometrically. +This change allows, but does not require, geometric growth of this +range.</p> + +<p>Backwards compatibility issues: These changes will break code that +derives from basic_stringbuf, observes epptr(), and depends upon +[pbase(), epptr()) growing by one character on each call to overflow() +(i.e. test suites). Otherwise there are no backwards compatibility +issues.</p> + +<p>27.7.1.1/2: The non-normative note is non-binding, and if it were +binding, would be over specification. The recommended change focuses +on the important observable fact.</p> + +<p>27.7.1.1/3: This change does two things: 1. It describes exactly +what must happen in terms of the sequences. The terms "input +sequence" and "output sequence" are not well defined. 2. It +introduces a common extension: open with app or ate mode. I concur +with issue 238 that paragraph 4 is both wrong and unnecessary.</p> + +<p>27.7.1.2/1: This change is the crux of the efficiency issue. The +resultant basic_string is not dependent upon epptr(), and thus +implementors are free to grow the underlying buffer geometrically +during overflow() *and* place epptr() at the end of that buffer.</p> + +<p>27.7.1.2/2: Made consistent with the proposed 27.7.1.1/3.</p> + +<p>27.7.1.3/1: Clarifies that characters written to the stream beyond +the initially specified string are available for reading in an i/o +basic_streambuf.</p> + +<p>27.7.1.3/9: Made normative by removing "Notes:", and removed the +trailing parenthetical comment concerning epptr().</p> + +<p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no +longer allowable since [pbase(), epptr()) may now contain +uninitialized characters. Positioning is only allowable over the +initialized range.</p> + + + + + +<hr> +<h3><a name="434"></a>434. bitset::to_string() hard to use</h3> +<p><b>Section:</b> 23.3.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It has been pointed out a number of times that the bitset to_string() member +function template is tedious to use since callers must explicitly specify the +entire template argument list (3 arguments). At least two implementations +provide a number of overloads of this template to make it easier to use. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p>In order to allow callers to specify no template arguments at all, just the +first one (charT), or the first 2 (charT and traits), in addition to all +three template arguments, add the following three overloads to both the +interface (declarations only) of the class template bitset as well as to +section 23.3.5.2, immediately after p34, the Returns clause of the existing +to_string() member function template:</p> + +<pre> template <class charT, class traits> + basic_string<charT, traits, allocator<charT> > + to_string () const; + + -34.1- Returns: to_string<charT, traits, allocator<charT> >(). + + template <class charT> + basic_string<charT, char_traits<charT>, allocator<charT> > + to_string () const; + + -34.2- Returns: to_string<charT, char_traits<charT>, allocator<charT> >(). + + basic_string<char, char_traits<char>, allocator<char> > + to_string () const; + + -34.3- Returns: to_string<char, char_traits<char>, allocator<char> >(). +</pre> + +<p><i>[Kona: the LWG agrees that this is an improvement over the + status quo. Dietmar thought about an alternative using a proxy + object but now believes that the proposed resolution above is the + right choice. +]</i></p> + + + + + + + + +<hr> +<h3><a name="435"></a>435. bug in DR 25</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +It has been pointed out that the proposed resolution in DR 25 may not be +quite up to snuff: <br> +http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html +http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br> +</p> + +<p> +It looks like Petur is right. The complete corrected text is copied below. +I think we may have have been confused by the reference to 22.2.2.2.2 and +the subsequent description of `n' which actually talks about the second +argument to sputn(), not about the number of fill characters to pad with. +</p> + +<p> +So the question is: was the original text correct? If the intent was to +follow classic iostreams then it most likely wasn't, since setting width() +to less than the length of the string doesn't truncate it on output. This +is also the behavior of most implementations (except for SGI's standard +iostreams where the operator does truncate). +</p> + + + +<p><b>Proposed resolution:</b></p> +<p>Change the text in 21.3.7.9, p4 from</p> + <blockquote><p> + If bool(k) is true, inserts characters as if by calling + os.rdbuf()->sputn(str.data(), n), padding as described in stage 3 + of lib.facet.num.put.virtuals, where n is the larger of os.width() + and str.size(); + </p></blockquote> +<p>to</p> + <blockquote><p> + If bool(k) is true, determines padding as described in + lib.facet.num.put.virtuals, and then inserts the resulting + sequence of characters <tt>seq</tt> as if by calling + <tt>os.rdbuf()->sputn(seq, n)</tt>, where <tt>n</tt> is the larger of + <tt>os.width()</tt> and <tt>str.size()</tt>; + </p></blockquote> + +<p><i>[Kona: it appears that neither the original wording, DR25, nor the + proposed resolution, is quite what we want. We want to say that + the string will be output, padded to os.width() if necessary. We + don't want to duplicate the padding rules in clause 22, because + they're complicated, but we need to be careful because they weren't + quite written with quite this case in mind. We need to say what + the character sequence is, and then defer to clause 22. Post-Kona: + Benjamin provided wording.]</i></p> + + + + + + + +<hr> +<h3><a name="436"></a>436. are cv-qualified facet types valid facets?</h3> +<p><b>Section:</b> 22.1.1.1.2 [locale.facet] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Is "const std::ctype<char>" a valid template argument to has_facet, use_facet, +and the locale template ctor? And if so, does it designate the same Facet as +the non-const "std::ctype<char>?" What about "volatile std::ctype<char>?" +Different implementations behave differently: some fail to compile, others +accept such types but behave inconsistently. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change 22.1.1.1.2, p1 to read:</p> + +<p>Template parameters in this clause which are required to be facets +are those named Facet in declarations. A program that passes a type +that is not a facet, or a type that refers to volatile-qualified +facet, as an (explicit or deduced) template parameter to a locale +function expecting a facet, is ill-formed. A const-qualified facet is +a valid template argument to any locale function that expects a Facet +template parameter.</p> + +<p><i>[Kona: changed the last sentence from a footnote to normative +text.]</i></p> + + + + + + +<hr> +<h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</h3> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2003-10-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> + +<p>Section 23.1.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem +noticed with statements like:</p> +<pre>vector<int> v(10, 1); +</pre> + +<p>The intent of the above statement was to construct with:</p> +<pre>vector(size_type, const value_type&); +</pre> + +<p>but early implementations failed to compile as they bound to:</p> +<pre>template <class InputIterator> +vector(InputIterator f, InputIterator l); +</pre> +<p>instead.</p> + +<p>Paragraphs 9-11 say that if InputIterator is an integral type, then the +member template constructor will have the same effect as:</p> +<pre>vector<static_cast<size_type>(f), static_cast<value_type>(l)); +</pre> +<p>(and similarly for the other member template functions of sequences).</p> + +<p>There is also a note that describes one implementation technique:</p> +<blockquote><p> + One way that sequence implementors can satisfy this requirement is to + specialize the member template for every integral type. +</p></blockquote> + +<p>This might look something like:</p> +<blockquote> +<pre>template <class T> +struct vector +{ + typedef unsigned size_type; + + explicit vector(size_type) {} + vector(size_type, const T&) {} + + template <class I> + vector(I, I); + + // ... +}; + +template <class T> +template <class I> +vector<T>::vector(I, I) { ... } + +template <> +template <> +vector<int>::vector(int, int) { ... } + +template <> +template <> +vector<int>::vector(unsigned, unsigned) { ... } + +// ... +</pre> +</blockquote> + +<p>Label this solution 'A'.</p> + +<p>The standard also says:</p> +<blockquote><p> + Less cumbersome implementation techniques also exist. +</p></blockquote> +<p> +A popular technique is to not specialize as above, but instead catch +every call with the member template, detect the type of InputIterator, +and then redirect to the correct logic. Something like: +</p> +<blockquote> +<pre>template <class T> +template <class I> +vector<T>::vector(I f, I l) +{ + choose_init(f, l, int2type<is_integral<I>::value>()); +} + +template <class T> +template <class I> +vector<T>::choose_init(I f, I l, int2type<false>) +{ + // construct with iterators +} + +template <class T> +template <class I> +vector<T>::choose_init(I f, I l, int2type<true>) +{ + size_type sz = static_cast<size_type>(f); + value_type v = static_cast<value_type>(l); + // construct with sz,v +} +</pre> +</blockquote> + +<p>Label this solution 'B'.</p> + +<p>Both of these solutions solve the case the standard specifically +mentions:</p> +<pre>vector<int> v(10, 1); // ok, vector size 10, initialized to 1 +</pre> + +<p> +However, (and here is the problem), the two solutions have different +behavior in some cases where the value_type of the sequence is not an +integral type. For example consider: +</p> +<blockquote><pre> pair<char, char> p('a', 'b'); + vector<vector<pair<char, char> > > d('a', 'b'); +</pre></blockquote> +<p> +The second line of this snippet is likely an error. Solution A catches +the error and refuses to compile. The reason is that there is no +specialization of the member template constructor that looks like: +</p> +<pre>template <> +template <> +vector<vector<pair<char, char> > >::vector(char, char) { ... } +</pre> + +<p> +So the expression binds to the unspecialized member template +constructor, and then fails (compile time) because char is not an +InputIterator. +</p> + +<p> +Solution B compiles the above example though. 'a' is casted to an +unsigned integral type and used to size the outer vector. 'b' is +static casted to the inner vector using it's explicit constructor: +</p> + +<pre>explicit vector(size_type n); +</pre> + +<p> +and so you end up with a static_cast<size_type>('a') by +static_cast<size_type>('b') matrix. +</p> + +<p> +It is certainly possible that this is what the coder intended. But the +explicit qualifier on the inner vector has been thwarted at any rate. +</p> + +<p> +The standard is not clear whether the expression: +</p> + +<pre> vector<vector<pair<char, char> > > d('a', 'b'); +</pre> + +<p> +(and similar expressions) are: +</p> + +<ol> +<li> undefined behavior.</li> +<li> illegal and must be rejected.</li> +<li> legal and must be accepted.</li> +</ol> + +<p>My preference is listed in the order presented.</p> + +<p>There are still other techniques for implementing the requirements of +paragraphs 9-11, namely the "restricted template technique" (e.g. +enable_if). This technique is the most compact and easy way of coding +the requirements, and has the behavior of #2 (rejects the above +expression). +</p> + +<p> +Choosing 1 would allow all implementation techniques I'm aware of. +Choosing 2 would allow only solution 'A' and the enable_if technique. +Choosing 3 would allow only solution 'B'. +</p> + +<p> +Possible wording for a future standard if we wanted to actively reject +the expression above would be to change "static_cast" in paragraphs +9-11 to "implicit_cast" where that is defined by: +</p> + +<blockquote> +<pre>template <class T, class U> +inline +T implicit_cast(const U& u) +{ + return u; +} +</pre> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + +<p>Replace 23.1.3 [sequence.reqmts] paragraphs 9 - 11 with:</p> + +<p>For every sequence defined in this clause and in clause lib.strings:</p> + +<ul> + <li> + <p>If the constructor</p> + <pre> template <class InputIterator> + X(InputIterator f, InputIterator l, + const allocator_type& a = allocator_type()) + </pre> + <p>is called with a type InputIterator that does not qualify as + an input iterator, then the constructor will behave as if the + overloaded constructor:</p> + <pre> X(size_type, const value_type& = value_type(), + const allocator_type& = allocator_type()) + </pre> + <p>were called instead, with the arguments static_cast<size_type>(f), l and a, respectively.</p> + </li> + + <li> + <p>If the member functions of the forms:</p> + <pre> template <class InputIterator> // such as insert() + rt fx1(iterator p, InputIterator f, InputIterator l); + + template <class InputIterator> // such as append(), assign() + rt fx2(InputIterator f, InputIterator l); + + template <class InputIterator> // such as replace() + rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l); + </pre> + <p>are called with a type InputIterator that does not qualify as + an input iterator, then these functions will behave as if the + overloaded member functions:</p> + <pre> rt fx1(iterator, size_type, const value_type&); + + rt fx2(size_type, const value_type&); + + rt fx3(iterator, iterator, size_type, const value_type&); + </pre> + <p>were called instead, with the same arguments.</p> + </li> +</ul> + +<p>In the previous paragraph the alternative binding will fail if f +is not implicitly convertible to X::size_type or if l is not implicitly +convertible to X::value_type.</p> + +<p> +The extent to which an implementation determines that a type cannot be +an input iterator is unspecified, except that as a minimum integral +types shall not qualify as input iterators. +</p> + + + +<p><i>[ +Kona: agreed that the current standard requires <tt>v('a', 'b')</tt> +to be accepted, and also agreed that this is surprising behavior. The +LWG considered several options, including something like +implicit_cast, which doesn't appear to be quite what we want. We +considered Howards three options: allow acceptance or rejection, +require rejection as a compile time error, and require acceptance. By +straw poll (1-6-1), we chose to require a compile time error. +Post-Kona: Howard provided wording. +]</i></p> + + +<p><i>[ +Sydney: The LWG agreed with this general direction, but there was some +discomfort with the wording in the original proposed resolution. +Howard submitted new wording, and we will review this again in +Redmond. +]</i></p> + + +<p><i>[Redmond: one very small change in wording: the first argument + is cast to size_t. This fixes the problem of something like + <tt>vector<vector<int> >(5, 5)</tt>, where int is not + implicitly convertible to the value type.]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>The proposed resolution fixes:</p> + +<pre> vector<int> v(10, 1); +</pre> + +<p> +since as integral types 10 and 1 must be disqualified as input +iterators and therefore the (size,value) constructor is called (as +if).</p> + +<p>The proposed resolution breaks:</p> + +<pre> vector<vector<T> > v(10, 1); +</pre> + +<p> +because the integral type 1 is not *implicitly* convertible to +vector<T>. The wording above requires a diagnostic.</p> + +<p> +The proposed resolution leaves the behavior of the following code +unspecified. +</p> + +<pre> struct A + { + operator int () const {return 10;} + }; + + struct B + { + B(A) {} + }; + + vector<B> v(A(), A()); +</pre> + +<p> +The implementation may or may not detect that A is not an input +iterator and employee the (size,value) constructor. Note though that +in the above example if the B(A) constructor is qualified explicit, +then the implementation must reject the constructor as A is no longer +implicitly convertible to B. +</p> + + + + + +<hr> +<h3><a name="441"></a>441. Is fpos::state const?</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#WP">WP</a> + <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-17</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In section 27.4.3.1 [fpos.members] fpos<stateT>::state() is declared +non const, but in section 27.4.3 [fpos] it is declared const. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In section 27.4.3.1 [fpos.members], change the declaration of +<tt>fpos<stateT>::state()</tt> to const. +</p> + + + + + +<hr> +<h3><a name="442"></a>442. sentry::operator bool() inconsistent signature</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#WP">WP</a> + <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-18</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In section 27.6.2.4 [ostream::sentry] paragraph 4, in description part +basic_ostream<charT, traits>::sentry::operator bool() is declared +as non const, but in section 27.6.2.3, in synopsis it is declared +const. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In section 27.6.2.4 [ostream::sentry] paragraph 4, change the declaration +of <tt>sentry::operator bool()</tt> to const. +</p> + + + + + +<hr> +<h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</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#WP">WP</a> + <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In section 27.8.1.4 [filebuf.members] par6, in effects description of +basic_filebuf<charT, traits>::close(), overflow(EOF) is used twice; +should be overflow(traits::eof()). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change overflow(EOF) to overflow(traits::eof()). +</p> + + + + + +<hr> +<h3><a name="444"></a>444. Bad use of casts in fstream</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#DR">DR</a> + <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</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#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p>27.8.1.9 [ifstream.members] p1, 27.8.1.13 [ofstream.members] p1, +27.8.1.17 [fstream.members] p1 seems have same problem as exposed in +LWG issue +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away + constness. The other two places are stylistic: we could change the + C-style casts to const_cast. Post-Sydney: Howard provided wording. +]</i></p> + + +<p>Change 27.8.1.7/1 from:</p> +<blockquote><p> + Returns: (basic_filebuf<charT,traits>*)&sb. +</p></blockquote> + +<p>to:</p> +<blockquote><p> + Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). +</p></blockquote> + +<p>Change 27.8.1.10/1 from:</p> +<blockquote><p> + Returns: (basic_filebuf<charT,traits>*)&sb. +</p></blockquote> + +<p>to:</p> +<blockquote><p> + Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). +</p></blockquote> + +<p>Change 27.8.1.13/1 from:</p> +<blockquote><p> + Returns: &sb. +</p></blockquote> + +<p>to:</p> +<blockquote><p> + Returns: const_cast<basic_filebuf<charT,traits>*>(&sb). +</p></blockquote> + + + + + + + + +<hr> +<h3><a name="445"></a>445. iterator_traits::reference unspecified for some iterator categories</h3> +<p><b>Section:</b> 24.3.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-12-09</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The standard places no restrictions at all on the reference type +of input, output, or forward iterators (for forward iterators it +only specifies that *x must be value_type& and doesn't mention +the reference type). Bidirectional iterators' reference type is +restricted only by implication, since the base iterator's +reference type is used as the return type of reverse_iterator's +operator*, which must be T& in order to be a conforming forward +iterator. +</p> + +<p> +Here's what I think we ought to be able to expect from an input +or forward iterator's reference type R, where a is an iterator +and V is its value_type +</p> + +<ul> + <li> + *a is convertible to R + </li> + + <li> + R is convertible to V + </li> + + <li> + static_cast<V>(static_cast<R>(*a)) is equivalent to + static_cast<V>(*a) + </li> +</ul> + +<p>A mutable forward iterator ought to satisfy, for x of type V:</p> + <pre> { R r = *a; r = x; } is equivalent to *a = x; + </pre> + +<p> +I think these requirements capture existing container iterators +(including vector<bool>'s), but render istream_iterator invalid; +its reference type would have to be changed to a constant +reference. +</p> + + +<p> +(Jeremy Siek) During the discussion in Sydney, it was felt that a +simpler long term solution for this was needed. The solution proposed +was to require <tt>reference</tt> to be the same type as <tt>*a</tt> +and <tt>pointer</tt> to be the same type as <tt>a-></tt>. Most +iterators in the Standard Library already meet this requirement. Some +iterators are output iterators, and do not need to meet the +requirement, and others are only specified through the general +iterator requirements (which will change with this resolution). The +sole case where there is an explicit definition of the reference type +that will need to change is <tt>istreambuf_iterator</tt> which returns +<tt>charT</tt> from <tt>operator*</tt> but has a reference type of +<tt>charT&</tt>. We propose changing the reference type of +<tt>istreambuf_iterator</tt> to <tt>charT</tt>. +</p> + +<p>The other option for resolving the issue with <tt>pointer</tt>, + mentioned in the note below, is to remove <tt>pointer</tt> + altogether. I prefer placing requirements on <tt>pointer</tt> to + removing it for two reasons. First, <tt>pointer</tt> will become + useful for implementing iterator adaptors and in particular, + <tt>reverse_iterator</tt> will become more well defined. Second, + removing <tt>pointer</tt> is a rather drastic and publicly-visible + action to take.</p> + +<p>The proposed resolution technically enlarges the requirements for +iterators, which means there are existing iterators (such as +<tt>istreambuf_iterator</tt>, and potentially some programmer-defined +iterators) that will no longer meet the requirements. Will this break +existing code? The scenario in which it would is if an algorithm +implementation (say in the Standard Library) is changed to rely on +<tt>iterator_traits::reference</tt>, and then is used with one of the +iterators that do not have an appropriately defined +<tt>iterator_traits::reference</tt>. +</p> + + +<p>The proposed resolution makes one other subtle change. Previously, +it was required that output iterators have a <tt>difference_type</tt> +and <tt>value_type</tt> of <tt>void</tt>, which means that a forward +iterator could not be an output iterator. This is clearly a mistake, +so I've changed the wording to say that those types may be +<tt>void</tt>. +</p> + + + +<p><b>Proposed resolution:</b></p> + +<p>In 24.3.1 [iterator.traits], after:</p> + +<blockquote><p> +be defined as the iterator's difference type, value type and iterator +category, respectively. +</p></blockquote> + +<p>add</p> + +<blockquote><p> +In addition, the types</p> +<pre>iterator_traits<Iterator>::reference +iterator_traits<Iterator>::pointer +</pre> +<p>must be defined as the iterator's reference and pointer types, that +is, the same type as the type of <tt>*a</tt> and <tt>a-></tt>, +respectively.</p> +</blockquote> + +<p>In 24.3.1 [iterator.traits], change:</p> + +<blockquote><p> +In the case of an output iterator, the types</p> +<pre>iterator_traits<Iterator>::difference_type +iterator_traits<Iterator>::value_type +</pre> +<p>are both defined as <tt>void</tt>.</p> +</blockquote> + +<p>to:</p> +<blockquote><p> +In the case of an output iterator, the types</p> +<pre>iterator_traits<Iterator>::difference_type +iterator_traits<Iterator>::value_type +iterator_traits<Iterator>::reference +iterator_traits<Iterator>::pointer +</pre> +<p>may be defined as <tt>void</tt>.</p> +</blockquote> + +<p>In 24.5.3 [istreambuf.iterator], change:</p> +<blockquote> +<pre>typename traits::off_type, charT*, charT&> +</pre> +</blockquote> +<p>to:</p> +<blockquote> +<pre>typename traits::off_type, charT*, charT> +</pre> +</blockquote> + +<p><i>[ +Redmond: there was concern in Sydney that this might not be the only place +where things were underspecified and needed to be changed. Jeremy +reviewed iterators in the standard and confirmed that nothing else +needed to be changed. +]</i></p> + + + + + + + + + +<hr> +<h3><a name="448"></a>448. Random Access Iterators over abstract classes</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#WP">WP</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-01-07</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Table 76, the random access iterator requirement table, says that the +return type of a[n] must be "convertible to T". When an iterator's +value_type T is an abstract class, nothing is convertible to T. +Surely this isn't an intended restriction? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the return type to "convertible to T const&". +</p> + + + + + +<hr> +<h3><a name="449"></a>449. Library Issue 306 Goes Too Far</h3> +<p><b>Section:</b> 18.1 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Pete Becker <b>Date:</b> 2004-01-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Original text:</p> +<blockquote><p> +The macro offsetof accepts a restricted set of type arguments in this +International Standard. type shall be a POD structure or a POD union +(clause 9). The result of applying the offsetof macro to a field that +is a static data member or a function member is undefined." +</p></blockquote> + +<p>Revised text:</p> +<blockquote><p> +"If type is not a POD structure or a POD union the results are undefined." +</p></blockquote> + +<p> +Looks to me like the revised text should have replaced only the second +sentence. It doesn't make sense standing alone. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p>Change 18.1, paragraph 5, to:</p> + +<blockquote><p> +The macro offsetof accepts a restricted set of type arguments in this +International Standard. If type is not a POD structure or a POD union +the results are undefined. The result of applying the offsetof macro +to a field that is a static data member or a function member is +undefined." +</p></blockquote> + + + + + +<hr> +<h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</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#WP">WP</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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir, + ios_base::openmode); +</pre> +<p> +is obliged to fail if nothing has been inserted into the stream. This +is unnecessary and undesirable. It should be permissible to seek to +an effective offset of zero.</p> + +<p><i>[ + Sydney: Agreed that this is an annoying problem: seeking to zero should be + legal. Bill will provide wording. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p>Change the sentence from:</p> +<blockquote><p> +For a sequence to be positioned, if its next pointer (either +gptr() or pptr()) is a null pointer, the positioning operation +fails. +</p></blockquote> + +<p>to:</p> + +<blockquote><p> +For a sequence to be positioned, if its next pointer (either +gptr() or pptr()) is a null pointer and the new offset newoff +is nonzero, the positioning operation fails. +</p></blockquote> + + + + + +<hr> +<h3><a name="455"></a>455. cerr::tie() and wcerr::tie() are overspecified</h3> +<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</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#iostream.objects">issues</a> in [iostream.objects].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Both cerr::tie() and wcerr::tie() are obliged to be null at program +startup. This is overspecification and overkill. It is both traditional +and useful to tie cerr to cout, to ensure that standard output is drained +whenever an error message is written. This behavior should at least be +permitted if not required. Same for wcerr::tie(). +</p> + + +<p><b>Proposed resolution:</b></p> + +<p>Add to the description of cerr:</p> +<blockquote><p> +After the object cerr is initialized, cerr.tie() returns &cout. +Its state is otherwise the same as required for basic_ios<char>::init +(lib.basic.ios.cons). +</p></blockquote> + +<p>Add to the description of wcerr:</p> + +<blockquote><p> +After the object wcerr is initialized, wcerr.tie() returns &wcout. +Its state is otherwise the same as required for basic_ios<wchar_t>::init +(lib.basic.ios.cons). +</p></blockquote> + +<p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just + permit, cout and cerr to be tied on startup. Pre-Redmond: Bill will + provide wording.]</i></p> + + + + + + +<hr> +<h3><a name="456"></a>456. Traditional C header files are overspecified</h3> +<p><b>Section:</b> 17.4.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#headers">issues</a> in [headers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>The C++ Standard effectively requires that the traditional C headers +(of the form <xxx.h>) be defined in terms of the newer C++ +headers (of the form <cxxx>). Clauses 17.4.1.2/4 and D.5 combine +to require that:</p> + +<ul> + <li>Including the header <cxxx> declares a C name in namespace std.</li> + + <li> Including the header <xxx.h> declares a C name in namespace std + (effectively by including <cxxx>), then imports it into the global + namespace with an individual using declaration.</li> +</ul> + +<p> +The rules were left in this form despited repeated and heated objections +from several compiler vendors. The C headers are often beyond the direct +control of C++ implementors. In some organizations, it's all they can do +to get a few #ifdef __cplusplus tests added. Third-party library vendors +can perhaps wrap the C headers. But neither of these approaches supports +the drastic restructuring required by the C++ Standard. As a result, it is +still widespread practice to ignore this conformance requirement, nearly +seven years after the committee last debated this topic. Instead, what is +often implemented is: +</p> + +<ul> + <li> Including the header <xxx.h> declares a C name in the + global namespace.</li> + + <li> Including the header <cxxx> declares a C name in the + global namespace (effectively by including <xxx.h>), then + imports it into namespace std with an individual using declaration.</li> +</ul> + +<p> +The practical benefit for implementors with the second approach is that +they can use existing C library headers, as they are pretty much obliged +to do. The practical cost for programmers facing a mix of implementations +is that they have to assume weaker rules:</p> + +<ul> + <li> If you want to assuredly declare a C name in the global + namespace, include <xxx.h>. You may or may not also get the + declaration in namespace std.</li> + + <li> If you want to assuredly declare a C name in namespace std, + include <cxxx>. You may or may not also get the declaration in + the global namespace.</li> +</ul> + +<p> +There also exists the <i>possibility</i> of subtle differences due to +Koenig lookup, but there are so few non-builtin types defined in the C +headers that I've yet to see an example of any real problems in this +area. +</p> + +<p> +It is worth observing that the rate at which programmers fall afoul of +these differences has remained small, at least as measured by newsgroup +postings and our own bug reports. (By an overwhelming margin, the +commonest problem is still that programmers include <string> and can't +understand why the typename string isn't defined -- this a decade after +the committee invented namespace std, nominally for the benefit of all +programmers.) +</p> + +<p> +We should accept the fact that we made a serious mistake and rectify it, +however belatedly, by explicitly allowing either of the two schemes for +declaring C names in headers. +</p> + +<p><i>[Sydney: This issue has been debated many times, and will + certainly have to be discussed in full committee before any action + can be taken. However, the preliminary sentiment of the LWG was in + favor of the change. (6 yes, 0 no, 2 abstain) Robert Klarer + suggests that we might also want to undeprecate the + C-style <tt>.h</tt> headers.]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +Add to 17.4.1.2 [headers], para. 4: +</p> + +<blockquote><p> +Except as noted in clauses 18 through 27 and Annex D, the contents of each +header <i>cname</i> shall be the same as that of the corresponding header +<i>name.h</i>, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause +7), or ISO/IEC:1990 Programming Languages-C AMENDMENT 1: C Integrity, (Clause +7), as appropriate, as if by inclusion. In the C++ Standard Library, however, +the declarations <del>and definitions</del> (except for names which are defined +as macros in C) are within namespace scope (3.3.5) of the namespace std. +<ins>It is unspecified whether these names are first declared within the global +namespace scope and are then injected into namespace std by explicit +using-declarations (7.3.3 [namespace.udecl]).</ins> +</p></blockquote> + +<p> +Change D.5 [depr.c.headers], para. 2-3: +</p> + +<blockquote> +<p> +-2- Every C header, each of which has a name of the form <i>name.h</i>, behaves +as if each name placed in the Standard library namespace by the corresponding +<i>cname</i> header is <del>also</del> placed within the <ins>global</ins> +namespace scope<ins>.</ins> <del>of the namespace <tt>std</tt> and is followed +by an explicit <i>using-declaration</i> (7.3.3 [namespace.udecl]).</del> +<ins>It is unspecified whether these names are first declared or defined within +namespace scope (3.3.5 [basic.scope.namespace]) of the namespace +<tt>std</tt> and are then injected into the global namespace scope by explicit +using-declarations (7.3.3 [namespace.udecl]).</ins> +</p> +<p> +-3- [<i>Example:</i> The header <tt><cstdlib></tt> <ins>assuredly</ins> +provides its declarations and definitions within the namespace <tt>std</tt>. +<ins>It may also provide these names within the global namespace.</ins> The +header <tt><stdlib.h></tt> <del>makes these available also in</del> +<ins>assuredly provides the same declarations and definitions within</ins> the +global namespace, much as in the C Standard. <ins>It may also provide these +names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>] +</p> +</blockquote> + + + + + +<hr> +<h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</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#DR">DR</a> + <b>Submitter:</b> Dag Henriksson <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#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#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The constructor from unsigned long says it initializes "the first M +bit positions to the corresponding bit values in val. M is the smaller +of N and the value CHAR_BIT * sizeof(unsigned long)." +</p> + +<p> +Object-representation vs. value-representation strikes again. CHAR_BIT * +sizeof (unsigned long) does not give us the number of bits an unsigned long +uses to hold the value. Thus, the first M bit position above is not +guaranteed to have any corresponding bit values in val. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 23.3.5.1 [bitset.cons] paragraph 2, change "M is the smaller of + N and the value CHAR_BIT * sizeof (unsigned long). (249)" to + "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in + the value representation (section 3.9 [basic.types]) of <tt>unsigned + long</tt>." +</p> + + + + + +<hr> +<h3><a name="460"></a>460. Default modes missing from basic_fstream member specifications</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#DR">DR</a> + <b>Submitter:</b> Ben Hutchings <b>Date:</b> 2004-04-01</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#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The second parameters of the non-default constructor and of the open +member function for basic_fstream, named "mode", are optional +according to the class declaration in 27.8.1.11 [lib.fstream]. The +specifications of these members in 27.8.1.12 [lib.fstream.cons] and +27.8.1.13 lib.fstream.members] disagree with this, though the +constructor declaration has the "explicit" function-specifier implying +that it is intended to be callable with one argument. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>In 27.8.1.15 [fstream.cons], change</p> +<pre> explicit basic_fstream(const char* s, ios_base::openmode mode); +</pre> +<p>to</p> +<pre> explicit basic_fstream(const char* s, + ios_base::openmode mode = ios_base::in|ios_base::out); +</pre> +<p>In 27.8.1.17 [fstream.members], change</p> +<pre> void open(const char*s, ios_base::openmode mode); +</pre> +<p>to</p> +<pre> void open(const char*s, + ios_base::openmode mode = ios_base::in|ios_base::out); +</pre> + + + + + +<hr> +<h3><a name="461"></a>461. time_get hard or impossible to implement</h3> +<p><b>Section:</b> 22.2.5.1.2 [locale.time.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Template time_get currently contains difficult, if not impossible, +requirements for do_date_order, do_get_time, and do_get_date. All require +the implementation to scan a field generated by the %x or %X conversion +specifier in strftime. Yes, do_date_order can always return no_order, but +that doesn't help the other functions. The problem is that %x can be +nearly anything, and it can vary widely with locales. It's horribly +onerous to have to parse "third sunday after Michaelmas in the year of +our Lord two thousand and three," but that's what we currently ask of +do_get_date. More practically, it leads some people to think that if +%x produces 10.2.04, we should know to look for dots as separators. Still +not easy. +</p> + +<p> +Note that this is the <i>opposite</i> effect from the intent stated in the +footnote earlier in this subclause: +</p> + +<blockquote><p> +"In other words, user confirmation is required for reliable parsing of +user-entered dates and times, but machine-generated formats can be +parsed reliably. This allows parsers to be aggressive about interpreting +user variations on standard formats." +</p></blockquote> + +<p> +We should give both implementers and users an easier and more reliable +alternative: provide a (short) list of alternative delimiters and say +what the default date order is for no_order. For backward compatibility, +and maximum latitude, we can permit an implementation to parse whatever +%x or %X generates, but we shouldn't require it. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p><b>In the description:</b></p> +<pre>iter_type do_get_time(iter_type s, iter_type end, ios_base& str, + ios_base::iostate& err, tm* t) const; +</pre> + +<p> +2 Effects: Reads characters starting at suntil it has extracted those +struct tm members, and remaining format characters, used by +time_put<>::put to produce the format specified by 'X', or until it +encounters an error or end of sequence. +</p> + +<p><b>change:</b> 'X'</p> + +<p><b>to:</b> "%H:%M:%S"</p> + + +<p>Change</p> +<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base& str, + ios_base::iostate& err, tm* t) const; + +4 Effects: Reads characters starting at s until it has extracted those +struct tm members, and remaining format characters, used by +time_put<>::put to produce the format specified by 'x', or until it +encounters an error. +</pre> + +<p>to</p> +<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base& str, + ios_base::iostate& err, tm* t) const; +</pre> + +<p> +4 Effects: Reads characters starting at s until it has extracted those +struct tm members, and remaining format characters, used by +time_put<>::put to produce one of the following formats, or until it +encounters an error. The format depends on the value returned by +date_order() as follows: +</p> + +<pre> date_order() format + + no_order "%m/%d/%y" + dmy "%d/%m/%y" + mdy "%m/%d/%y" + ymd "%y/%m/%d" + ydm "%y/%d/%m" +</pre> +<p> +An implementation may also accept additional implementation-defined formats. +</p> + +<p><i>[Redmond: agreed that this is a real problem. The solution is + probably to match C99's parsing rules. Bill provided wording. +]</i></p> + + + + + + + +<hr> +<h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3> +<p><b>Section:</b> 23.2.6 [vector], 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2004-05-12</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>To add slightly more convenience to vector<T> and map<Key,T> we should consider to add</p> +<ol> +<li> add vector<T>::data() member (const and non-const version) +semantics: if( empty() ) return 0; else return buffer_;</li> +<li> add map<Key,T>::at( const Key& k ) member (const and non-const version) +<i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li> +</ol> + +<p>Rationale:</p> + +<ul> +<li>To obtain a pointer to the vector's buffer, one must use either +operator[]() (which can give undefined behavior for empty vectors) or +at() (which will then throw if the vector is empty). </li> +<li>tr1::array<T,sz> already has a data() member</li> +<li>e cannot use operator[]() when T is not DefaultDonstructible</li> +<li>Neither when the map is const.</li> +<li>when we want to make sure we don't add an element accidently</li> +<li>when it should be considered an error if a key is not in the map</li> +</ul> + + + +<p><b>Proposed resolution:</b></p> +<p>In 23.2.6 [vector], add the following to the <tt>vector</tt> + synopsis after "element access" and before "modifiers":</p> +<pre> // <i>[lib.vector.data] data access</i> + pointer data(); + const_pointer data() const; +</pre> + +<p>Add a new subsection of 23.2.6 [vector]:</p> +<blockquote> +<p>23.2.4.x <tt>vector</tt> data access</p> +<pre> pointer data(); + const_pointer data() const; +</pre> +<p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid + range. For a non-empty vector, data() == &front().</p> +<p><b>Complexity:</b> Constant time.</p> +<p><b>Throws:</b> Nothing.</p> +</blockquote> + +<p>In 23.3.1 [map], add the following to the <tt>map</tt> +synopsis immediately after the line for operator[]:</p> +<pre> T& at(const key_type& x); + const T& at(const key_type& x) const; +</pre> + +<p>Add the following to 23.3.1.2 [map.access]:</p> +<blockquote> +<pre> T& at(const key_type& x); + const T& at(const key_type& x) const; +</pre> + +<p><b>Returns:</b> A reference to the element whose key is equivalent + to x, if such an element is present in the map.</p> +<p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p> + +</blockquote> + + + +<p><b>Rationale:</b></p> +<p>Neither of these additions provides any new functionality but the + LWG agreed that they are convenient, especially for novices. The + exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>, + was chosen to match <tt>vector::at</tt>.</p> + + + + + +<hr> +<h3><a name="465"></a>465. Contents of <ciso646></h3> +<p><b>Section:</b> 17.4.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 2004-06-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>C header <iso646.h> defines macros for some operators, such as +not_eq for !=.</p> + +<p>Section 17.4.1.2 [headers] "Headers" says that except as noted in +clauses 18 through 27, the <cname> C++ header contents are the same +as the C header <name.h>. In particular, table 12 lists +<ciso646> as a C++ header.</p> + +<p>I don't find any other mention of <ciso646>, or any mention of +<iso646.h>, in clauses 17 thorough 27. That implies that the +contents of <ciso646> are the same as C header <iso646.h>.</p> + +<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2 +"Header <iso646.h>" says that the alternative tokens are not +defined as macros in <ciso646>, but does not mention the contents +of <iso646.h>.</p> + +<p>I don't find any normative text to support C.2.2.2.</p> + + + +<p><b>Proposed resolution:</b></p> +<p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after + paragraph 6 (the one about functions must be functions):</p> + +<blockquote> +<p>Identifiers that are keywords or operators in C++ shall not be defined +as macros in C++ standard library headers. +[Footnote:In particular, including the standard header <iso646.h> +or <ciso646> has no effect. </p> +</blockquote> + +<p><i>[post-Redmond: Steve provided wording.]</i></p> + + + + + + + +<hr> +<h3><a name="467"></a>467. char_traits::lt(), compare(), and memcmp()</h3> +<p><b>Section:</b> 21.1.3.1 [char.traits.specializations.char] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +Table 37 describes the requirements on Traits::compare() in terms of +those on Traits::lt(). 21.1.3.1, p6 requires char_traits<char>::lt() +to yield the same result as operator<(char, char). +</p> + +<p> +Most, if not all, implementations of char_traits<char>::compare() +call memcmp() for efficiency. However, the C standard requires both +memcmp() and strcmp() to interpret characters under comparison as +unsigned, regardless of the signedness of char. As a result, all +these char_traits implementations fail to meet the requirement +imposed by Table 37 on compare() when char is signed. +</p> + + +<p>Read email thread starting with c++std-lib-13499 for more. </p> + + +<p><b>Proposed resolution:</b></p> + + +<p>Change 21.1.3.1, p6 from</p> +<blockquote><p> + The two-argument members assign, eq, and lt are defined identically + to the built-in operators =, ==, and < respectively. +</p></blockquote> +<p>to</p> +<blockquote><p> + The two-argument member assign is defined identically to + the built-in operator =. The two + argument members eq and lt are defined identically to + the built-in operators == and < for type unsigned char. +</p></blockquote> + +<p><i>[Redmond: The LWG agreed with this general direction, but we + also need to change <tt>eq</tt> to be consistent with this change. + Post-Redmond: Martin provided wording.]</i></p> + + + + + + +<hr> +<h3><a name="468"></a>468. unexpected consequences of ios_base::operator void*()</h3> +<p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#iostate.flags">issues</a> in [iostate.flags].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>The program below is required to compile but when run it typically +produces unexpected results due to the user-defined conversion from +std::cout or any object derived from basic_ios to void*. +</p> + +<pre> #include <cassert> + #include <iostream> + + int main () + { + assert (std::cin.tie () == std::cout); + // calls std::cout.ios::operator void*() + } +</pre> + + +<p><b>Proposed resolution:</b></p> + +<p> +Replace std::basic_ios<charT, traits>::operator void*() with another +conversion operator to some unspecified type that is guaranteed not +to be convertible to any other type except for bool (a pointer-to-member +might be one such suitable type). In addition, make it clear that the +pointer type need not be a pointer to a complete type and when non-null, +the value need not be valid. +</p> + +<p>Specifically, change in [lib.ios] the signature of</p> +<pre> operator void*() const; +</pre> +<p>to</p> +<pre> operator unspecified-bool-type() const; +</pre> +<p>and change [lib.iostate.flags], p1 from</p> +<pre> operator void*() const; +</pre> +<p>to</p> +<pre>operator unspecified-bool-type() const; + + -1- Returns: if fail() then a value that will evaluate false in a + boolean context; otherwise a value that will evaluate true in a + boolean context. The value type returned shall not be + convertible to int. + + -2- [Note: This conversion can be used in contexts where a bool + is expected (e.g., an if condition); however, implicit + conversions (e.g., to int) that can occur with bool are not + allowed, eliminating some sources of user error. One possible + implementation choice for this type is pointer-to-member. - end + note] +</pre> + +<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p> + +<p><i>[Lillehammer: Doug provided revised wording for + "unspecified-bool-type".]</i></p> + + + + + + + + +<hr> +<h3><a name="469"></a>469. vector<bool> ill-formed relational operators</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#DR">DR</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#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#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +The overloads of relational operators for vector<bool> specified +in [lib.vector.bool] are redundant (they are semantically identical +to those provided for the vector primary template) and may even be +diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation +in c++std-lib-13647). +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Remove all overloads of overloads of relational operators for +vector<bool> from [lib.vector.bool]. +</p> + + + + +<hr> +<h3><a name="474"></a>474. confusing Footnote 297</h3> +<p><b>Section:</b> 27.6.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +I think Footnote 297 is confused. The paragraph it applies to seems +quite clear in that widen() is only called if the object is not a char +stream (i.e., not basic_ostream<char>), so it's irrelevant what the +value of widen(c) is otherwise. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +I propose to strike the Footnote. +</p> + + + + +<hr> +<h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</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#WP">WP</a> + <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 2004-07-09</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It is not clear whether the function object passed to for_each is allowed to +modify the elements of the sequence being iterated over. +</p> + +<p> +for_each is classified without explanation in [lib.alg.nonmodifying], "25.1 +Non-modifying sequence operations". 'Non-modifying sequence operation' is +never defined. +</p> + +<p> +25(5) says: "If an algorithm's Effects section says that a value pointed to +by any iterator passed as an argument is modified, then that algorithm has +an additional type requirement: The type of that argument shall satisfy the +requirements of a mutable iterator (24.1)." +</p> + +<p>for_each's Effects section does not mention whether arguments can be +modified:</p> + +<blockquote><p> + "Effects: Applies f to the result of dereferencing every iterator in the + range [first, last), starting from first and proceeding to last - 1." +</p></blockquote> + +<p> +Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in +the sense that neither the algorithms themselves nor the function objects +passed to the algorithms may modify the sequences or elements in any way. +This DR affects only for_each. +</p> + +<p> +We suspect that for_each's classification in "non-modifying sequence +operations" means that the algorithm itself does not inherently modify the +sequence or the elements in the sequence, but that the function object +passed to it may modify the elements it operates on. +</p> + +<p> +The original STL document by Stepanov and Lee explicitly prohibited the +function object from modifying its argument. +The "obvious" implementation of for_each found in several standard library +implementations, however, does not impose this restriction. +As a result, we suspect that the use of for_each with function objects that modify +their arguments is wide-spread. +If the restriction was reinstated, all such code would become non-conforming. +Further, none of the other algorithms in the Standard +could serve the purpose of for_each (transform does not guarantee the order in +which its function object is called). +</p> + +<p> +We suggest that the standard be clarified to explicitly allow the function object +passed to for_each modify its argument.</p> + + + +<p><b>Proposed resolution:</b></p> +<p>Add a nonnormative note to the Effects in 25.1.4 [alg.foreach]: If +the type of 'first' satisfies the requirements of a mutable iterator, +'f' may apply nonconstant functions through the dereferenced iterators +passed to it. +</p> + + + +<p><b>Rationale:</b></p> +<p>The LWG believes that nothing in the standard prohibits function + objects that modify the sequence elements. The problem is that + for_each is in a secion entitled "nonmutating algorithms", and the + title may be confusing. A nonnormative note should clarify that.</p> + + + + + +<hr> +<h3><a name="478"></a>478. Should forward iterator requirements table have a line for r->m?</h3> +<p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-11</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p> +<p><b>Discussion:</b></p> +<p> +The Forward Iterator requirements table contains the following: +</p> +<pre> expression return type operational precondition + semantics + ========== ================== =========== ========================== + a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined. + otherwise const U& + + r->m U& (*r).m pre: (*r).m is well-defined. +</pre> + +<p>The second line may be unnecessary. Paragraph 11 of + [lib.iterator.requirements] says: +</p> + +<blockquote><p> + In the following sections, a and b denote values of type const X, n + denotes a value of the difference type Distance, u, tmp, and m + denote identifiers, r denotes a value of X&, t denotes a value of + value type T, o denotes a value of some type that is writable to + the output iterator. +</p></blockquote> + +<p> +Because operators can be overloaded on an iterator's const-ness, the +current requirements allow iterators to make many of the operations +specified using the identifiers a and b invalid for non-const +iterators.</p> + +<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p> + + +<p><b>Proposed resolution:</b></p> + +<p>Remove the "r->m" line from the Forward Iterator requirements +table. Change</p> +<blockquote><p> + "const X" +</p></blockquote> + +<p> to </p> + +<blockquote><p> + "X or const X" +</p></blockquote> + +<p>in paragraph 11 of [lib.iterator.requirements].</p> + + + + +<p><b>Rationale:</b></p> +<p> +This is a defect because it constrains an lvalue to returning a modifiable lvalue. +</p> + + + + + +<hr> +<h3><a name="488"></a>488. rotate throws away useful information</h3> +<p><b>Section:</b> 25.2.11 [alg.rotate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2004-11-22</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +rotate takes 3 iterators: first, middle and last which point into a +sequence, and rearranges the sequence such that the subrange [middle, +last) is now at the beginning of the sequence and the subrange [first, +middle) follows. The return type is void. +</p> + +<p> +In many use cases of rotate, the client needs to know where the +subrange [first, middle) starts after the rotate is performed. This +might look like: +</p> +<pre> rotate(first, middle, last); + Iterator i = advance(first, distance(middle, last)); +</pre> + +<p> +Unless the iterators are random access, the computation to find the +start of the subrange [first, middle) has linear complexity. However, +it is not difficult for rotate to return this information with +negligible additional computation expense. So the client could code: +</p> +<pre> Iterator i = rotate(first, middle, last); +</pre> + +<p> +and the resulting program becomes significantly more efficient. +</p> + +<p> +While the backwards compatibility hit with this change is not zero, it +is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is +a significant benefit to the change. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p>In 25 [algorithms] p2, change:</p> + +<blockquote><pre> template<class ForwardIterator> + <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle, + ForwardIterator last); +</pre></blockquote> + +<p>In 25.2.11 [alg.rotate], change:</p> + +<blockquote><pre> template<class ForwardIterator> + <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle, + ForwardIterator last); +</pre></blockquote> + +<p>In 25.2.11 [alg.rotate] insert a new paragraph after p1:</p> + +<blockquote> +<p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p> +</blockquote> + +<p><i>[ +The LWG agrees with this idea, but has one quibble: we want to make +sure not to give the impression that the function "advance" is +actually called, just that the nth iterator is returned. (Calling +advance is observable behavior, since users can specialize it for +their own iterators.) Howard will provide wording. +]</i></p> + + +<p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p> + + +<p><i>[ +Toronto: moved to Ready. +]</i></p> + + + + + + + +<hr> +<h3><a name="495"></a>495. Clause 22 template parameter requirements</h3> +<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-01-10</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>It appears that there are no requirements specified for many of the +template parameters in clause 22. It looks like this issue has never +come up, except perhaps for Facet.</p> + +<p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions], +either, which is the wording that allows requirements on template +parameters to be identified by name.</p> + +<p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be +changed to cover clause 22. A better change, which will cover us in +the future, would be to say that it applies to all the library +clauses. Then if a template gets added to any library clause we are +covered.</p> + +<p>charT, InputIterator, and other names with requirements defined +elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix. +But there are a few template arguments names which I don't think have +requirements given elsewhere:</p> + +<ul> +<li>internT and externT. The fix is to add wording saying that internT +and externT must meet the same requirements as template arguments +named charT.</li> + +<li>stateT. I'm not sure about this one. There already is some wording, +but it seems a bit vague.</li> + +<li>Intl. [lib.locale.moneypunct.byname] The fix for this one is to +rename "Intl" to "International". The name is important because other +text identifies the requirements for the name International but not +for Intl.</li> +</ul> + +<p><b>Proposed resolution:</b></p> +<p>Change 17.3.2.1 [type.descriptions], paragraph 1, from:</p> +<blockquote><p> +The Requirements subclauses may describe names that are used to +specify constraints on template arguments.153) These names are used in +clauses 20, 23, 25, and 26 to describe the types that may be supplied +as arguments by a C++ program when instantiating template components +from the library. +</p></blockquote> +<p>to:</p> +<blockquote><p> +The Requirements subclauses may describe names that are used to +specify constraints on template arguments.153) These names are used in +library clauses to describe the types that may be supplied as +arguments by a C++ program when instantiating template components from +the library. +</p></blockquote> + +<p>In the front matter of class 22, locales, add:</p> +<blockquote><p> +Template parameter types internT and externT shall meet the +requirements of charT (described in 21 [strings]). +</p></blockquote> + + +<p><b>Rationale:</b></p> +<p> + Again, a blanket clause isn't blanket enough. Also, we've got a + couple of names that we don't have blanket requirement statements + for. The only issue is what to do about stateT. This wording is + thin, but probably adequate.</p> + + + + + +<hr> +<h3><a name="496"></a>496. Illegal use of "T" in vector<bool></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#WP">WP</a> + <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 2005-02-10</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the synopsis of the std::vector<bool> specialisation in 23.2.6 [vector], +the non-template assign() function has the signature</p> + +<pre> void assign( size_type n, const T& t ); +</pre> + +<p>The type, T, is not defined in this context.</p> + + +<p><b>Proposed resolution:</b></p> +<p>Replace "T" with "value_type".</p> + + + + + +<hr> +<h3><a name="497"></a>497. meaning of numeric_limits::traps for floating point types</h3> +<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-03-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + +<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p> + +<blockquote> +<p>static const bool traps;<br> +-59- true if trapping is implemented for the type.204) +<br> +Footnote 204: Required by LIA-1. +</p> +</blockquote> + +<p>It's not clear what is meant by "is implemented" here.</p> + +<p> +In the context of floating point numbers it seems reasonable to expect +to be able to use traps to determine whether a program can "safely" use +infinity(), quiet_NaN(), etc., in arithmetic expressions, that is +without causing a trap (i.e., on UNIX without having to worry about +getting a signal). When traps is true, I would expect any of the +operations in section 7 of IEEE 754 to cause a trap (and my program +to get a SIGFPE). So, for example, on Alpha, I would expect traps +to be true by default (unless I compiled my program with the -ieee +option), false by default on most other popular architectures, +including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require +traps to be explicitly enabled by the program. +</p> + +<p> +Another possible interpretation of p59 is that traps should be true +on any implementation that supports traps regardless of whether they +are enabled by default or not. I don't think such an interpretation +makes the traps member very useful, even though that is how traps is +implemented on several platforms. It is also the only way to implement +traps on platforms that allow programs to enable and disable trapping +at runtime. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Change p59 to read:</p> +<blockquote><p>True if, at program startup, there exists a value of the type that + would cause an arithmetic operation using that value to trap.</p></blockquote> + + +<p><b>Rationale:</b></p> +<p> + Real issue, since trapping can be turned on and off. Unclear what a + static query can say about a dynamic issue. The real advice we should + give users is to use cfenv for these sorts of queries. But this new + proposed resolution is at least consistent and slightly better than + nothing.</p> + + + + + +<hr> +<h3><a name="505"></a>505. Result_type in random distribution requirements</h3> +<p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Table 17: Random distribution requirements +</p> +<p> +Row 1 requires that each random distribution provide a nested type "input_type"; +this type denotes the type of the values that the distribution consumes. +</p> +<p> +Inspection of all distributions in [tr.rand.dist] reveals that each distribution +provides a second typedef ("result_type") that denotes the type of the values the +distribution produces when called. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +It seems to me that this is also a requirement +for all distributions and should therefore be indicated as such via a new second +row to this table 17: +</p> +<table border="1" cellpadding="5"> +<tbody><tr><td>X::result_type</td><td>T</td><td>---</td><td>compile-time</td></tr> +</tbody></table> + +<p><i>[ +Berlin: Voted to WP. N1932 adopts the proposed resolution: see Table 5 row 1. +]</i></p> + + + + + + + +<hr> +<h3><a name="507"></a>507. Missing requirement for variate_generator::operator()</h3> +<p><b>Section:</b> 26.4 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Paragraph 11 of [tr.rand.var] equires that the member template +</p> +<blockquote><pre>template<class T> result_type operator() (T value); +</pre></blockquote> +<p> +return +</p> +<blockquote><pre>distribution()(e, value) +</pre></blockquote> +<p> +However, not all distributions have an operator() with a corresponding signature. +</p> + +<p><i>[ +Berlin: As a working group we voted in favor of N1932 which makes this moot: +variate_generator has been eliminated. Then in full committee we voted to give +this issue WP status (mistakenly). +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +We therefore recommend that we insert the following precondition before paragraph 11: +</p> +<blockquote><p> +Precondition: <tt>distribution().operator()(e,value)</tt> is well-formed. +</p></blockquote> + + + + + +<hr> +<h3><a name="508"></a>508. Bad parameters for ranlux64_base_01</h3> +<p><b>Section:</b> 26.4.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The fifth of these engines with predefined parameters, ranlux64_base_01, +appears to have an unintentional error for which there is a simple correction. +The two pre-defined subtract_with_carry_01 engines are given as: +</p> +<blockquote><pre>typedef subtract_with_carry_01<float, 24, 10, 24> ranlux_base_01; +typedef subtract_with_carry_01<double, 48, 10, 24> ranlux64_base_01; +</pre></blockquote> +<p> +We demonstrate below that ranlux64_base_01 fails to meet the intent of the +random number generation proposal, but that the simple correction to +</p> +<blockquote><pre>typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01; +</pre></blockquote> +<p> +does meet the intent of defining well-known good parameterizations. +</p> +<p> +The ranlux64_base_01 engine as presented fails to meet the intent for +predefined engines, stated in proposal N1398 (section E): +</p> +<blockquote><p> +In order to make good random numbers available to a large number of library +users, this proposal not only defines generic random-number engines, but also +provides a number of predefined well-known good parameterizations for those. +</p></blockquote> +<p> +The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very +long period and so meets this criterion. This property makes it suitable for +use in the excellent discard_block engines defined subsequently. The proof +of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s) ++ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01, +as defined in [tr.rand.eng.sub1]). +</p> +<p> +The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10. +For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though +explicit factorization would be a challenge). In consequence, while it is +certainly possible for some seeding states that this engine would have a very +long period, it is not at all "well-known" that this is the case. The intent +in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy +use in the physics community. This is isomorphic to the predefined ranlux_base_01, +but exploits the ability of double variables to hold (at least) 48 bits of mantissa, +to deliver 48 random bits at a time rather than 24. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +To achieve this intended behavior, the correct template parameteriztion would be: +</p> +<blockquote><pre>typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01; +</pre></blockquote> +<p> +The sequence of mantissa bits delivered by this is isomorphic (treating each +double as having the bits of two floats) to that delivered by ranlux_base_01. +</p> +<p> +<b>References:</b> +</p> +<ol> +<li>F. James, Comput. Phys. Commun. 60(1990) 329</li> +<li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li> +<li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li> +</ol> + +<p><i>[ +Berlin: Voted to WP. N1932 adopts the proposed resolution in 26.3.5, +just above paragraph 5. +]</i></p> + + + + + + + +<hr> +<h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3> +<p><b>Section:</b> 23.1.5 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Issue 371 deals with stability of multiset/multimap under insert and erase +(i.e. do they preserve the relative order in ranges of equal elements). +The same issue applies to unordered_multiset and unordered_multimap. +</p> +<p><i>[ +Moved to open (from review): There is no resolution. +]</i></p> + + +<p><i>[ +Toronto: We have a resolution now. Moved to Review. Some concern was noted +as to whether this conflicted with existing practice or not. An additional +concern was in specifying (partial) ordering for an unordered container. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +Wording for the proposed resolution is taken from the equivalent text for associative containers. +</p> + +<p> +Change 23.1.5 [unord.req], Unordered associative containers, paragraph 6 to: +</p> + +<blockquote><p> +An unordered associative container supports <i>unique</i> keys if it may +contain at most one element for each key. Otherwise, it supports <i>equivalent +keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support +unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt> +support equivalent keys. In containers that support equivalent keys, elements +with equivalent keys are adjacent to each other. <ins>For +<tt>unordered_multiset</tt> +and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt> +preserve the relative ordering of equivalent elements.</ins> +</p></blockquote> + +<p> +Change 23.1.5 [unord.req], Unordered associative containers, paragraph 8 to: +</p> + +<blockquote> +<p>The elements of an unordered associative container are organized into <i> +buckets</i>. Keys with the same hash code appear in the same bucket. The number +of buckets is automatically increased as elements are added to an unordered +associative container, so that the average number of elements per bucket is kept +below a bound. Rehashing invalidates iterators, changes ordering between +elements, and changes which buckets elements appear in, but does not invalidate +pointers or references to elements. <ins>For <tt>unordered_multiset</tt> +and <tt>unordered_multimap</tt>, rehashing +preserves the relative ordering of equivalent elements.</ins></p> +</blockquote> + + + + + + +<hr> +<h3><a name="519"></a>519. Data() undocumented</h3> +<p><b>Section:</b> 23.2.1 [array], TR1 6.2.2 [tr.array.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Pete Becker <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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>array<>::data()</tt> is present in the class synopsis, but not documented. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add a new section, after 6.2.2.3: +</p> +<blockquote><pre>T* data() +const T* data() const; +</pre></blockquote> +<p> +<b>Returns:</b> <tt>elems</tt>. +</p> +<p> +Change 6.2.2.4/2 to: +</p> +<blockquote><p> +In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value +of <tt>data()</tt> is unspecified. +</p></blockquote> + + + + + +<hr> +<h3><a name="520"></a>520. Result_of and pointers to data members</h3> +<p><b>Section:</b> 20.6.11.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the original proposal for binders, the return type of bind() when +called with a pointer to member data as it's callable object was +defined to be mem_fn(ptr); when Peter Dimov and I unified the +descriptions of the TR1 function objects we hoisted the descriptions +of return types into the INVOKE pseudo-function and into result_of. +Unfortunately, we left pointer to member data out of result_of, so +bind doesn't have any specified behavior when called with a pointer +to member data. +</p> + + +<p><b>Proposed resolution:</b></p> +<p><i>[ +Pete and Peter will provide wording. +]</i></p> + + +<p> +In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2: +</p> +<ol start="3"> +<li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt> +shall be <tt><i>cv</i> R&</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&</tt>, +<tt>R</tt> otherwise.</li> +</ol> + +<p><i>[ +Peter provided wording. +]</i></p> + + + + + + + +<hr> +<h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3> +<p><b>Section:</b> 20.6.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +2.1.2/3, second bullet item currently says that reference_wrapper<T> is +derived from unary_function<T, R> if T is: +</p> +<blockquote><p> +a pointer to member function type with cv-qualifier cv and no arguments; +the type T1 is cv T* and R is the return type of the pointer to member function; +</p></blockquote> +<p> +The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member +function. It should be a pointer to the class that T is a pointer to member of. +Like this: +</p> +<blockquote><p> +a pointer to a member function R T0::f() cv (where cv represents the member +function's cv-qualifiers); the type T1 is cv T0* +</p></blockquote> +<p> +Similarly, bullet item 2 in 2.1.2/4 should be: +</p> +<blockquote><p> +a pointer to a member function R T0::f(T2) cv (where cv represents the member +function's cv-qualifiers); the type T1 is cv T0* +</p></blockquote> + + +<p><b>Proposed resolution:</b></p> + +<p> +Change bullet item 2 in 2.1.2/3: +</p> + +<blockquote> +<ul> +<li> +a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments; +the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return +type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt> +(where <tt><i>cv</i></tt> represents the member function's cv-qualifiers); +the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins> +</li> +</ul> +</blockquote> + +<p> +Change bullet item 2 in 2.1.2/4: +</p> + +<blockquote> +<ul> +<li> +a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument +of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and +<tt>R</tt> is the return type of the pointer to member function</del> +<ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member +function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins> +</li> +</ul> +</blockquote> + + + + + + +<hr> +<h3><a name="524"></a>524. regex named character classes and case-insensitivity don't mix</h3> +<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +This defect is also being discussed on the Boost developers list. The +full discussion can be found here: +http://lists.boost.org/boost/2005/07/29546.php +</p> +<p> +-- Begin original message -- +</p> +<p> +Also, I may have found another issue, closely related to the one under +discussion. It regards case-insensitive matching of named character +classes. The regex_traits<> provides two functions for working with +named char classes: lookup_classname and isctype. To match a char class +such as [[:alpha:]], you pass "alpha" to lookup_classname and get a +bitmask. Later, you pass a char and the bitmask to isctype and get a +bool yes/no answer. +</p> +<p> +But how does case-insensitivity work in this scenario? Suppose we're +doing a case-insensitive match on [[:lower:]]. It should behave as if it +were [[:lower:][:upper:]], right? But there doesn't seem to be enough +smarts in the regex_traits interface to do this. +</p> +<p> +Imagine I write a traits class which recognizes [[:fubar:]], and the +"fubar" char class happens to be case-sensitive. How is the regex engine +to know that? And how should it do a case-insensitive match of a +character against the [[:fubar:]] char class? John, can you confirm this +is a legitimate problem? +</p> +<p> +I see two options: +</p> +<p> +1) Add a bool icase parameter to lookup_classname. Then, +lookup_classname( "upper", true ) will know to return lower|upper +instead of just upper. +</p> +<p> +2) Add a isctype_nocase function +</p> +<p> +I prefer (1) because the extra computation happens at the time the +pattern is compiled rather than when it is executed. +</p> +<p> +-- End original message -- +</p> + +<p> +For what it's worth, John has also expressed his preference for option +(1) above. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3> +<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-01</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The original bind proposal gives the guarantee that tr1::bind(f, t1, +..., tN) does not throw when the copy constructors of f, t1, ..., tN +don't. +</p> + +<p> +This guarantee is not present in the final version of TR1. +</p> + +<p> +I'm pretty certain that we never removed it on purpose. Editorial omission? :-) +</p> + +<p><i>[ +Berlin: not quite editorial, needs proposed wording. +]</i></p> + +<p><i>[ +Batavia: Doug to translate wording to variadic templates. +]</i></p> + + +<p><i>[ +Toronto: We agree but aren't quite happy with the wording. The "t"'s no +longer refer to anything. Alan to provide improved wording. +]</i></p> + + + +<p><i>[ +Pre-Bellevue: Alisdair provided wording. +]</i></p> + + +<p> +TR1 proposed resolution: +</p> + +<blockquote> +<p> +In TR1 3.6.3 [tr.func.bind.bind], add a new paragraph after p2: +</p> +<blockquote><p> +<i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt> +throws an exception. +</p></blockquote> + +<p> +Add a new paragraph after p4: +</p> +<blockquote><p> +<i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt> +throws an exception. +</p></blockquote> + +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p2: +</p> + +<blockquote> +<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types +in the <tt>BoundArgs...</tt> pack expansion throws an exception. +</blockquote> + +<p> +In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p4: +</p> + +<blockquote> +<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types +in the <tt>BoundArgs...</tt> pack expansion throws an exception. +</blockquote> + + + + + + +<hr> +<h3><a name="530"></a>530. Must elements of a string be contiguous?</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#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-11-15</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated + that the elements of a vector must be stored in contiguous memory. + Should the same also apply to <tt>basic_string</tt>?</p> + +<p>We almost require contiguity already. Clause 23.3.4 [multiset] + defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing + is a similar guarantee if we access the string's elements via the + iterator interface.</p> + +<p>Given the existence of <tt>data()</tt>, and the definition of + <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>, + I don't believe it's possible to write a useful and standard- + conforming <tt>basic_string</tt> that isn't contiguous. I'm not + aware of any non-contiguous implementation. We should just require + it. +</p> + + +<p><b>Proposed resolution:</b></p> +<p>Add the following text to the end of 21.3 [basic.string], +paragraph 2. </p> + +<blockquote> + <p>The characters in a string are stored contiguously, meaning that if + <tt>s</tt> is a <tt>basic_string<charT, Allocator></tt>, then + it obeys the identity + <tt>&*(s.begin() + n) == &*s.begin() + n</tt> + for all <tt>0 <= n < s.size()</tt>. + </p> +</blockquote> + + +<p><b>Rationale:</b></p> +<p> +Not standardizing this existing practice does not give implementors more +freedom. We thought it might a decade ago. But the vendors have spoken +both with their implementations, and with their voice at the LWG +meetings. The implementations are going to be contiguous no matter what +the standard says. So the standard might as well give string clients +more design choices. +</p> + + + + + +<hr> +<h3><a name="531"></a>531. array forms of unformatted input functions</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-23</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The array forms of unformatted input functions don't seem to have well-defined +semantics for zero-element arrays in a couple of cases. The affected ones +(<tt>istream::get()</tt> and <tt>istream::getline()</tt>) are supposed to +terminate when <tt>(n - 1)</tt> characters are stored, which obviously can +never be true when <tt>(n == 0)</tt> holds to start with. See +c++std-lib-16071. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +I suggest changing 27.6.1.3, p7 (<tt>istream::get()</tt>), bullet 1 to read: +</p> + <ul> + <li> + <tt>(n < 1)</tt> is true or <tt>(n - 1)</tt> characters + are stored; + </li> + </ul> +<p> +Change 27.6.1.3, p9: +</p> + +<blockquote><p> +If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which +may throw <tt>ios_base::failure</tt> (27.4.4.3)). In any case, <ins>if <tt>(n +> 0)</tt> is true</ins> it then stores a null character into the next +successive location of the array. +</p></blockquote> + + <p> + +and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to: + + </p> + <ul> + <li> + <tt>(n < 1)</tt> is true or <tt>(n - 1)</tt> characters + are stored (in which case the function calls + <tt>setstate(failbit)</tt>). + </li> + </ul> + + <p> + +In addition, to clarify that <tt>istream::getline()</tt> must not store the +terminating NUL character unless the the array has non-zero size, Robert +Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read: + + </p> + <blockquote><p> + +In any case, provided <tt>(n > 0)</tt> is true, it then stores a null character +(using charT()) into the next successive location of the array. + + </p></blockquote> + +<p><i>[ +post-Redmond: Pete noticed that the current resolution for <tt>get</tt> requires +writing to out of bounds memory when <tt>n == 0</tt>. Martin provided fix. +]</i></p> + + + + + + + +<hr> +<h3><a name="533"></a>533. typo in 2.2.3.10/1</h3> +<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> + <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-11-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt> +says: +</p> +<blockquote><p> +If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>... +</p></blockquote> +<p> +but <tt>get_deleter</tt> is a free function! +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Therefore, I think should be: +</p> +<blockquote><p> +If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>... +</p></blockquote> + + + + + +<hr> +<h3><a name="534"></a>534. Missing basic_string members</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#WP">WP</a> + <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2005-11-16</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +OK, we all know std::basic_string is bloated and already has way too +many members. However, I propose it is missing 3 useful members that +are often expected by users believing it is a close approximation of the +container concept. All 3 are listed in table 71 as 'optional' +</p> + +<p> +i/ pop_back. +</p> + +<p> +This is the one I feel most strongly about, as I only just discovered it +was missing as we are switching to a more conforming standard library +<g> +</p> + +<p> +I find it particularly inconsistent to support push_back, but not +pop_back. +</p> + +<p> +ii/ back. +</p> + +<p> +There are certainly cases where I want to examine the last character of +a string before deciding to append, or to trim trailing path separators +from directory names etc. *rbegin() somehow feels inelegant. +</p> + +<p> +iii/ front +</p> + +<p> +This one I don't feel strongly about, but if I can get the first two, +this one feels that it should be added as a 'me too' for consistency. +</p> + +<p> +I believe this would be similarly useful to the data() member recently +added to vector, or at() member added to the maps. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following members to definition of class template basic_string, 21.3p7 +</p> +<blockquote><pre>void pop_back () + +const charT & front() const +charT & front() + +const charT & back() const +charT & back() +</pre></blockquote> +<p> +Add the following paragraphs to basic_string description +</p> + +<p> +21.3.4p5 +</p> +<blockquote> +<pre>const charT & front() const +charT & front() +</pre> +<p> +<i>Precondition:</i> <tt>!empty()</tt> +</p> +<p> +<i>Effects:</i> Equivalent to <tt>operator[](0)</tt>. +</p> +</blockquote> + +<p> +21.3.4p6 +</p> +<blockquote> +<pre>const charT & back() const +charT & back() +</pre> +<p> +<i>Precondition:</i> <tt>!empty()</tt> +</p> +<p> +<i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>. +</p> +</blockquote> + +<p> +21.3.5.5p10 +</p> +<blockquote> +<pre>void pop_back () +</pre> +<p> +<i>Precondition:</i> <tt>!empty()</tt> +</p> +<p> +<i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>. +</p> +</blockquote> + +<p> +Update Table 71: (optional sequence operations) +Add basic_string to the list of containers for the following operations. +</p> +<blockquote><pre>a.front() +a.back() +a.push_back() +a.pop_back() +a[n] +</pre></blockquote> + +<p><i>[ +Berlin: Has support. Alisdair provided wording. +]</i></p> + + + + + + +<hr> +<h3><a name="535"></a>535. std::string::swap specification poorly worded</h3> +<p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-12-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +std::string::swap currently says for effects and postcondition: +</p> + +<blockquote> +<p> +<i>Effects:</i> Swaps the contents of the two strings. +</p> + +<p> +<i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>, +<tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>. +</p> +</blockquote> + +<p> +Specifying both Effects and Postcondition seems redundant, and the postcondition +needs to be made stronger. Users would be unhappy if the characters were not in +the same order after the swap. +</p> + + +<p><b>Proposed resolution:</b></p> +<blockquote> +<p> +<del><i>Effects:</i> Swaps the contents of the two strings.</del> +</p> + +<p> +<i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins> +characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>, +<tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that +<del>were</del> <ins>was</ins> in <tt>*this</tt>. +</p> +</blockquote> + + + + + +<hr> +<h3><a name="537"></a>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</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#WP">WP</a> + <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-12</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the most recent working draft, I'm still seeing: +</p> + +<blockquote><pre>seekg(off_type& off, ios_base::seekdir dir) +</pre></blockquote> + +<p> +and +</p> + +<blockquote><pre>seekp(pos_type& pos) + +seekp(off_type& off, ios_base::seekdir dir) +</pre></blockquote> + +<p> +that is, by reference off and pos arguments. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +After 27.6.1.3p42 change: +</p> + +<blockquote><pre>basic_istream<charT,traits>& seekg(off_type<del>&</del> <i>off</i>, ios_base::seekdir <i>dir</i>); +</pre></blockquote> + +<p> +After 27.6.2.4p1 change: +</p> + +<blockquote><pre>basic_ostream<charT,traits>& seekp(pos_type<del>&</del> <i>pos</i>); +</pre></blockquote> + +<p> +After 27.6.2.4p3 change: +</p> + +<blockquote><pre>basic_ostream<charT,traits>& seekp(off_type<del>&</del> <i>off</i>, ios_base::seekdir <i>dir</i>); +</pre></blockquote> + + + + + +<hr> +<h3><a name="538"></a>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3> +<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I believe I botched the resolution of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241"> +241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now +has WP status. +</p> + +<p> +This talks about <tt>unique_copy</tt> requirements and currently reads: +</p> + +<blockquote><p> +-5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and +<tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt> +shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> shall +be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the +requirements of forward iterator then the value type of <tt>InputIterator</tt> +must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required. +</p></blockquote> + +<p> +The problem (which Paolo discovered) is that when the iterators are at their +most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want +<tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and +<tt>CopyAssignable</tt> (for the most efficient implementation). However this +proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>, +and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>. +This latter requirement does not necessarily imply that you can: +</p> + +<blockquote><pre>*<i>first</i> = *<i>first</i>; +</pre></blockquote> + + +<p><b>Proposed resolution:</b></p> +<blockquote><p> +-5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and +<tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt> +shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> +shall +be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the +requirements of forward iterator then the <del>value type</del> +<ins><tt>value_type</tt></ins> of <tt>InputIterator</tt> +must be CopyConstructible (20.1.3) <ins>and Assignable</ins>. +Otherwise CopyConstructible is not required. +</p></blockquote> + + + + + +<hr> +<h3><a name="540"></a>540. shared_ptr<void>::operator*()</h3> +<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-15</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6 +that talks about the operator*() member function of shared_ptr: +</p> + +<blockquote><p> + Notes: When T is void, attempting to instantiate this member function + renders the program ill-formed. [Note: Instantiating shared_ptr<void> + does not necessarily result in instantiating this member function. + --end note] +</p></blockquote> + +<p> +with the requirement in temp.inst, p1: +</p> + +<blockquote><p> + The implicit instantiation of a class template specialization causes + the implicit instantiation of the declarations, but not of the + definitions... +</p></blockquote> + +<p> +I assume that what the note is really trying to say is that +"instantiating shared_ptr<void> *must not* result in instantiating +this member function." That is, that this function must not be +declared a member of shared_ptr<void>. Is my interpretation +correct? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 2.2.3.5p6 +</p> + +<blockquote><p> +-6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate +this member function renders the program ill-formed. [<i>Note:</i> +Instantiating <tt>shared_ptr<void></tt> does not necessarily result in +instantiating this member function. <i>--end note</i>]</del> <ins>it is +unspecified whether this member function is declared or not, and if so, what its +return type is, except that the declaration (although not necessarily the +definition) of the function shall be well-formed.</ins> +</p></blockquote> + + + + + + +<hr> +<h3><a name="541"></a>541. shared_ptr template assignment and void</h3> +<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-16</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Is the void specialization of the template assignment operator taking +a shared_ptr<void> as an argument supposed be well-formed? +</p> +<p> +I.e., is this snippet well-formed: +</p> +<blockquote><pre>shared_ptr<void> p; +p.operator=<void>(p); +</pre></blockquote> + +<p> +Gcc complains about auto_ptr<void>::operator*() returning a reference +to void. I suspect it's because shared_ptr has two template assignment +operators, one of which takes auto_ptr, and the auto_ptr template gets +implicitly instantiated in the process of overload resolution. +</p> + +<p> +The only way I see around it is to do the same trick with auto_ptr<void> +operator*() as with the same operator in shared_ptr<void>. +</p> + +<p> +PS Strangely enough, the EDG front end doesn't mind the code, even +though in a small test case (below) I can reproduce the error with +it as well. +</p> + +<blockquote><pre>template <class T> +struct A { T& operator*() { return *(T*)0; } }; + +template <class T> +struct B { + void operator= (const B&) { } + template <class U> + void operator= (const B<U>&) { } + template <class U> + void operator= (const A<U>&) { } +}; + +int main () +{ + B<void> b; + b.operator=<void>(b); +} +</pre></blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +In [lib.memory] change: +</p> +<blockquote><pre>template<class X> class auto_ptr; +<ins>template<> class auto_ptr<void>;</ins> +</pre></blockquote> + +<p> +In [lib.auto.ptr]/2 add the following before the last closing brace: +</p> + +<blockquote><pre>template<> class auto_ptr<void> +{ +public: + typedef void element_type; +}; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="542"></a>542. shared_ptr observers</h3> +<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-18</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Peter Dimov wrote: +To: C++ libraries mailing list +Message c++std-lib-15614 +[...] +The intent is for both use_count() and unique() to work in a threaded environment. +They are intrinsically prone to race conditions, but they never return garbage. +</p> + +<p> +This is a crucial piece of information that I really wish were +captured in the text. Having this in a non-normative note would +have made everything crystal clear to me and probably stopped +me from ever starting this discussion :) Instead, the sentence +in p12 "use only for debugging and testing purposes, not for +production code" very strongly suggests that implementations +can and even are encouraged to return garbage (when threads +are involved) for performance reasons. +</p> +<p> +How about adding an informative note along these lines: +</p> +<blockquote><p> + Note: Implementations are encouraged to provide well-defined + behavior for use_count() and unique() even in the presence of + multiple threads. +</p></blockquote> +<p> +I don't necessarily insist on the exact wording, just that we +capture the intent. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.7.12.2.5 [util.smartptr.shared.obs] p12: +</p> +<blockquote><p> +[<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for +debugging and testing purposes, not for production code.</del> --<i>end note</i>] +</p></blockquote> + +<p> +Change 20.7.12.3.5 [util.smartptr.weak.obs] p3: +</p> +<blockquote><p> +[<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for +debugging and testing purposes, not for production code.</del> --<i>end note</i>] +</p></blockquote> + + + + + +<hr> +<h3><a name="543"></a>543. valarray slice default constructor</h3> +<p><b>Section:</b> 26.5.4 [class.slice] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2005-11-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +If one explicitly constructs a slice or glice with the default +constructor, does the standard require this slice to have any usable +state? It says "creates a slice which specifies no elements", which +could be interpreted two ways: +</p> +<ol> +<li>There are no elements to which the slice refers (i.e. undefined).</li> +<li>The slice specifies an array with no elements in it (i.e. defined).</li> +</ol> +<p> +Here is a bit of code to illustrate: +</p> +<blockquote><pre>#include <iostream> +#include <valarray> + +int main() +{ + std::valarray<int> v(10); + std::valarray<int> v2 = v[std::slice()]; + std::cout << "v[slice()].size() = " << v2.size() << '\n'; +} +</pre></blockquote> + +<p> +Is the behavior undefined? Or should the output be: +</p> + +<blockquote><pre>v[slice()].size() = 0 +</pre></blockquote> + +<p> +There is a similar question and wording for gslice at 26.3.6.1p1. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p><i>[Martin suggests removing the second sentence in 26.5.4.1 [cons.slice] as well.]</i></p> + + +<p> +Change 26.5.4.1 [cons.slice]: +</p> + +<blockquote><p> +1 - <del>The default constructor for <tt>slice</tt> creates a <tt>slice</tt> +which specifies no elements.</del> <ins>The default constructor is equivalent to +<tt>slice(0, 0, 0)</tt>.</ins> A default constructor is provided only to permit +the declaration of arrays of slices. The constructor with arguments for a slice +takes a start, length, and stride parameter. +</p></blockquote> + +<p> +Change 26.5.6.1 [gslice.cons]: +</p> + +<blockquote><p> +1 - <del>The default constructor creates a <tt>gslice</tt> which specifies no +elements.</del> <ins>The default constructor is equivalent to <tt>gslice(0, +valarray<size_t>(), valarray<size_t>())</tt>.</ins> The constructor +with arguments builds a <tt>gslice</tt> based on a specification of start, +lengths, and strides, as explained in the previous section. +</p></blockquote> + + + + + + +<hr> +<h3><a name="545"></a>545. When is a deleter deleted?</h3> +<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if +any, is destroyed. In principle there are two possibilities: it is destroyed +unconditionally whenever ~shared_ptr is executed (which, from an implementation +standpoint, means that the deleter is copied whenever the shared_ptr is copied), +or it is destroyed immediately after the owned pointer is destroyed (which, from +an implementation standpoint, means that the deleter object is shared between +instances). We should say which it is. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add after the first sentence of 20.7.12.2.11 [util.smartptr.getdeleter]/1: +</p> +<blockquote> +<p> +The returned pointer remains valid as long as there exists a <tt>shared_ptr</tt> instance +that owns <tt><i>d</i></tt>. +</p> +<p> +[<i>Note:</i> it is unspecified whether the pointer remains valid longer than that. +This can happen if the implementation doesn't destroy the deleter until all +<tt>weak_ptr</tt> instances in the ownership group are destroyed. <i>-- end note</i>] +</p> +</blockquote> + + + + + +<hr> +<h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-12</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Assuming we adopt the +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C +compatibility package from C99</a> what should be the return type of the +following signature be: +</p> +<blockquote><pre>? pow(float, int); +</pre></blockquote> +<p> +C++03 says that the return type should be <tt>float</tt>. +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf"> +TR1</a> and C90/99 say the return type should be <tt>double</tt>. This can put +clients into a situation where C++03 provides answers that are not as high +quality as C90/C99/TR1. For example: +</p> +<blockquote><pre>#include <math.h> + +int main() +{ + float x = 2080703.375F; + double y = pow(x, 2); +} +</pre></blockquote> +<p> +Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest: +</p> + +<blockquote><pre>y = 4329326534736.390625 +</pre></blockquote> + +<p> +which is exactly right. While C++98/C++03 demands: +</p> + +<blockquote><pre>y = 4329326510080. +</pre></blockquote> + +<p> +which is only approximately right. +</p> + +<p> +I recommend that C++0X adopt the mixed mode arithmetic already adopted by +Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be +<tt>double</tt>. +</p> + +<p><i>[ +Kona (2007): Other functions that are affected by this issue include +<tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in +26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float +nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed +resolution appears above, rather than below, the heading "Proposed +resolution") +]</i></p> + + +<p><i>[ +<p> +Howard, post Kona: +</p> +<blockquote> +<p> +Unfortunately I strongly disagree with a part of the resolution +from Kona. I am moving from New to Open instead of to Review because I do not believe +we have consensus on the intent of the resolution. +</p> +<p> +This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because +the second integral parameter in each of these signatures (from C99) is <b>not</b> a +<i>generic parameter</i> according to C99 7.22p2. The corresponding C++ overloads are +intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>. +</p> +<p> +For similar reasons, I do not believe that the second <tt>long double</tt> parameter of +<tt>nexttoward</tt>, nor the return type of this function, is in error. I believe the +correct signature is: +</p> +<blockquote> +<pre>float nexttoward(float, long double); +</pre> +</blockquote> +<p> +which is what both the C++0X working paper and C99 state (as far as I currently understand). +</p> +<p> +This is really <b>only</b> about <tt>pow(float, int)</tt>. And this is because C++98 took one +route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt><tgmath.h></tt>. +The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99. +</p> +</blockquote> +]</i></p> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +This signature was not picked up from C99. Instead, if one types +pow(2.0f,2), the promotion rules will invoke "double pow(double, +double)", which generally gives special treatment for integral +exponents, preserving full accuracy of the result. New proposed +wording provided. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.7 [c.math] p10: +</p> + +<blockquote> +<p> +The added signatures are: +</p> +<blockquote><pre>... +<del>float pow(float, int);</del> +... +<del>double pow(double, int);</del> +... +<del>long double pow(long double, int);</del> +</pre></blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="551"></a>551. <ccomplex></h3> +<p><b>Section:</b> 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Previously xxx.h was parsable by C++. But in the case of C99's <complex.h> +it isn't. Otherwise we could model it just like <string.h>, <cstring>, <string>: +</p> + +<ul> +<li><string> : C++ API in namespace std</li> +<li><cstring> : C API in namespace std</li> +<li><string.h> : C API in global namespace</li> +</ul> + +<p> +In the case of C's complex, the C API won't compile in C++. So we have: +</p> + +<ul> +<li><complex> : C++ API in namespace std</li> +<li><ccomplex> : ?</li> +<li><complex.h> : ?</li> +</ul> + +<p> +The ? can't refer to the C API. TR1 currently says: +</p> + +<ul> +<li><complex> : C++ API in namespace std</li> +<li><ccomplex> : C++ API in namespace std</li> +<li><complex.h> : C++ API in global namespace</li> +</ul> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.3.11 [cmplxh]: +</p> + +<blockquote> +<p> +The header behaves as if it includes the header +<tt><ccomplex></tt><ins>.</ins><del>, and provides sufficient using +declarations to declare in the global namespace all function and type names +declared or defined in the neader <tt><complex></tt>.</del> +<ins>[<i>Note:</i> <tt><complex.h></tt> does not promote any interface +into the global namespace as there is no C interface to promote. <i>--end +note</i>]</ins> +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="552"></a>552. random_shuffle and its generator</h3> +<p><b>Section:</b> 25.2.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-01-25</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +...is specified to shuffle its range by calling swap but not how +(or even that) it's supposed to use the RandomNumberGenerator +argument passed to it. +</p> +<p> +Shouldn't we require that the generator object actually be used +by the algorithm to obtain a series of random numbers and specify +how many times its operator() should be invoked by the algorithm? +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +for some further discussion. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="559"></a>559. numeric_limits<const T></h3> +<p><b>Section:</b> 18.2.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-19</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +18.2.1 [limits], p2 requires implementations to provide specializations of the +<code>numeric_limits</code> template for each scalar type. While this +could be interepreted to include cv-qualified forms of such types such +an interepretation is not reflected in the synopsis of the +<code><limits></code> header. + + </p> + <p> + +The absence of specializations of the template on cv-qualified forms +of fundamental types makes <code>numeric_limits</code> difficult to +use in generic code where the constness (or volatility) of a type is +not always immediately apparent. In such contexts, the primary +template ends up being instantiated instead of the provided +specialization, typically yielding unexpected behavior. + + </p> + <p> + +Require that specializations of <code>numeric_limits</code> on +cv-qualified fundamental types have the same semantics as those on the +unqualifed forms of the same types. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +Add to the synopsis of the <code><limits></code> header, +immediately below the declaration of the primary template, the +following: +</p> + +<pre> +template <class T> class numeric_limits<const T>; +template <class T> class numeric_limits<volatile T>; +template <class T> class numeric_limits<const volatile T>; + +</pre> + + <p> + +Add a new paragraph to the end of 18.2.1.1 [numeric.limits], with the following +text: + + </p> + <p> + +-new-para- The value of each member of a <code>numeric_limits</code> +specialization on a cv-qualified T is equal to the value of the same +member of <code>numeric_limits<T></code>. + + </p> + +<p><i>[ +Portland: Martin will clarify that user-defined types get cv-specializations +automatically. +]</i></p> + + + + + + + +<hr> +<h3><a name="561"></a>561. inserter overly generic</h3> +<p><b>Section:</b> 24.4.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-21</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The declaration of <tt>std::inserter</tt> is: +</p> + +<blockquote><pre>template <class Container, class Iterator> +insert_iterator<Container> +inserter(Container& x, Iterator i); +</pre></blockquote> + +<p> +The template parameter <tt>Iterator</tt> in this function is completely unrelated +to the template parameter <tt>Container</tt> when it doesn't need to be. This +causes the code to be overly generic. That is, any type at all can be deduced +as <tt>Iterator</tt>, whether or not it makes sense. Now the same is true of +<tt>Container</tt>. However, for every free (unconstrained) template parameter +one has in a signature, the opportunity for a mistaken binding grows geometrically. +</p> + +<p> +It would be much better if <tt>inserter</tt> had the following signature instead: +</p> + +<blockquote><pre>template <class Container> +insert_iterator<Container> +inserter(Container& x, typename Container::iterator i); +</pre></blockquote> + +<p> +Now there is only one free template parameter. And the second argument to +<tt>inserter</tt> must be implicitly convertible to the container's iterator, +else the call will not be a viable overload (allowing other functions in the +overload set to take precedence). Furthermore, the first parameter must have a +nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt> +is not viable. Contrast this with the current situation +where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those +types need not be anything closely related to containers or iterators. +</p> + +<p> +This can adversely impact well written code. Consider: +</p> + +<blockquote><pre>#include <iterator> +#include <string> + +namespace my +{ + +template <class String> +struct my_type {}; + +struct my_container +{ +template <class String> +void push_back(const my_type<String>&); +}; + +template <class String> +void inserter(const my_type<String>& m, my_container& c) {c.push_back(m);} + +} // my + +int main() +{ + my::my_container c; + my::my_type<std::string> m; + inserter(m, c); +} +</pre></blockquote> + +<p> +Today this code fails because the call to <tt>inserter</tt> binds to +<tt>std::inserter</tt> instead of to <tt>my::inserter</tt>. However with the +proposed change <tt>std::inserter</tt> will no longer be a viable function which +leaves only <tt>my::inserter</tt> in the overload resolution set. Everything +works as the client intends. +</p> + +<p> +To make matters a little more insidious, the above example works today if you +simply change the first argument to an rvalue: +</p> + +<blockquote><pre> inserter(my::my_type(), c); +</pre></blockquote> + +<p> +It will also work if instantiated with some string type other than +<tt>std::string</tt> (or any other <tt>std</tt> type). It will also work if +<tt><iterator></tt> happens to not get included. +</p> + +<p> +And it will fail again for such inocuous reaons as <tt>my_type</tt> or +<tt>my_container</tt> privately deriving from any <tt>std</tt> type. +</p> + +<p> +It seems unfortunate that such simple changes in the client's code can result +in such radically differing behavior. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 24.2: +</p> + +<blockquote><p> +<b>24.2 Header</b> <tt><iterator></tt> <b>synopsis</b> +</p> +<blockquote><pre>... +template <class Container<del>, class Iterator</del>> + insert_iterator<Container> inserter(Container& x, <del>Iterator</del> <ins>typename Container::iterator</ins> i); +... +</pre></blockquote> +</blockquote> + +<p> +Change 24.4.2.5: +</p> + +<blockquote><p> +<b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p> +<blockquote><pre>... +template <class Container<del>, class Iterator</del>> + insert_iterator<Container> inserter(Container& x, <del>Iterator</del> <ins>typename Container::iterator</ins> i); +... +</pre></blockquote> +</blockquote> + +<p> +Change 24.4.2.6.5: +</p> + +<blockquote> +<p> +<b>24.4.2.6.5</b> <tt>inserter</tt> +</p> +<pre>template <class Container<del>, class Inserter</del>> + insert_iterator<Container> inserter(Container& x, <del>Inserter</del> <ins>typename Container::iterator</ins> i); +</pre> +<blockquote><p> +-1- <i>Returns:</i> <tt>insert_iterator<Container>(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>. +</p></blockquote> +</blockquote> + + + +<p><i>[ +Kona (2007): This issue will probably be addressed as a part of the +concepts overhaul of the library anyway, but the proposed resolution is +correct in the absence of concepts. Proposed Disposition: Ready +]</i></p> + + + + + +<hr> +<h3><a name="562"></a>562. stringbuf ctor inefficient</h3> +<p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +For better efficiency, the requirement on the stringbuf ctor that +takes a string argument should be loosened up to let it set +<code>epptr()</code> beyond just one past the last initialized +character just like <code>overflow()</code> has been changed to be +allowed to do (see issue 432). That way the first call to +<code>sputc()</code> on an object won't necessarily cause a call to +<code>overflow</code>. The corresponding change should be made to the +string overload of the <code>str()</code> member function. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +Change 27.7.1.1, p3 of the Working Draft, N1804, as follows: + + </p> + +<blockquote><pre>explicit basic_stringbuf(const basic_string<charT,traits,Allocator>& <i>s<del>tr</del></i>, + ios_base::openmode <i>which</i> = ios_base::in | ios_base::out); +</pre> + +<p> +-3- <i>Effects:</i> Constructs an object of class <tt>basic_stringbuf</tt>, +initializing the base class with <tt>basic_streambuf()</tt> +(27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>. +Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of +<i>str</i> into the <tt>basic_stringbuf</tt> underlying character +sequence. If <tt><i>which</i> & ios_base::out</tt> is true, initializes the +output sequence such that <tt>pbase()</tt> points to the first underlying +character, <tt>epptr()</tt> points one past the last underlying character, and +<tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> & ios_base::ate</tt> +is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If +<tt>which & ios_base::in</tt> is true, initializes the input sequence such +that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying +character and <tt>egptr()</tt> points one past the last underlying character.</del> +</p> +</blockquote> + + <p> + +Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to +read: + + </p> +<blockquote> +<p> +-2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the +<tt>basic_stringbuf</tt> underlying character sequence <ins>and +initializes the input and output sequences according to <tt><i>mode</i></tt></ins>. +<del>If +<tt><i>mode</i> & ios_base::out</tt> is true, initializes the output +sequence such that <tt>pbase()</tt> points to the first underlying character, +<tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt> +is equal to <tt>epptr()</tt> if <tt><i>mode</i> & ios_base::in</tt> +is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If +<tt>mode & ios_base::in</tt> is true, initializes the input sequence +such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying +character and <tt>egptr()</tt> points one past the last underlying character.</del> +</p> + + <p> + +<ins>-3- <i>Postconditions:</i> If <code>mode & ios_base::out</code> is true, +<code>pbase()</code> points to the first underlying character and +<code>(epptr() >= pbase() + s.size())</code> holds; in addition, if +<code>mode & ios_base::in</code> is true, <code>(pptr() == pbase() ++ s.data())</code> holds, otherwise <code>(pptr() == pbase())</code> +is true. If <code>mode & ios_base::in</code> is true, +<code>eback()</code> points to the first underlying character, and +<code>(gptr() == eback())</code> and <code>(egptr() == eback() + +s.size())</code> hold.</ins> + + </p> +</blockquote> + + +<p><i>[ +Kona (2007) Moved to Ready. +]</i></p> + + + + + +<hr> +<h3><a name="563"></a>563. stringbuf seeking from end</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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +According to Table 92 (unchanged by issue 432), when <code>(way == +end)</code> the <code>newoff</code> value in out mode is computed as +the difference between <code>epptr()</code> and <code>pbase()</code>. +</p> + <p> + +This value isn't meaningful unless the value of <code>epptr()</code> +can be precisely controlled by a program. That used to be possible +until we accepted the resolution of issue 432, but since then the +requirements on <code>overflow()</code> have been relaxed to allow it +to make more than 1 write position available (i.e., by setting +<code>epptr()</code> to some unspecified value past +<code>pptr()</code>). So after the first call to +<code>overflow()</code> positioning the output sequence relative to +end will have unspecified results. + + </p> + <p> + +In addition, in <code>in|out</code> mode, since <code>(egptr() == +epptr())</code> need not hold, there are two different possible values +for <code>newoff</code>: <code>epptr() - pbase()</code> and +<code>egptr() - eback()</code>. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +Change the <code>newoff</code> column in the last row of Table 94 to +read: + + </p> +<blockquote><p> + +the <del>end</del> <ins>high mark</ins> pointer minus the beginning +pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>). + +</p></blockquote> + + +<p><i>[ +Kona (2007) Moved to Ready. +]</i></p> + + + + + +<hr> +<h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</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#WP">WP</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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The array forms of unformatted input functions don't have well-defined +semantics for zero-element arrays in a couple of cases. The affected +ones (<tt>istream::get()</tt> and <tt>getline()</tt>) are supposed to +terminate when <tt>(n - 1)</tt> characters are stored, which obviously +can never be true when <tt>(n == 0)</tt> to start with. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +I propose the following changes (references are relative to the +Working Draft (document N1804). + + </p> + <p> + +Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows: + + </p> + <blockquote> + <p> + +<ins>if <tt>(n < 1)</tt> is true or </ins> <tt>(n - 1)</tt> +characters are stored; + + </p> + </blockquote> + <p> + +Similarly, change 27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet +3 as follows: + + </p> + <blockquote> + <p> + +<ins><tt>(n < 1)</tt> is true or </ins><tt>(n - 1)</tt> characters +are stored (in which case the function calls +<tt>setstate(failbit)</tt>). + + </p> + </blockquote> + <p> + +Finally, change p21 as follows: + + </p> + <blockquote> + <p> + +In any case, <ins>provided <tt>(n > 0)</tt> is true, </ins>it then +stores a null character (using charT()) into the next successive +location of the array. + + </p> + </blockquote> + + + + + +<hr> +<h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-25</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +Issue 60 explicitly made the extractor and inserter operators that +take a <tt>basic_streambuf*</tt> argument formatted input and output +functions, respectively. I believe that's wrong, certainly in the +case of the extractor, since formatted functions begin by extracting +and discarding whitespace. The extractor should not discard any +characters. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +I propose to change each operator to behave as unformatted input and +output function, respectively. The changes below are relative to the +working draft document number N1804. + + </p> + <p> + +Specifically, change 27.6.1.2.3, p14 as follows: + + </p> + + <blockquote> + <p> + +<i>Effects</i>: Behaves as a<ins>n un</ins>formatted input function +(as described in <del>27.6.1.2.1</del><ins>27.6.1.3, paragraph +1</ins>). + + </p> + </blockquote> + <p> + +And change 27.6.2.5.3, p7 as follows: + + </p> + + <blockquote> + <p> + +<i>Effects</i>: Behaves as a<ins>n un</ins>formatted output function +(as described in <del>27.6.2.5.1</del><ins>27.6.2.6, paragraph +1</ins>). + + </p> + </blockquote> + + +<p><i>[ +Kona (2007): Proposed Disposition: Ready +]</i></p> + + + + + +<hr> +<h3><a name="574"></a>574. DR 369 Contradicts Text</h3> +<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Pete Becker <b>Date:</b> 2006-04-18</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +lib.iostream.objects requires that the standard stream objects are never +destroyed, and it requires that they be destroyed. +</p> +<p> +DR 369 adds words to say that we really mean for ios_base::Init objects to force +construction of standard stream objects. It ends, though, with the phrase "these +stream objects shall be destroyed after the destruction of dynamically ...". +However, the rule for destruction is stated in the standard: "The objects are +not destroyed during program execution." +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 27.3 [iostream.objects]/1: +</p> + +<blockquote> +<p> +-2- The objects are constructed and the associations are established at +some time prior to or during the first time an object of class +<tt>ios_base::Init</tt> is constructed, and in any case before the body of main +begins execution.<sup>290)</sup> The objects are not destroyed during program +execution.<sup>291)</sup> If a translation unit includes <tt><iostream&t;</tt> or explicitly +constructs an <tt>ios_base::Init</tt> object, these stream objects shall be +constructed before dynamic initialization of non-local objects defined +later in that translation unit<del>, and these stream objects shall be +destroyed after the destruction of dynamically initialized non-local +objects defined later in that translation unit</del>. +</p> +</blockquote> + + +<p><i>[ +Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects +shall be destroyed after the destruction of dynamically initialized +non-local objects defined later in that translation unit." Proposed +Disposition: Review +]</i></p> + + + + + +<hr> +<h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3> +<p><b>Section:</b> 20.7.12.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-04-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +[tr.util.smartptr.shared.dest] says in its second bullet: +</p> + +<p> +"If *this shares ownership with another shared_ptr instance (use_count() > 1), +decrements that instance's use count." +</p> + +<p> +The problem with this formulation is that it presupposes the existence of an +"use count" variable that can be decremented and that is part of the state of a +shared_ptr instance (because of the "that instance's use count".) +</p> + +<p> +This is contrary to the spirit of the rest of the specification that carefully +avoids to require an use count variable. Instead, use_count() is specified to +return a value, a number of instances. +</p> + +<p> +In multithreaded code, the usual implicit assumption is that a shared variable +should not be accessed by more than one thread without explicit synchronization, +and by introducing the concept of an "use count" variable, the current wording +implies that two shared_ptr instances that share ownership cannot be destroyed +simultaneously. +</p> + +<p> +In addition, if we allow the interpretation that an use count variable is part +of shared_ptr's state, this would lead to other undesirable consequences WRT +multiple threads. For example, +</p> + +<blockquote><pre>p1 = p2; +</pre></blockquote> + +<p> +would now visibly modify the state of p2, a "write" operation, requiring a lock. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to: +</p> + +<blockquote> +<ul> +<li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another +<tt>shared_ptr</tt> instance (<tt>use_count() > 1</tt>)</ins>, there are no side effects.</li> +<li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance +(<tt>use_count() > 1</tt>), decrements that instance's use count.</del></li> +</ul> +</blockquote> + +<p> +Add the following paragraph after [lib.util.smartptr.shared.dest]/1: +</p> + +<blockquote><p> +[<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in +<tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership +with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value +after <tt>*this</tt> is destroyed. <i>--end note</i>] +</p></blockquote> + + + + + +<hr> +<h3><a name="576"></a>576. find_first_of is overconstrained</h3> +<p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Doug Gregor <b>Date:</b> 2006-04-25</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to +find_first_of are specified to require Forward Iterators, as follows: +</p> + +<blockquote><pre>template<class ForwardIterator1, class ForwardIterator2> + ForwardIterator1 + find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2); +template<class ForwardIterator1, class ForwardIterator2, + class BinaryPredicate> +ForwardIterator1 + find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2, + BinaryPredicate pred); +</pre></blockquote> + +<p> +However, ForwardIterator1 need not actually be a Forward Iterator; an Input +Iterator suffices, because we do not need the multi-pass property of the Forward +Iterator or a true reference. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the declarations of <tt>find_first_of</tt> to: +</p> + +<blockquote><pre>template<class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2> + <del>ForwardIterator1</del><ins>InputIterator1</ins> + find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1, + ForwardIterator2 first2, ForwardIterator2 last2); +template<class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2, + class BinaryPredicate> +<del>ForwardIterator1</del><ins>InputIterator1</ins> + find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1, + ForwardIterator2 first2, ForwardIterator2 last2, + BinaryPredicate pred); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3> +<p><b>Section:</b> 25.3.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-05-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +ISO/IEC 14882:2003 says: +</p> + +<blockquote> +<p> +25.3.3.2 upper_bound +</p> +<p> +<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range +<tt>[<i>first</i>, <i>last</i>)</tt> such that +for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding +conditions hold: <tt>!(value < *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>. +</p> +</blockquote> + +<p> +From the description above, upper_bound cannot return last, since it's +not in the interval [first, last). This seems to be a typo, because if +value is greater than or equal to any other values in the range, or if +the range is empty, returning last seems to be the intended behaviour. +The corresponding interval for lower_bound is also [first, last]. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change [lib.upper.bound]: +</p> + +<blockquote> +<p> +<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range +<tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that +for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding +conditions hold: <tt>!(value < *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>. +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3> +<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The description of the allocator member function +<code>allocate()</code> requires that the <i>hint</i> argument be +either 0 or a value previously returned from <code>allocate()</code>. +Footnote 227 further suggests that containers may pass the address of +an adjacent element as this argument. + + </p> + <p> + +I believe that either the footnote is wrong or the normative +requirement that the argument be a value previously returned from a +call to <code>allocate()</code> is wrong. The latter is supported by +the resolution to issue 20-004 proposed in c++std-lib-3736 by Nathan +Myers. In addition, the <i>hint</i> is an ordinary void* and not the +<code>pointer</code> type returned by <code>allocate()</code>, with +the two types potentially being incompatible and the requirement +impossible to satisfy. + + </p> + <p> + +See also c++std-lib-14323 for some more context on where this came up +(again). + + </p> + + + <p><b>Proposed resolution:</b></p> + <p> + +Remove the requirement in 20.6.1.1, p4 that the hint be a value +previously returned from <code>allocate()</code>. Specifically, change +the paragraph as follows: + + </p> +<p> +<del><i>Requires</i>: <i>hint</i> either 0 or previously obtained from member +<code>allocate</code> and not yet passed to member <code>deallocate</code>. +The value hint may be used by an implementation to help improve performance +<sup>223)</sup>.</del> <ins>[<i>Note:</i> The value <i>hint</i> may be used by an +implementation to help improve performance. -- <i>end note</i>]</ins> +</p> +<blockquote><p> +<del>[Footnote: <sup>223)</sup>In a container member function, the address of an +adjacent element is often a good choice to pass for this argument.</del> +</p></blockquote> + + + + +<hr> +<h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3> +<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#ostream.unformatted">issues</a> in [ostream.unformatted].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The resolution of issue 60 changed <code>basic_ostream::flush()</code> +so as not to require it to behave as an unformatted output function. +That has at least two in my opinion problematic consequences: + + </p> + <p> + +First, <code>flush()</code> now calls <code>rdbuf()->pubsync()</code> +unconditionally, without regard to the state of the stream. I can't +think of any reason why <code>flush()</code> should behave differently +from the vast majority of stream functions in this respect. + + </p> + <p> + +Second, <code>flush()</code> is not required to catch exceptions from +<code>pubsync()</code> or set <code>badbit</code> in response to such +events. That doesn't seem right either, as most other stream functions +do so. + + </p> + + + <p><b>Proposed resolution:</b></p> + <p> + +I propose to revert the resolution of issue 60 with respect to +<code>flush()</code>. Specifically, I propose to change 27.6.2.6, p7 +as follows: + + </p> + +<p> +Effects: <ins>Behaves as an unformatted output function (as described +in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null +pointer, <ins>constructs a sentry object. If this object returns +<code>true</code> when converted to a value of type bool the function +</ins>calls <code>rdbuf()->pubsync()</code>. If that function returns +-1 calls <code>setstate(badbit)</code> (which may throw +<code>ios_base::failure</code> (27.4.4.3)). <ins>Otherwise, if the +sentry object returns <code>false</code>, does nothing.</ins><del>Does +not behave as an unformatted output function (as described in +27.6.2.6, paragraph 1).</del> +</p> + + + +<p><i>[ +Kona (2007): Proposed Disposition: Ready +]</i></p> + + + + + +<hr> +<h3><a name="586"></a>586. string inserter not a formatted function</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +Section and paragraph numbers in this paper are relative to the +working draft document number N2009 from 4/21/2006. + + </p> + + <p> + +The <code>basic_string</code> extractor in 21.3.7.9, p1 is clearly +required to behave as a formatted input function, as is the +<code>std::getline()</code> overload for string described in p7. + + </p> + <p> + +However, the <code>basic_string</code> inserter described in p5 of the +same section has no such requirement. This has implications on how the +operator responds to exceptions thrown from <code>xsputn()</code> +(formatted output functions are required to set <code>badbit</code> +and swallow the exception unless <code>badbit</code> is also set in +<code>exceptions()</code>; the string inserter doesn't have any such +requirement). + + </p> + <p> + +I don't see anything in the spec for the string inserter that would +justify requiring it to treat exceptions differently from all other +similar operators. (If it did, I think it should be made this explicit +by saying that the operator "does not behave as a formatted output +function" as has been made customary by the adoption of the resolution +of issue 60). + + </p> + + + <p><b>Proposed resolution:</b></p> + <p> + +I propose to change the Effects clause in 21.3.7.9, p5, as follows: + + </p> + <blockquote> + <p> + +<i>Effects</i>: <del>Begins by constructing a sentry object k as if k +were constructed by typename <code>basic_ostream<charT, +traits>::sentry k (os)</code>. If <code>bool(k)</code> is +<code>true</code>, </del><ins>Behaves as a formatted output function +(27.6.2.5.1). After constructing a <code>sentry</code> object, if +this object returns <code>true</code> when converted to a value of +type <code>bool</code>, determines padding as described in +22.2.2.2.2</ins>, then inserts the resulting sequence of characters +<code><i>seq</i></code> as if by calling <code>os.rdbuf()->sputn(seq , +n)</code>, where <code><i>n</i></code> is the larger of +<code>os.width()</code> and <code>str.size()</code>; then calls +<code>os.width(0)</code>. <del>If the call to sputn fails, calls +<code>os.setstate(ios_base::failbit)</code>.</del> + + </p> + </blockquote> + <p> + +This proposed resilution assumes the resolution of issue 394 (i.e., +that all formatted output functions are required to set +<code>ios_base::badbit</code> in response to any kind of streambuf +failure), and implicitly assumes that a return value of +<code>sputn(seq, <i>n</i>)</code> other than <code><i>n</i></code> +indicates a failure. + + </p> + + + + +<hr> +<h3><a name="589"></a>589. Requirements on iterators of member template functions 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#WP">WP</a> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-08-02</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#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a></p> +<p><b>Discussion:</b></p> +<p> +There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in +terms of their value_type, and the requirements in 23.1.2 appear to be overly strict +(requires InputIterator::value_type be the same type as the container's value_type). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 23.1.1 p3: +</p> + +<blockquote><p> +In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a +value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input +iterator requirements <ins>and refer to elements <ins>implicitly +convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid +range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a +valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable +iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>, +and <tt>t</tt> denotes a value of <tt>X::value_type</tt>. +</p></blockquote> + +<p> +Change 23.1.2 p7: +</p> + +<blockquote><p> +In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value +of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports +unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports +multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and +refer to elements <del>of</del> <ins>implicitly convertible to</ins> +<tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid +iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to +<tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a +value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt> +and <tt>c</tt> is a value of type <tt>X::key_compare</tt>. +</p></blockquote> + + + +<p><b>Rationale:</b></p> +<p> +Concepts will probably come in and rewrite this section anyway. But just in case it is +easy to fix this up as a safety net and as a clear statement of intent. +</p> + + + + + +<hr> +<h3><a name="593"></a>593. __STDC_CONSTANT_MACROS</h3> +<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Walter Brown <b>Date:</b> 2006-08-28</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers +<cstdint> and <stdint.h>. These are of course based on the C99 header +<stdint.h>, and were part of TR1. +</p> + +<p> +Per 18.3.1/1, these headers define a number of macros and function macros. +While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99 +footnotes do mention __STDC_CONSTANT_MACROS. Further, 18.3.1/2 states that "The +header defines all ... macros the same as C99 subclause 7.18." +</p> + +<p> +Therefore, if I wish to have the above-referenced macros and function macros +defined, must I #define __STDC_CONSTANT_MACROS before I #include <cstdint>, or +does the C++ header define these macros/function macros unconditionally? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +To put this issue to rest for C++0X, I propose the following addition to +18.3.1/2 of the Working Paper N2009: +</p> + +<blockquote><p> +[Note: The macros defined by <cstdint> are provided unconditionally: in +particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS +(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note] +</p></blockquote> + + + + + +<hr> +<h3><a name="595"></a>595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified</h3> +<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 2006-09-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +TR1 introduced, in the C compatibility chapter, the function +fabs(complex<T>): +</p> +<blockquote><pre>----- SNIP ----- +8.1.1 Synopsis [tr.c99.cmplx.syn] + + namespace std { + namespace tr1 { +[...] + template<class T> complex<T> fabs(const complex<T>& x); + } // namespace tr1 + } // namespace std + +[...] + +8.1.8 Function fabs [tr.c99.cmplx.fabs] + +1 Effects: Behaves the same as C99 function cabs, defined in + subclause 7.3.8.1. +----- SNIP ----- +</pre></blockquote> + +<p> +The current C++0X draft document (n2009.pdf) adopted this +definition in chapter 26.3.1 (under the comment // 26.3.7 values) +and 26.3.7/7. +</p> +<p> +But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document +n1124), the referenced subclause reads +</p> + +<blockquote><pre>----- SNIP ----- +7.3.8.1 The cabs functions + + Synopsis + +1 #include <complex.h> + double cabs(double complex z); + float cabsf(float complex z); + long double cabsl(long double z); + + Description + +2 The cabs functions compute the complex absolute value (also called + norm, modulus, or magnitude) of z. + + Returns + +3 The cabs functions return the complex absolute value. +----- SNIP ----- +</pre></blockquote> + +<p> +Note that the return type of the cabs*() functions is not a complex +type. Thus, they are equivalent to the already well established + template<class T> T abs(const complex<T>& x); +(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft +document n2009.pdf). +</p> +<p> +So either the return value of fabs() is specified wrongly, or fabs() +does not behave the same as C99's cabs*(). +</p> + +<b>Possible Resolutions</b> + +<p> +This depends on the intention behind the introduction of fabs(). +</p> +<p> +If the intention was to provide a /complex/ valued function that +calculates the magnitude of its argument, this should be +explicitly specified. In TR1, the categorization under "C +compatibility" is definitely wrong, since C99 does not provide +such a complex valued function. +</p> +<p> +Also, it remains questionable if such a complex valued function +is really needed, since complex<T> supports construction and +assignment from real valued arguments. There is no difference +in observable behaviour between +</p> +<blockquote><pre> complex<double> x, y; + y = fabs(x); + complex<double> z(fabs(x)); +</pre></blockquote> +<p> +and +</p> +<blockquote><pre> complex<double> x, y; + y = abs(x); + complex<double> z(abs(x)); +</pre></blockquote> +<p> +If on the other hand the intention was to provide the intended +functionality of C99, fabs() should be either declared deprecated +or (for C++0X) removed from the standard, since the functionality +is already provided by the corresponding overloads of abs(). +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Bill believes that abs() is a suitable overload. We should remove fabs(). +</blockquote> + + +<p><b>Proposed resolution:</b></p> + +<p> +Change the synopsis in 26.3.1 [complex.synopsis]: +</p> + +<blockquote><pre><del>template<class T> complex<T> fabs(const complex<T>&);</del> +</pre></blockquote> + +<p> +Remove 26.3.7 [complex.value.ops], p7: +</p> + +<blockquote> +<pre><del>template<class T> complex<T> fabs(const complex<T>& <i>x</i>);</del> +</pre> +<blockquote> +<p> +<del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del> +</p> +</blockquote> +</blockquote> + + + +<p><i>[ +Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>. +Proposed Disposition: Ready +]</i></p> + + + + + +<hr> +<h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</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#WP">WP</a> + <b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke +</p> +<blockquote><pre> ostr.open("somename", ios_base::out | ios_base::in | ios_base::app) +</pre></blockquote> +<p> +and we expect the open to fail, because out|in|app is not listed in +Table 92, and just before the table we see very specific words: +</p> +<blockquote><p> + If mode is not some combination of flags shown in the table + then the open fails. +</p></blockquote> +<p> +But the corresponding table in the C standard, 7.19.5.3, provides two +modes "a+" and "a+b", to which the C++ modes out|in|app and +out|in|app|binary would presumably apply. +</p> +<p> +We would like to argue that the intent of Table 112 was to match the +semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was +unintentional. (Otherwise there would be valid and useful behaviors +available in C file I/O which are unavailable using C++, for no +valid functional reason.) +</p> +<p> +We further request that the missing modes be explicitly restored to +the WP, for inclusion in C++0x. +</p> + +<p><i>[ +Martin adds: +]</i></p> + + +<p> +...besides "a+" and "a+b" the C++ table is also missing a row +for a lone app bit which in at least two current implementation +as well as in Classic Iostreams corresponds to the C stdio "a" +mode and has been traditionally documented as implying ios::out. +Which means the table should also have a row for in|app meaning +the same thing as "a+" already proposed in the issue. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to the table "File open modes" in 27.8.1.4 [filebuf.members]: +</p> + +<blockquote> +<table border="1"> +<caption> File open modes</caption> +<tbody><tr> +<th colspan="5"><tt>ios_base</tt> Flag combination</th> +<th><tt>stdio</tt> equivalent</th> +</tr> +<tr> +<th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt> </tt></th> +</tr> + +<tr> +<td> </td> <td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"w"</tt></td> +</tr> +<tr> +<td> </td> <td> </td> <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>"a"</tt></td> +</tr> +<tr> +<td> </td> <td> </td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td> +</tr> +<tr> +<td> </td> <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w"</tt></td> +</tr> +<tr> +<td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td> </td> <td><tt>"r"</tt></td> +</tr> +<tr> +<td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"r+"</tt></td> +</tr> +<tr> +<td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w+"</tt></td> +</tr> +<tr> +<td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td> +</tr> +<tr> +<td> </td> <td><ins><tt>+</tt></ins></td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td> +</tr> + +<tr> +<td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"wb"</tt></td> +</tr> +<tr> +<td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td> +</tr> +<tr> +<td><ins><tt>+</tt></ins></td> <td> </td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td> +</tr> +<tr> +<td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"wb"</tt></td> +</tr> +<tr> +<td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td> </td> <td><tt>"rb"</tt></td> +</tr> +<tr> +<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"r+b"</tt></td> +</tr> +<tr> +<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w+b"</tt></td> +</tr><tr> +<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td> +</tr> +<tr> +<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td> +</tr> + + +</tbody></table> +</blockquote> + + + +<p><i>[ +Kona (2007) Added proposed wording and moved to Review. +]</i></p> + + + + + +<hr> +<h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</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#TRDec">TRDec</a> + <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</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#TRDec">TRDec</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +In a private email, Daniel writes: +</p> +<blockquote> +<p> +I would like to +ask, what where the reason for the decision to +define the semantics of the integral conversion of the decimal types, namely +</p> +<pre>"operator long long() const; + + Returns: Returns the result of the +conversion of *this to the type long long, as if +performed by the expression llrounddXX(*this)." +</pre> +<p> +where XX stands for either 32, 64, or 128, +corresponding to the proper decimal type. The +exact meaning of llrounddXX is not given in that +paper, so I compared it to the corresponding +definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2: +</p> +<p> +"The lround and llround functions round their +argument to the nearest integer value, +rounding halfway cases away from zero, regardless +of the current rounding direction. [..]" +</p> +<p> +Now considering the fact that integral conversion +of the usual floating-point types ("4.9 +Floating-integral conversions") has truncation +semantic I wonder why this conversion behaviour +has not been transferred for the decimal types. +</p> +</blockquote> +<p> +Robert comments: +</p> +<p> +Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>. It currently calls <code>llroundd64</code>, not <code>llroundd128</code>. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the <b>Returns:</b> clause in 3.2.2.4 to: +</p> +<blockquote><p> +<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>. +</p></blockquote> +<p> +Change the <b>Returns:</b> clause in 3.2.3.4 to: +</p> +<blockquote><p> +<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>. +</p></blockquote> +<p> +Change the <b>Returns:</b> clause in 3.2.4.4 to: +</p> +<blockquote><p> +<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>. +</p></blockquote> + + + + + + +<hr> +<h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3> +<p><b>Section:</b> TRDecimal 3.1 [trdec.types.encodings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a> + <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Daniel writes in a private email: +</p> + +<blockquote> +<p> +- 3.1 'Decimal type encodings' says in its note: +</p> +<pre>"this implies that +sizeof(std::decimal::decimal32) == 4, +sizeof(std::decimal::decimal64) == 8, and +sizeof(std::decimal::decimal128) == 16." +</pre> +<p> +This is a wrong assertion, because the definition +of 'byte' in 1.7 'The C+ + memory model' of ISO +14882 (2nd edition) does not specify that a byte +must be necessarily 8 bits large, which would be +necessary to compare with the specified bit sizes +of the types decimal32, decimal64, and decimal128. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 3.1 as follows: +</p> +<blockquote> +<p> +The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows: +</p> +<ul> +<li> +decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits) +</li> +<li> +decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits) + +</li> +<li> +decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits) +</li> +</ul> +<p> +<del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>. <i>--end note</i>]</del> +</p> +</blockquote> + + + + +<hr> +<h3><a name="600"></a>600. Decimal: Wrong parameters for wcstod* functions</h3> +<p><b>Section:</b> TRDecimal 3.9 [trdec.types.cwchar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a> + <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Daniel writes: +</p> +<blockquote><p> +- 3.9.1 'Additions to <cwchar>' provides wrong +signatures to the wcstod32, wcstod64, and +wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t). +</p></blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change "3.9.1 Additions to <code><cwchar></code> synopsis" to: +</p> +<pre> namespace std { + namespace decimal { + // 3.9.2 wcstod functions: + decimal32 wcstod32 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr); + decimal64 wcstod64 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr); + decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr); + } + } +</pre> + + + + +<hr> +<h3><a name="601"></a>601. Decimal: numeric_limits typos</h3> +<p><b>Section:</b> TRDecimal 3.3 [trdec.types.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a> + <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Daniel writes in a private email: +</p> + +<blockquote> +<p> +- 3.3 'Additions to header <limits>' contains two +errors in the specialisation of numeric_limits<decimal::decimal128>: +</p> +<ol> +<li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li> +<li>The static member digits is assigned to 384, +this should be 34 (Probably mixed up with the +max. exponent for decimal::decimal64).</li> +</ol> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +In "3.3 Additions to header <code><limits></code>" change numeric_limits<decimal::decimal128> as follows: +</p> +<pre> template<> class numeric_limits<decimal::decimal128> { + public: + static const bool is_specialized = true; + + static decimal::decimal128 min() throw() { return DEC128_MIN; } + static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> } + + static const int digits = <del>384</del> <ins>34</ins>; + /* ... */ +</pre> + + + + +<hr> +<h3><a name="602"></a>602. Decimal: "generic floating type" not defined.</h3> +<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a> + <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The document uses the term "generic floating types," but defines it nowhere. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the first paragraph of "3 Decimal floating-point types" as follows: +</p> +<blockquote><p> +This Technical Report introduces three decimal floating-point types, named +decimal32, decimal64, and decimal128. The set of values of type decimal32 is a +subset of the set of values of type decimal64; the set of values of the type +decimal64 is a subset of the set of values of the type decimal128. Support for +decimal128 is optional. <ins>These types supplement the Standard C++ types +<code>float</code>, <code>double</code>, and <code>long double</code>, which are +collectively described as the <i>basic floating types</i></ins>. +</p></blockquote> + + + + +<hr> +<h3><a name="603"></a>603. Decimal: Trivially simplifying decimal classes.</h3> +<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p> +<p><b>Discussion:</b></p> +<p>In c++std-lib-17198, Martin writes:</p> + +<blockquote><p> +Each of the three classes proposed in the paper (decimal32, decimal64, +and decimal128) explicitly declares and specifies the semantics of its +copy constructor, copy assignment operator, and destructor. Since the +semantics of all three functions are identical to the trivial versions +implicitly generated by the compiler in the absence of any declarations +it is safe to drop them from the spec. This change would make the +proposed classes consistent with other similar classes already in the +standard (e.g., std::complex). +</p></blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change "3.2.2 Class <code>decimal32</code>" as follows: +</p> +<pre> namespace std { + namespace decimal { + class decimal32 { + public: + // 3.2.2.1 construct/copy/destroy: + decimal32(); + <del>decimal32(const decimal32 & d32);</del> + <del>decimal32 & operator=(const decimal32 & d32);</del> + <del>~decimal32();</del> + /* ... */ +</pre> +<p> +Change "3.2.2.1 construct/copy/destroy" as follows: +</p> +<pre> decimal32(); + + Effects: Constructs an object of type decimal32 with the value 0; + + <del>decimal32(const decimal32 & d32);</del> + <del>decimal32 & operator=(const decimal32 & d32);</del> + + <del>Effects: Copies an object of type decimal32.</del> + + <del>~decimal32();</del> + + <del>Effects: Destroys an object of type decimal32.</del> + +</pre> +<p> +Change "3.2.3 Class <code>decimal64</code>" as follows: +</p> +<pre> namespace std { + namespace decimal { + class decimal64 { + public: + // 3.2.3.1 construct/copy/destroy: + decimal64(); + <del>decimal64(const decimal64 & d64);</del> + <del>decimal64 & operator=(const decimal64 & d64);</del> + <del>~decimal64();</del> + /* ... */ +</pre> +<p> +Change "3.2.3.1 construct/copy/destroy" as follows: +</p> +<pre> decimal64(); + + Effects: Constructs an object of type decimal64 with the value 0; + + <del>decimal64(const decimal64 & d64);</del> + <del>decimal64 & operator=(const decimal64 & d64);</del> + + <del>Effects: Copies an object of type decimal64.</del> + + <del>~decimal64();</del> + + <del>Effects: Destroys an object of type decimal64.</del> + +</pre> +<p> +Change "3.2.4 Class <code>decimal128</code>" as follows: +</p> +<pre> namespace std { + namespace decimal { + class decimal128 { + public: + // 3.2.4.1 construct/copy/destroy: + decimal128(); + <del>decimal128(const decimal128 & d128);</del> + <del>decimal128 & operator=(const decimal128 & d128);</del> + <del>~decimal128();</del> + /* ... */ +</pre> +<p> +Change "3.2.4.1 construct/copy/destroy" as follows: +</p> +<pre> decimal128(); + + Effects: Constructs an object of type decimal128 with the value 0; + + <del>decimal128(const decimal128 & d128);</del> + <del>decimal128 & operator=(const decimal128 & d128);</del> + + <del>Effects: Copies an object of type decimal128.</del> + + <del>~decimal128();</del> + + <del>Effects: Destroys an object of type decimal128.</del> + +</pre> + + + + +<hr> +<h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3> +<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In c++std-lib-17197, Martin writes: +</p> +<blockquote><p> +The extended_num_get and extended_num_put facets are designed +to store a reference to a num_get or num_put facet which the +extended facets delegate the parsing and formatting of types +other than decimal. One form of the extended facet's ctor (the +default ctor and the size_t overload) obtains the reference +from the global C++ locale while the other form takes this +reference as an argument. +</p></blockquote> +<blockquote><p> +The problem with storing a reference to a facet in another +object (as opposed to storing the locale object in which the +facet is installed) is that doing so bypasses the reference +counting mechanism designed to prevent a facet that is still +being referenced (i.e., one that is still installed in some +locale) from being destroyed when another locale that contains +it is destroyed. Separating a facet reference from the locale +it comes from van make it cumbersome (and in some cases might +even make it impossible) for programs to prevent invalidating +the reference. (The danger of this design is highlighted in +the paper.) +</p></blockquote> +<blockquote><p> +This problem could be easily avoided by having the extended +facets store a copy of the locale from which they would extract +the base facet either at construction time or when needed. To +make it possible, the forms of ctors of the extended facets that +take a reference to the base facet would need to be changed to +take a locale argument instead. +</p></blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows: +</p> +<pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0); + + /* ... */ + + <del>// <i>const std::num_get<charT, InputIterator> & <b>base</b></i>; <i><b>exposition only</b></i></del> + <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins> +</pre> +<p> +2. Change the description of the above constructor in 3.10.2.1: +</p> +<pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0); + +</pre> +<blockquote> +<p> +<b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by: +</p> +<pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0) + : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>) + { /* ... */ } + +</pre> +<p> +<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del> +</p> +</blockquote> +<p> +3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const</code>, <i>et al</i> to +</p> +<blockquote><p> +<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_get<charT, InputIterator> >(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>. +</p></blockquote> +<p> +4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows: +</p> +<pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0); + + /* ... */ + + <del>// <i>const std::num_put<charT, OutputIterator> & <b>base</b></i>; <i><b>exposition only</b></i></del> + <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins> +</pre> +<p> +5. Change the description of the above constructor in 3.10.3.1: +</p> +<pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0); +</pre> +<blockquote> +<p> +<b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by: +</p> +<pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0) + : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>) + { /* ... */ } + +</pre> +<p> +<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del> +</p> +</blockquote> +<p> +6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &, char_type, bool &) const</code>, <i>et al</i> to +</p> +<blockquote><p> +<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_put<charT, OutputIterator> >(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>. +</p></blockquote> + +<p><i>[ +Redmond: We would prefer to rename "extended" to "decimal". +]</i></p> + + + + + + +<hr> +<h3><a name="605"></a>605. Decimal: <decfloat.h> doesn't live here anymore.</h3> +<p><b>Section:</b> TRDecimal 3.4 [trdec.types.cdecfloat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a> + <b>Submitter:</b> Robert Klarer <b>Date:</b> 2006-10-17</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In Berlin, WG14 decided to drop the <decfloat.h> header. The +contents of that header have been moved into <float.h>. For the +sake of C compatibility, we should make corresponding changes. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +1. Change the heading of subclause 3.4, "Headers <code><cdecfloat></code> and <code><decfloat.h></code>" to "Additions to headers <code><cfloat></code> and <code><float.h></code>." +</p> +<p> +2. Change the text of subclause 3.4 as follows: +</p> +<blockquote> +<p> +<del>The standard C++ headers <code><cfloat></code> and <code><float.h></code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>. Their contents remain unchanged by this Technical Report.</del> +</p> +<p> +<del>Headers <code><cdecfloat></code> and <code><decfloat.h></code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><decfloat.h></code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del> +</p> +<p> +<ins>The header <code><cfloat></code> is described in [tr.c99.cfloat]. The header <code><float.h></code> +is described in [tr.c99.floath]. These headers are extended by this +Technical Report to define characteristics of the decimal +floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><float.h></code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins> +</p> +</blockquote> +<p> +3. Change the heading of subclause 3.4.1, "Header <code><cdecfloat></code> synopsis" to "Additions to header <code><cfloat></code> synopsis." +</p> +<p> +4. Change the heading of subclause 3.4.2, "Header <code><decfloat.h></code> synopsis" to "Additions to header <code><float.h></code> synopsis." +</p> +<p> +5. Change the contents of 3.4.2 as follows: +</p> +<pre> <del>#include <cdecfloat></del> + + // <i>C-compatibility convenience typedefs:</i> + + typedef std::decimal::decimal32 _Decimal32; + typedef std::decimal::decimal64 _Decimal64; + typedef std::decimal::decimal128 _Decimal128; +</pre> + + + + + +<hr> +<h3><a name="607"></a>607. Concern about short seed vectors</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#WP">WP</a> + <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Short seed vectors of 32-bit quantities all result in different states. However +this is not true of seed vectors of 16-bit (or smaller) quantities. For example +these two seeds +</p> + +<blockquote><pre>unsigned short seed = {1, 2, 3}; +unsigned short seed = {1, 2, 3, 0}; +</pre></blockquote> + +<p> +both pack to +</p> + +<blockquote><pre>unsigned seed = {0x20001, 0x3}; +</pre></blockquote> + +<p> +yielding the same state. +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +for some further discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="608"></a>608. Unclear seed_seq construction details</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#WP">WP</a> + <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the +treatment of signed quantities is unclear. Better to spell it out. +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +for some further discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="609"></a>609. missing static const</h3> +<p><b>Section:</b> 26.4.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Walter E. Brown <b>Date:</b> 2006-11-02</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In preparing N2111, an error on my part resulted in the omission of the +following line from the template synopsis in the cited section: +</p> + +<blockquote><pre>static const size_t word_size = w; +</pre></blockquote> + +<p> +(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4: +</p> + +<blockquote><pre>// engine characteristics +<ins>static const size_t word_size = w;</ins> +</pre></blockquote> + +<p> +and accept my apologies for the oversight. +</p> + + + + + +<hr> +<h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3> +<p><b>Section:</b> 20.6.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Scott Meyers <b>Date:</b> 2006-11-02</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +My suggestion is that implementers of both tr1::function and its +official C++0x successor be explicitly encouraged (but not required) to +optimize for the cases mentioned above, i.e., function pointers and +small function objects. They could do this by using a small internal +buffer akin to the buffer used by implementations of the small string +optimization. (That would make this the small functor optimization -- +SFO :-}) The form of this encouragement could be a note in the standard +akin to footnote 214 of the current standard. +</p> + +<p> +Dave Abrahams notes: +</p> + +<p> +"shall not throw exceptions" should really be "nothing," both to be more +grammatical and to be consistent with existing wording in the standard. +</p> + +<p> +Doug Gregor comments: I think this is a good idea. Currently, implementations of +tr1::function are required to have non-throwing constructors and assignment +operators when the target function object is a function pointer or a +reference_wrapper. The common case, however, is for a tr1::function to store +either an empty function object or a member pointer + an object pointer. +</p> +<p> +The function implementation in the upcoming Boost 1.34.0 uses the +"SFO", so that the function objects for typical bind expressions like +</p> +<blockquote><pre>bind(&X::f, this, _1, _2, _3) +</pre></blockquote> + +<p> +do not require heap allocation when stored in a boost::function. I +believe Dinkumware's implementation also performs this optimization. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows: +</p> + +<blockquote> +<p> +<i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function +pointer or a function object passed via <tt>reference_wrapper</tt>. Otherwise, +may throw <tt>bad_alloc</tt> or any exception thrown by the copy constructor of +the stored function object. +</p> +<p> +<ins><i>Note:</i> Implementations are encouraged to avoid the use of dynamically +allocated memory for "small" function objects, e.g., where <tt>f</tt>'s target +is an object holding only a pointer or reference to an object and a member +function pointer (a "bound member function").</ins> +</p> +</blockquote> + + + + + +<hr> +<h3><a name="611"></a>611. Standard library templates and incomplete types</h3> +<p><b>Section:</b> 17.4.3.7 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Nicola Musatti <b>Date:</b> 2006-11-13</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the latest available draft standard +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>) +§ 17.4.3.6 [res.on.functions] states: +</p> + +<blockquote> +<p> +-1- In certain cases (replacement functions, handler functions, operations on +types used to instantiate standard library template components), the C++ +Standard Library depends on components supplied by a C++ program. If these +components do not meet their requirements, the Standard places no requirements +on the implementation. +</p> + +<p> +-2- In particular, the effects are undefined in the following cases: +</p> +<p> +[...] +</p> +<ul> +<li>if an incomplete type (3.9) is used as a template argument when +instantiating a template component. </li> +</ul> +</blockquote> + +<p> +This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which +states: +</p> + +<blockquote> +<p> +[...] +</p> + +<p> +The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for +exceptions: +</p> + +<blockquote> +<ul> +<li>if an incomplete type (3.9) is used as a template argument when +instantiating a template component<ins>, unless specifically allowed for the +component</ins>. </li> +</ul> +</blockquote> + + + + + + +<hr> +<h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3> +<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +18.2.1.2 55 states that "A type is modulo if it is possible to add two +positive numbers together and have a result that wraps around to a +third number that is less". +This seems insufficient for the following reasons: +</p> + +<ol> +<li>Doesn't define what that value received is.</li> +<li>Doesn't state the result is repeatable</li> +<li> Doesn't require that doing addition, subtraction and other +operations on all values is defined behaviour.</li> +</ol> + +<p><i>[ +Batavia: Related to +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>. +Pete: is there an ISO definition of modulo? Underflow on signed behavior is undefined. +]</i></p> + + +<p><i>[ +Bellevue: accept resolution, move to ready status. +Does this mandate that is_modulo be true on platforms for which int +happens to b modulo? A: the standard already seems to require that. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Suggest 18.2.1.2 [numeric.limits.members], paragraph 57 is amended to: +</p> + +<blockquote><p> +A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers +and have a result that wraps around to a third number that is less.</del> +<ins>given any operation involving +,- or * on values of that type whose value +would fall outside the range <tt>[min(), max()]</tt>, then the value returned +differs from the true value by an integer multiple of <tt>(max() - min() + +1)</tt>.</ins> +</p></blockquote> + + + + + + +<hr> +<h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3> +<p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-11-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided +for all specializations." +</p> +<p> +Then it goes on to show specializations for float and bool, where one member +is missing (max_digits10). +</p> + +<p> +Maarten Kronenburg adds: +</p> + +<p> +I agree, just adding the comment that the exact number of decimal digits +is digits * ln(radix) / ln(10), where probably this real number is +rounded downward for digits10, and rounded upward for max_digits10 +(when radix=10, then digits10=max_digits10). +Why not add this exact definition also to the standard, so the user +knows what these numbers exactly mean. +</p> + +<p> +Howard adds: +</p> + +<p> +For reference, here are the correct formulas from +<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf">N1822</a>: +</p> + +<blockquote><pre>digits10 = floor((digits-1) * log10(2)) +max_digits10 = ceil((1 + digits) * log10(2)) +</pre></blockquote> + +<p> +We are also missing a statement regarding for what specializations this member has meaning. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change and add after 18.2.1.2 [numeric.limits.members], p11: +</p> + +<blockquote> +<pre>static const int max_digits10;</pre> +<blockquote> +<p> +-11- Number of base 10 digits required to ensure that values which +differ <del>by only one epsilon</del> are always differentiated. +</p> +<p><ins> +-12- Meaningful for all floating point types. +</ins></p> +</blockquote> +</blockquote> + +<p> +Change 18.2.1.5 [numeric.special], p2: +</p> + +<blockquote><pre>template<> class numeric_limits<float> { +public: + static const bool is_specialized = true; + ... + static const int digits10 = 6; + <ins>static const int max_digits10 = 9</ins>; + ... +</pre></blockquote> + +<p> +Change 18.2.1.5 [numeric.special], p3: +</p> + +<blockquote><pre>template<> class numeric_limits<bool> { +public: + static const bool is_specialized = true; + ... + static const int digits10 = 0; + <ins>static const int max_digits10 = 0</ins>; + ... +</pre></blockquote> + + + + + + + +<hr> +<h3><a name="616"></a>616. missing 'typename' in ctype_byname</h3> +<p><b>Section:</b> 22.2.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-16</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 22.2.1.2 defines the ctype_byname class template. It contains the +line +</p> + +<blockquote><pre>typedef ctype<charT>::mask mask; +</pre></blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +as this is a dependent type, it should obviously be +</p> + +<blockquote><pre>typedef <ins>typename</ins> ctype<charT>::mask mask; +</pre></blockquote> + + + + + +<hr> +<h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3> +<p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I would respectfully request an issue be opened with the intention to +clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.5.2.7 [valarray.members], paragraph 10: +</p> + +<blockquote> + +<pre>valarray<T> cshift(int <i>n</i>) const; +</pre> + +<blockquote> +<p> +This function returns an object of class <tt>valarray<T></tt>, of +length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is +<tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as +the leftmost element, a positive value of <i>n</i> shifts the elements +circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If +element zero is taken as the leftmost element, a non-negative value of +<i>n</i> shifts the elements circularly left <i>n</i> places and a +negative value of <i>n</i> shifts the elements circularly right +-<i>n</i> places.</ins> +</p> +</blockquote> +</blockquote> + + + +<p><b>Rationale:</b></p> +<p> +We do not believe that there is any real ambiguity about what happens +when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++ +expression causes more trouble that it solves. The expression is +certainly wrong when <tt>n < 0</tt>, since the sign of % with negative arguments +is implementation defined. +</p> + + +<p><i>[ +Kona (2007) Changed proposed wording, added rationale and set to Review. +]</i></p> + + + + + +<hr> +<h3><a name="619"></a>619. Longjmp wording problem</h3> +<p><b>Section:</b> 18.9 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2007-01-12</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The wording for <tt>longjmp</tt> is confusing. +</p> +<p> +18.9 [support.runtime] -4- Other runtime support +</p> +<blockquote><p> +The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted +behavior in this International Standard. If any automatic objects would +be destroyed by a thrown exception transferring control to another +(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that +the throw point that transfers control to the same (destination) point has +undefined behavior. +</p></blockquote> +<p> +Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt> +*at* the throw point that transfers control". +</p> +<p> +Bill Gibbons thinks it should say something like "If any automatic objects +would be destroyed by an exception thrown at the point of the longjmp and +caught only at the point of the setjmp, the behavior is undefined." +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In general, accept Bill Gibbons' recommendation, +but add "call" to indicate that the undefined behavior +comes from the dynamic call, not from its presence in the code. +In 18.9 [support.runtime] paragraph 4, change +</p> + +<blockquote><p> +The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more +restricted behavior in this International Standard. <del>If any automatic +objects would be destroyed by a thrown exception transferring control to another +(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> +that the throw point that transfers control to the same (destination) point has +undefined behavior.</del> <ins>A <tt>setjmp</tt>/<tt>longjmp</tt> call pair has +undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by +<tt>catch</tt> and <tt>throw</tt> would destroy any automatic objects.</ins> +</p></blockquote> + + + + + +<hr> +<h3><a name="620"></a>620. valid uses of empty valarrays</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The <i>Effects</i> clause for the default <code>valarray</code> ctor +suggests that it is possible to increase the size of an empty +<code>valarray</code> object by calling other non-const member +functions of the class besides <code>resize()</code>. However, such an +interpretation would be contradicted by the requirement on the copy +assignment operator (and apparently also that on the computed +assignments) that the assigned arrays be the same size. See the +reflector discussion starting with c++std-lib-17871. + + </p> + <p> + +In addition, <i>Footnote</i> 280 uses some questionable normative +language. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.5.2.1 [valarray.cons]): + + </p> + <blockquote> + <p> + +<code>valarray();</code> + + </p> + <p> + +<i>Effects</i>: Constructs an object of class +<code>valarray<T></code>,<sup>279)</sup> which has zero +length<del> until it is passed into a library function as a modifiable +lvalue or through a non-constant this pointer</del>.<sup>280)</sup> + + </p> + <p> + +<ins><i>Postcondition</i>: <code>size() == 0</code>.</ins> + + </p> + <p> + +<i>Footnote 280</i>: This default constructor is essential, since +arrays of <code>valarray</code> <del>are likely to prove useful. +There shall also be a way to change the size of an array after +initialization; this is supplied by the semantics</del> <ins>may be +useful. The length of an empty array can be increased after +initialization by means</ins> of the <code>resize()</code> member +function. + + </p> + </blockquote> + + + + + +<hr> +<h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3> +<p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The computed and "fill" assignment operators of <code>valarray</code> +helper array class templates (<code>slice_array</code>, +<code>gslice_array</code>, <code>mask_array</code>, and +<code>indirect_array</code>) are const member functions of each class +template (the latter by the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a> +since they have reference semantics and thus do not affect +the state of the object on which they are called. However, the copy +assignment operators of these class templates, which also have +reference semantics, are non-const. The absence of constness opens +the door to speculation about whether they really are intended to have +reference semantics (existing implementations vary widely). + + </p> + +<p> +Pre-Kona, Martin adds: +</p> + +<p> +I realized that adding the const qualifier to the +functions as I suggested would break the const correctness of the +classes. A few possible solutions come to mind: +</p> + +<ol> +<li>Add the const qualifier to the return types of these functions.</li> +<li>Change the return type of all the functions to void to match +the signatures of all the other assignment operators these classes +define.</li> +<li>Prohibit the copy assignment of these classes by declaring the +copy assignment operators private (as is done and documented by +some implementations).</li> +</ol> + + + +<p><b>Proposed resolution:</b></p> + <p> + +Declare the copy assignment operators of all four helper array +class templates const. + + </p> + <p> + +Specifically, make the following edits: + + </p> + <p> + +Change the signature in 26.5.5 [template.slice.array] and +26.5.5.1 [slice.arr.assign] as follows: + + </p> + <blockquote><pre> +<code><ins>const</ins> slice_array& operator= (const slice_array&)<ins> const</ins>;</code> + + </pre></blockquote> + <p> + +Change the signature in 26.5.7 [template.gslice.array] and +26.5.7.1 [gslice.array.assign] as follows: + + </p> + <blockquote><pre> +<code><ins>const</ins> gslice_array& operator= (const gslice_array&)<ins> const</ins>;</code> + + </pre></blockquote> + <p> + +Change the signature in 26.5.8 [template.mask.array] and 26.5.8.1 [mask.array.assign] as +follows: + + </p> + <blockquote><pre> +<code><ins>const</ins> mask_array& operator= (const mask_array&)<ins> const</ins>;</code> + + </pre></blockquote> + <p> + +Change the signature in 26.5.9 [template.indirect.array] and +26.5.9.1 [indirect.array.assign] as follows: + + </p> + <blockquote><pre> +<code><ins>const</ins> indirect_array& operator= (const indirect_array&)<ins> const</ins>;</code> + + </pre></blockquote> + + +<p><i>[ +Kona (2007) Added const qualification to the return types and set to Ready. +]</i></p> + + + + + +<hr> +<h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3> +<p><b>Section:</b> 27.8.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +<code>basic_filebuf</code> dtor is specified to have the following +straightforward effects: + + </p> + <blockquote><p> + +<i>Effects</i>: Destroys an object of class +<code>basic_filebuf</code>. Calls <code>close()</code>. + + </p></blockquote> + <p> + +<code>close()</code> does a lot of potentially complicated processing, +including calling <code>overflow()</code> to write out the termination +sequence (to bring the output sequence to its initial shift +state). Since any of the functions called during the processing can +throw an exception, what should the effects of an exception be on the +dtor? Should the dtor catch and swallow it or should it propagate it +to the caller? The text doesn't seem to provide any guidance in this +regard other than the general restriction on throwing (but not +propagating) exceptions from destructors of library classes in +17.4.4.9 [res.on.exception.handling]. + + </p> + <p> + +Further, the last thing <code>close()</code> is specified to do is +call <code>fclose()</code> to close the <code>FILE</code> pointer. The +last sentence of the <i>Effects</i> clause reads: + + </p> + <blockquote><p> + +... If any of the calls to <code>overflow</code> or +<code>std::fclose</code> fails then <code>close</code> fails. + + </p></blockquote> + <p> + +This suggests that <code>close()</code> might be required to call +<code>fclose()</code> if and only if none of the calls to +<code>overflow()</code> fails, and avoid closing the <code>FILE</code> +otherwise. This way, if <code>overflow()</code> failed to flush out +the data, the caller would have the opportunity to try to flush it +again (perhaps after trying to deal with whatever problem may have +caused the failure), rather than losing it outright. + + </p> + <p> + +On the other hand, the function's <i>Postcondition</i> specifies that +<code>is_open() == false</code>, which suggests that it should call +<code>fclose()</code> unconditionally. However, since +<i>Postcondition</i> clauses are specified for many functions in the +standard, including constructors where they obviously cannot apply +after an exception, it's not clear whether this <i>Postcondition</i> +clause is intended to apply even after an exception. + + </p> + <p> + +It might be worth noting that the traditional behavior (Classic +Iostreams <code>fstream::close()</code> and C <code>fclose()</code>) +is to close the <code>FILE</code> unconditionally, regardless of +errors. + + </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-active.html#418">418</a> for related issues. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> + <p> + +After discussing this on the reflector (see the thread starting with +c++std-lib-17650) we propose that <code>close()</code> be clarified to +match the traditional behavior, that is to close the <code>FILE</code> +unconditionally, even after errors or exceptions. In addition, we +propose the dtor description be amended so as to explicitly require it +to catch and swallow any exceptions thrown by <code>close()</code>. + + </p> + <p> + +Specifically, we propose to make the following edits in +27.8.1.4 [filebuf.members]: + + </p> + <blockquote> + <pre> +<code>basic_filebuf<charT,traits>* close();</code> + + </pre> + <p> + +<i>Effects</i>: If <code>is_open() == false</code>, returns a null +pointer. If a put area exists, calls +<code>overflow(traits::eof())</code> to flush characters. If the last +virtual member function called on <code>*this</code> (between +<code>underflow</code>, <code>overflow</code>, <code>seekoff</code>, +and <code>seekpos</code>) was <code>overflow</code> then calls +<code>a_codecvt.unshift</code> (possibly several times) to determine a +termination sequence, inserts those characters and calls +<code>overflow(traits::eof())</code> again. Finally<ins>, regardless +of whether any of the preceding calls fails or throws an exception, +the function</ins> <del>it</del> closes the file ("as if" by calling +<code>std::fclose(file)</code>).<sup>334)</sup> If any of the calls +<ins>made by the function</ins><del>to <code>overflow</code> +or</del><ins>, including </ins><code>std::fclose</code><ins>, </ins> +fails then <code>close</code> fails<ins> by returning a null pointer. +If one of these calls throws an exception, the exception is caught and +rethrown after closing the file.</ins> + + </p> + </blockquote> + <p> + +And to make the following edits in 27.8.1.2 [filebuf.cons]. + + </p> + <blockquote> + <pre> +<code>virtual ~basic_filebuf();</code> + + </pre> + <p> + +<i>Effects</i>: Destroys an object of class +<code>basic_filebuf<charT,traits></code>. Calls +<code>close()</code>. <ins>If an exception occurs during the +destruction of the object, including the call to <code>close()</code>, +the exception is caught but not rethrown (see +17.4.4.9 [res.on.exception.handling]).</ins> + + </p> + </blockquote> + + + + + +<hr> +<h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3> +<p><b>Section:</b> 27.1.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +27.1.1 [iostream.limits.imbue] specifies that "no function described in +clause 27 except for <code>ios_base::imbue</code> causes any instance +of <code>basic_ios::imbue</code> or +<code>basic_streambuf::imbue</code> to be called." + + </p> + <p> + +That contradicts the <i>Effects</i> clause for +<code>basic_streambuf::pubimbue()</code> which requires the function +to do just that: call <code>basic_streambuf::imbue()</code>. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +To fix this, rephrase the sentence above to allow +<code>pubimbue</code> to do what it was designed to do. Specifically. +change 27.1.1 [iostream.limits.imbue], p1 to read: + + </p> + <blockquote><p> + +No function described in clause 27 except for +<code>ios_base::imbue</code> <ins>and <code>basic_filebuf::pubimbue</code></ins> +causes any instance of <code>basic_ios::imbue</code> or +<code>basic_streambuf::imbue</code> to be called. ... + + </p></blockquote> + + + + + +<hr> +<h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3> +<p><b>Section:</b> 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The behavior of the <code>valarray</code> copy assignment operator is +defined only when both sides have the same number of elements and the +spec is explicit about assignments of arrays of unequal lengths having +undefined behavior. + + </p> + <p> + +However, the generalized subscripting assignment operators overloaded +on <code>slice_array</code> et al (26.5.2.2 [valarray.assign]) don't have any +such restriction, leading the reader to believe that the behavior of +these overloads is well defined regardless of the lengths of the +arguments. + + </p> + <p> + +For example, based on the reading of the spec the behavior of the +snippet below can be expected to be well-defined: + + </p> + <pre> const std::slice from_0_to_3 (0, 3, 1); // refers to elements 0, 1, 2 + const std::valarray<int> a (1, 3); // a = { 1, 1, 1 } + std::valarray<int> b (2, 4); // b = { 2, 2, 2, 2 } + + b = a [from_0_to_3]; + </pre> + <p> + +In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>, +<code>{ 1, 1, 1, 2 }</code>, or anything else, indicating that +existing implementations vary. + + </p> + +<p> +Quoting from Section 3.4, Assignment operators, of Al Vermeulen's +Proposal for Standard C++ Array Classes (see c++std-lib-704; +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>): +</p> +<blockquote><p> + ...if the size of the array on the right hand side of the equal + sign differs from the size of the array on the left, a run time + error occurs. How this error is handled is implementation + dependent; for compilers which support it, throwing an exception + would be reasonable. +</p></blockquote> + +<p> +And see more history in +<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>. +</p> + + <p> + +It has been argued in discussions on the committee's reflector that +the semantics of all <code>valarray</code> assignment operators should +be permitted to be undefined unless the length of the arrays being +assigned is the same as the length of the one being assigned from. See +the thread starting at c++std-lib-17786. + + </p> + <p> + +In order to reflect such views, the standard must specify that the +size of the array referred to by the argument of the assignment must +match the size of the array under assignment, for example by adding a +<i>Requires</i> clause to 26.5.2.2 [valarray.assign] as follows: + + </p> + <blockquote><p> + +<i>Requires</i>: The length of the array to which the argument refers +equals <code>size()</code>. + + </p></blockquote> + + <p> + +Note that it's far from clear that such leeway is necessary in order +to implement <code>valarray</code> efficiently. + + </p> + + +<p><b>Proposed resolution:</b></p> +<p> +Insert new paragraph into 26.5.2.2 [valarray.assign]: +</p> + +<blockquote> +<pre>valarray<T>& operator=(const slice_array<T>&); +valarray<T>& operator=(const gslice_array<T>&); +valarray<T>& operator=(const mask_array<T>&); +valarray<T>& operator=(const indirect_array<T>&); +</pre> +<blockquote> +<p><ins> +<i>Requires</i>: The length of the array to which the argument refers +equals <code>size()</code>. +</ins></p> +<p> +These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>. +</p> +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</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#WP">WP</a> + <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-01-23</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 28.8 [re.regex] lists a constructor +</p> + +<blockquote><pre>template<class InputIterator> +basic_regex(InputIterator first, InputIterator last, + flag_type f = regex_constants::ECMAScript); +</pre></blockquote> + +<p> +However, in section 28.8.2 [re.regex.construct], this constructor takes a +pair of <tt>ForwardIterator</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 28.8.2 [re.regex.construct]: +</p> + +<blockquote><pre>template <class <del>ForwardIterator</del> <ins>InputIterator</ins>> + basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last, + flag_type f = regex_constants::ECMAScript); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&</tt></h3> +<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-07</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p> +<p><b>Discussion:</b></p> + +<p> +20.7.5.1 [allocator.members] says: +</p> +<blockquote> +<pre>pointer address(reference <i>x</i>) const;</pre> +<blockquote> +<p> +-1- <i>Returns:</i> <tt>&<i>x</i></tt>. +</p> +</blockquote> +</blockquote> + +<p> +20.7.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not +only defines the semantics of copy construction, but also restricts what an overloaded +<tt>operator&</tt> may do. I believe proposals are in the works (such as concepts +and rvalue reference) to decouple these two requirements. Indeed it is not evident +that we should disallow overloading <tt>operator&</tt> to return something other +than the address of <tt>*this</tt>. +</p> + +<p> +An example of when you want to overload <tt>operator&</tt> to return something +other than the object's address is proxy references such as <tt>vector<bool></tt> +(or its replacement, currently code-named <tt>bit_vector</tt>). Taking the address of +such a proxy reference should logically yield a proxy pointer, which when dereferenced, +yields a copy of the original proxy reference again. +</p> + +<p> +On the other hand, some code truly needs the address of an object, and not a proxy +(typically for determining the identity of an object compared to a reference object). +<a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with +<a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>. +It appears to me that this would be useful functionality for the default allocator. Adopting +this definition for <tt>allocator::address</tt> would free the standard of requiring +anything special from types which overload <tt>operator&</tt>. Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a> +is expected to make use of <tt>allocator::address</tt> mandatory for containers. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.7.5.1 [allocator.members]: +</p> + +<blockquote> +<pre>pointer address(reference <i>x</i>) const;</pre> +<blockquote> +<p> +-1- <i>Returns:</i> <del><tt>&<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>, +even in the presence of an overloaded <tt>operator&</tt>.</ins> +</p> +</blockquote> + +<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre> +<blockquote> +<p> +-2- <i>Returns:</i> <del><tt>&<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>, +even in the presence of an overloaded <tt>operator&</tt>.</ins> +</p> +</blockquote> +</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): The LWG adopted the proposed resolution of N2387 for this issue which +was subsequently split out into a separate paper N2436 for the purposes of voting. +The resolution in N2436 addresses this issue. The LWG voted to accelerate this +issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + + + +<hr> +<h3><a name="638"></a>638. deque end invalidation during erase</h3> +<p><b>Section:</b> 23.2.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Steve LoBasso <b>Date:</b> 2007-02-17</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The standard states at 23.2.2.3 [deque.modifiers]/4: +</p> +<blockquote><pre>deque erase(...) +</pre> + <p> +<i>Effects:</i> ... An erase at either end of the deque invalidates only +the iterators and the references to the erased elements. +</p> +</blockquote> +<p> +This does not state that iterators to end will be invalidated. +It needs to be amended in such a way as to account for end invalidation. +</p> +<p> +Something like: +</p> +<blockquote><p> +Any time the last element is erased, iterators to end are invalidated. +</p></blockquote> + +<p> +This would handle situations like: +</p> +<blockquote><pre>erase(begin(), end()) +erase(end() - 1) +pop_back() +resize(n, ...) where n < size() +pop_front() with size() == 1 + +</pre></blockquote> + +<p><i>[ +Post Kona, Steve LoBasso notes: +]</i></p> + + +<blockquote> +My only issue with the proposed resolution is that it might not be clear +that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end +iterators. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 23.2.2.3 [deque.modifiers], p4: +</p> + +<blockquote> +<pre>iterator erase(const_iterator position); +iterator erase(const_iterator first, const_iterator last); +</pre> + +<blockquote> +<p> +-4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt> +invalidates all the iterators and references to elements of the +<tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at +either end of the <tt>deque</tt> invalidates only the iterators and the +references to the erased elements<ins>, except that erasing at the end +also invalidates the past-the-end iterator</ins>. +</p> +</blockquote> +</blockquote> + + + +<p><i>[ +Kona (2007): Proposed wording added and moved to Review. +]</i></p> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Note that there is existing code that relies on iterators not being +invalidated, but there are also existing implementations that do +invalidate iterators. Thus, such code is not portable in any case. There +is a pop_front() note, which should possibly be a separate issue. Mike +Spertus to evaluate and, if need be, file an issue. +</blockquote> + + + + +<hr> +<h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3> +<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic]. +Although the section starts with a listing of the inserters including +the new ones: +</p> + +<blockquote><pre>operator<<(long long val ); +operator<<(unsigned long long val ); +</pre></blockquote> + +<p> +the text in paragraph 1, which describes the corresponding effects +of the inserters, depending on the actual type of val, does not +handle the types <tt>long long</tt> and <tt>unsigned long long</tt>. +</p> + +<p><i>[ +Alisdair: In addition to the (unsigned) long long problem, that whole paragraph +misses any reference to extended integral types supplied by the +implementation - one of the additions by core a couple of working papers +back. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence +</p> + +<blockquote> +When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned +long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>, +<tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion +occurs as if it performed the following code fragment: +</blockquote> + + + + + +<hr> +<h3><a name="643"></a>643. Impossible "as if" clauses</h3> +<p><b>Section:</b> 27.8.1.1 [filebuf], 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#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current standard 14882:2003(E) as well as N2134 have the +following +defects: +</p> + +<p> +27.8.1.1 [filebuf]/5 says: +</p> + +<blockquote> +<p> +In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a +facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by +</p> +<blockquote><pre>codecvt<charT,char,typename traits::state_type> <i>a_codecvt</i> = + use_facet<codecvt<charT,char,typename traits::state_type> >(getloc()); +</pre></blockquote> +</blockquote> + +<p> +<tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is +copyconstructible, so the codecvt construction should fail to compile. +</p> + +<p> +A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 27.8.1.1 [filebuf]/5 change the "as if" code +</p> + +<blockquote><pre><ins>const </ins>codecvt<charT,char,typename traits::state_type><ins>&</ins> <i>a_codecvt</i> = + use_facet<codecvt<charT,char,typename traits::state_type> >(getloc()); +</pre></blockquote> + +<p> +In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change +</p> + +<blockquote> +<p> +A local variable <tt><i>punct</i></tt> is initialized via +</p> +<blockquote><pre><ins>const </ins>numpunct<charT><ins>&</ins> <i>punct</i> = use_facet< numpunct<charT> >(<i>str</i>.getloc() )<ins>;</ins> +</pre></blockquote> +</blockquote> + +<p> +(Please note also the additional provided trailing semicolon) +</p> + + + + + + +<hr> +<h3><a name="646"></a>646. const incorrect match_result members</h3> +<p><b>Section:</b> 28.10.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template +members format as non-const functions, although they are declared +as const in 28.10 [re.results]/3. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described +in section 28.10.4 [re.results.form]. +</p> + + + + + +<hr> +<h3><a name="650"></a>650. regex_token_iterator and const correctness</h3> +<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Both the class definition of regex_token_iterator (28.12.2 +[re.tokiter]/6) and the latter member specifications (28.12.2.2 +[re.tokiter.comp]/1+2) declare both comparison operators as +non-const functions. Furtheron, both dereference operators are +unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6 +as well as in (28.12.2.3 [re.tokiter.deref]/1+2). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +1) In (28.12.2 [re.tokiter]/6) change the current declarations +</p> + +<blockquote><pre>bool operator==(const regex_token_iterator&) <ins>const</ins>; +bool operator!=(const regex_token_iterator&) <ins>const</ins>; +const value_type& operator*() <ins>const</ins>; +const value_type* operator->() <ins>const</ins>; +</pre></blockquote> + +<p> +2) In 28.12.2.2 [re.tokiter.comp] change the following declarations +</p> + +<blockquote><pre>bool operator==(const regex_token_iterator& right) <ins>const</ins>; +bool operator!=(const regex_token_iterator& right) <ins>const</ins>; +</pre></blockquote> + +<p> +3) In 28.12.2.3 [re.tokiter.deref] change the following declarations +</p> + +<blockquote><pre>const value_type& operator*() <ins>const</ins>; +const value_type* operator->() <ins>const</ins>; +</pre></blockquote> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which +is to adopt the proposed wording in this issue). +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3> +<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes +the effects of the three non-default constructors of class +template regex_token_iterator but is does not clarify which values +are legal values for submatch/submatches. This becomes +an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains +the notion of a "current match" by saying: +</p> + +<blockquote><p> +The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N] +== -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of +<tt>subs[N]</tt>. +</p></blockquote> + +<p> +It's not clear to me, whether other negative values except -1 +are legal arguments or not - it seems they are not. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following precondition paragraph just before the current +28.12.2.1 [re.tokiter.cnstr]/2: +</p> + +<blockquote><p> +<i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>>= -1</tt>. +</p></blockquote> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which +is to adopt the proposed wording in this issue). +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="652"></a>652. regex_iterator and const correctness</h3> +<p><b>Section:</b> 28.12.1 [re.regiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Both the class definition of regex_iterator (28.12.1 [re.regiter]/1) +and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2) +declare both comparison operators as +non-const functions. Furtheron, both dereference operators are +unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1 +as well as in (28.12.1.3 [re.regiter.deref]/1+2). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +1) In (28.12.1 [re.regiter]/1) change the current declarations +</p> + +<blockquote><pre>bool operator==(const regex_iterator&) <ins>const</ins>; +bool operator!=(const regex_iterator&) <ins>const</ins>; +const value_type& operator*() <ins>const</ins>; +const value_type* operator->() <ins>const</ins>; +</pre></blockquote> + +<p> +2) In 28.12.1.3 [re.regiter.deref] change the following declarations +</p> + +<blockquote><pre>const value_type& operator*() <ins>const</ins>; +const value_type* operator->() <ins>const</ins>; +</pre></blockquote> + +<p> +3) In 28.12.1.2 [re.regiter.comp] change the following declarations +</p> + +<blockquote><pre>bool operator==(const regex_iterator& right) <ins>const</ins>; +bool operator!=(const regex_iterator& right) <ins>const</ins>; +</pre></blockquote> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which +is to adopt the proposed wording in this issue). +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3> +<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify +the IO insertion and extraction semantic of random +number engines. It can be shown, v.i., that the specification +of the extractor cannot guarantee to fulfill the requirement +from para 5: +</p> + +<blockquote><p> +If a textual representation written via os << x was +subsequently read via is >> v, then x == v provided that +there have been no intervening invocations of x or of v. +</p></blockquote> + +<p> +The problem is, that the extraction process described in +table 98 misses to specify that it will initially set the +if.fmtflags to ios_base::dec, see table 104: +</p> + +<blockquote><p> +dec: converts integer input or generates integer output +in decimal base +</p></blockquote> + +<p> +Proof: The following small program demonstrates the violation +of requirements (exception safety not fulfilled): +</p> + +<blockquote><pre>#include <cassert> +#include <ostream> +#include <iostream> +#include <iomanip> +#include <sstream> + +class RanNumEngine { + int state; +public: + RanNumEngine() : state(42) {} + + bool operator==(RanNumEngine other) const { + return state == other.state; + } + + template <typename Ch, typename Tr> + friend std::basic_ostream<Ch, Tr>& operator<<(std::basic_ostream<Ch, Tr>& os, RanNumEngine engine) { + Ch old = os.fill(os.widen(' ')); // Sets space character + std::ios_base::fmtflags f = os.flags(); + os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left + os.fill(old); // Undo + os.flags(f); + return os; + } + + template <typename Ch, typename Tr> + friend std::basic_istream<Ch, Tr>& operator>>(std::basic_istream<Ch, Tr>& is, RanNumEngine& engine) { + // Uncomment only for the fix. + + //std::ios_base::fmtflags f = is.flags(); + //is >> std::dec; + is >> engine.state; + //is.flags(f); + return is; + } +}; + +int main() { + std::stringstream s; + s << std::setfill('#'); // No problem + s << std::oct; // Yikes! + // Here starts para 5 requirements: + RanNumEngine x; + s << x; + RanNumEngine v; + s >> v; + assert(x == v); // Fails: 42 == 34 +} +</pre></blockquote> + +<p> +A second, minor issue seems to be, that the insertion +description from table 98 unnecessarily requires the +addition of ios_base::fixed (which only influences floating-point +numbers). Its not entirely clear to me whether the proposed +standard does require that the state of random number engines +is stored in integral types or not, but I have the impression +that this is the indent, see e.g. p. 3 +</p> + +<blockquote><p> +The specification of each random number engine defines the +size of its state in multiples of the size of its result_type. +</p></blockquote> + +<p> +If other types than integrals are supported, then I wonder why +no requirements are specified for the precision of the stream. +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +for some further discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="655"></a>655. Signature of generate_canonical not useful</h3> +<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 26.4.2 [rand.synopsis] we have the declaration +</p> + +<blockquote><pre>template<class RealType, class UniformRandomNumberGenerator, + size_t bits> +result_type generate_canonical(UniformRandomNumberGenerator& g); +</pre></blockquote> + +<p> +Besides the "result_type" issue (already recognized by Bo Persson +at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that +the template parameter order is not reasonably choosen: Obviously +one always needs to specify all three parameters, although usually +only two are required, namely the result type RealType and the +wanted bits, because UniformRandomNumberGenerator can usually +be deduced. +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +for some further discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="660"></a>660. Missing Bitwise Operations</h3> +<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-04-02</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p>Section 20.6 [function.objects] provides <span id="st" name="st" class="st">function</span> +<span id="st" name="st" class="st">objects</span> for some unary and binary +operations, but others are missing. In a LWG reflector discussion, beginning +with c++std-lib-18078, pros and cons of adding some of the missing operations +were discussed. Bjarne Stroustrup commented "Why standardize what isn't used? +Yes, I see the chicken and egg problems here, but it would be nice to see a +couple of genuine uses before making additions."</p> +<p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have +already added these functions, either publicly or for internal use. For example, +Doug Gregor commented: "Boost will also add ... (|, &, ^) in 1.35.0, because we +need those <span id="st" name="st" class="st">function</span> +<span id="st" name="st" class="st">objects</span> to represent various parallel +collective operations (reductions, prefix reductions, etc.) in the new Message +Passing Interface (MPI) library."</p> +<p>Because the bitwise operators have the strongest use cases, the proposed +resolution is limited to them.</p> + + +<p><b>Proposed resolution:</b></p> +<p>To 20.6 [function.objects], Function objects, paragraph 2, add to the header +<functional> synopsis:</p> +<blockquote> + <pre>template <class T> struct bit_and; +template <class T> struct bit_or; +template <class T> struct bit_xor;</pre> +</blockquote> +<p>At a location in clause 20 to be determined by the Project Editor, add:</p> +<blockquote> + <p>The library provides basic function object classes for all of the bitwise + operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p> + <pre>template <class T> struct bit_and : binary_function<T,T,T> { + T operator()(const T& x , const T& y ) const; +};</pre> + <blockquote> + <p><code>operator()</code> returns<code> x & y</code> .</p> + </blockquote> + <pre>template <class T> struct bit_or : binary_function<T,T,T> { + T operator()(const T& x , const T& y ) const; +};</pre> + <blockquote> + <p><code>operator()</code> returns <code>x | y</code> .</p> + </blockquote> + <pre>template <class T> struct bit_xor : binary_function<T,T,T> { + T operator()(const T& x , const T& y ) const; +};</pre> + <blockquote> + <p><code>operator()</code> returns <code>x ^ y</code> .</p> + </blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</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#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-04-01</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong +the explicit description of the extraction of the types short and int in +terms of as-if code fragments. +</p> + +<ol> +<li> +The corresponding as-if extractions in paragraph 2 and 3 will never +result in a change of the operator>> argument val, because the +contents of the local variable lval is in no case written into val. +Furtheron both fragments need a currently missing parentheses in the +beginning of the if-statement to be valid C++. +</li> +<li>I would like to ask whether the omission of a similar explicit +extraction of unsigned short and unsigned int in terms of long - +compared to their corresponding new insertions, as described in +27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or +an +oversight. +</li> +</ol> + + +<p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment +</p> +<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; +iostate err = 0; +long lval; +use_facet<numget>(loc).get(*this, 0, *this, err, lval ); +if (err == 0) <ins>{</ins> + <del>&&</del> <ins>if</ins> (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval)<del>)</del> + err = ios_base::failbit; + <ins>else + val = static_cast<short>(lval); +}</ins> +setstate(err); +</pre></blockquote> + +<p> +Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment +</p> + +<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; +iostate err = 0; +long lval; +use_facet<numget>(loc).get(*this, 0, *this, err, lval ); +if (err == 0) <ins>{</ins> + <del>&&</del> <ins>if</ins> (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval)<del>)</del> + err = ios_base::failbit; + <ins>else + val = static_cast<int>(lval); +}</ins> +setstate(err); +</pre></blockquote> +</li> +<li> +--- +</li> +</ol> + + +<p><i>[ +Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt> +is incorrectly italicized in the code fragments corresponding to +<tt>operator>>(short &)</tt> and <tt>operator >>(int &)</tt>. Also, val -- which appears +twice on the line with the <tt>static_cast</tt> in the proposed resolution -- +should be italicized. Also, in response to part two of the issue: this +is deliberate. +]</i></p> + + + + + +<hr> +<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt<char, char, mbstate_t></tt></h3> +<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>): +</p> + +<blockquote><p> +<i>Effects:</i> Places characters starting at to that should be appended to +terminate a sequence when the current <tt>stateT</tt> is given by +<tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> - +<i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt> +pointer pointing one beyond the last element successfully stored. +<em><tt>codecvt<char, char, mbstate_t></tt> stores no characters.</em> +</p></blockquote> + +<p> +The following objection has been raised: +</p> + +<blockquote><p> +Since the C++ Standard permits a nontrivial conversion for the required +instantiations of <tt>codecvt</tt>, it is overly restrictive to say that +<tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>. +</p></blockquote> + +<p> +[Plum ref _222152Y50] +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 22.2.1.4.2 [locale.codecvt.virtuals], p7: +</p> + +<blockquote> +<p> +<i>Effects:</i> Places characters starting at <i>to</i> that should be +appended to terminate a sequence when the current <tt>stateT</tt> is +given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>) +destination elements, and leaves the <i>to_next</i> pointer pointing one +beyond the last element successfully stored. <del><tt>codecvt<char, char, +mbstate_t></tt> stores no characters.</del> +</p> +</blockquote> + + + + + +<hr> +<h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3> +<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +22.2.1.4.2 [locale.codecvt.virtuals], para 8 says: +</p> + +<blockquote><p> +<tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>. +</p></blockquote> + +<p> +The following objection has been raised: +</p> + +<blockquote><p> +Despite what the C++ Standard +says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since +they can be nontrivial. At least one implementation does whatever the +C functions do. +</p></blockquote> + +<p> +[Plum ref _222152Y62] +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 22.2.1.4.2 [locale.codecvt.virtuals], p8: +</p> + +<blockquote> +<p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p> +<p>...</p> +<p> +<del><tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>.</del> +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3> +<p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says +</p> + +<blockquote><p> +<sup>257)</sup> For international +specializations (second template parameter <tt>true</tt>) this is always four +characters long, usually three letters and a space. +</p></blockquote> + +<p> +The following objection has been raised: +</p> + +<blockquote><p> +The international currency +symbol is whatever the underlying locale says it is, not necessarily +four characters long. +</p></blockquote> + +<p> +[Plum ref _222632Y41] +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]: +</p> + +<blockquote> +<p> +<sup>253)</sup> For international specializations (second template +parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins> +four characters long, usually three letters and a space. +</p> +</blockquote> + + + + + +<hr> +<h3><a name="672"></a>672. Swappable requirements need updating</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#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current <tt>Swappable</tt> is: +</p> + +<blockquote> +<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(s,t)</tt></td><td><tt>void</tt></td><td><tt>t</tt> has the value originally held by <tt>u</tt>, and <tt>u</tt> has the value originally +held by <tt>t</tt></td></tr> +<tr><td colspan="3"> +<p> +The Swappable requirement is met by satisfying one or more of the following conditions: +</p> +<ul> +<li> +<tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34) +and the <tt>CopyAssignable</tt> requirements (Table 36); +</li> +<li> +<tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same +namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid +and has the semantics described in this table. +</li> +</ul> +</td></tr> +</tbody></table> +</blockquote> + +<p> +With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to +require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>. This is a minimum. +</p> + +<p> +Additionally we may want to support proxy references such that the following code is acceptable: +</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; +swap(*i1, a); +</pre></blockquote> + +<p> +I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class +itself. We do not need to anything in terms of implementation except not block their way with overly +constrained concepts. That is, the <tt>Swappable</tt> concept should be expanded to allow swapping +between two different types for the case that one is binding to a user-defined <tt>swap</tt>. +</p> + + + +<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> is a type 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>; and <tt>rv</tt> is a non-<tt>const</tt> +rvalue of type <tt>T</tt>. +</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(s,t)</tt></td><td><tt>void</tt></td> +<td><tt>t</tt> has the value originally +held by <tt>u</tt>, and +<tt>u</tt> has the value originally held +by <tt>t</tt></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 <tt>T</tt> satisfies the +<del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins> +requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins> +requirements (Table <del>36</del> <ins>35</ins>); +</li> +<li> +<tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named +<tt>swap</tt> exists in the same namespace as the definition of +<tt>T</tt>, such that the expression +<tt>swap(t,u)</tt> is valid and has the +semantics described in this table. +</li> +</ul> +</td></tr> +</tbody></table> +</blockquote> + + + +<p><i>[ +Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use +move semantics. The issue relating to the support of proxies is +separable from the one relating to move semantics, and it's bigger than +just swap. We'd like to address only the move semantics changes under +this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>) to handle proxies. Also, there +may be a third issue, in that the current definition of <tt>Swappable</tt> does +not permit rvalues to be operands to a swap operation, and Howard's +proposed resolution would allow the right-most operand to be an rvalue, +but it would not allow the left-most operand to be an rvalue (some swap +functions in the library have been overloaded to permit left operands to +swap to be rvalues). +]</i></p> + + + + + +<hr> +<h3><a name="673"></a>673. <tt>unique_ptr</tt> update</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#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Since the publication of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> +there have been a few small but significant advances which should be included into +<tt>unique_ptr</tt>. There exists a +<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a> +for all of these changes. +</p> + +<ul> + +<li> +<p> +Even though <tt>unique_ptr<void></tt> is not a valid use case (unlike for <tt>shared_ptr<void></tt>), +unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr<void></tt> +even if it is never used. For example see +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently +happened to <tt>auto_ptr</tt>. I believe the most robust way to protect <tt>unique_ptr</tt> against this +type of failure is to augment the return type of <tt>unique_ptr<T>:operator*()</tt> with +<tt>add_lvalue_reference<T>::type</tt>. This means that given an instantiated <tt>unique_ptr<void></tt> +the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure. +This is simpler than creating a <tt>unique_ptr<void></tt> specialization which isn't robust in the +face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types. +</p> + +<p> +This resolution also supports instantiations such as <tt>unique_ptr<void, free_deleter></tt> +which could be very useful to the client. +</p> + +</li> + +<li> +<p> +Efforts have been made to better support containers and smart pointers in shared +memory contexts. One of the key hurdles in such support is not assuming that a +pointer type is actually a <tt>T*</tt>. This can easily be accomplished +for <tt>unique_ptr</tt> by having the deleter define the pointer type: +<tt>D::pointer</tt>. Furthermore this type can easily be defaulted to +<tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer +type (example implementation +<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>). +This change has no run time overhead. It has no interface overhead on +authors of custom delter types. It simply allows (but not requires) +authors of custom deleter types to define a smart pointer for the +storage type of <tt>unique_ptr</tt> if they find such functionality +useful. <tt>std::default_delete</tt> is an example of a deleter which +defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue +and not including a <tt>pointer typedef</tt>. +</p> +</li> + +<li> +<p> +When the deleter type is a function pointer then it is unsafe to construct +a <tt>unique_ptr</tt> without specifying the function pointer in the constructor. +This case is easy to check for with a <tt>static_assert</tt> assuring that the +deleter is not a pointer type in those constructors which do not accept deleters. +</p> + +<blockquote><pre>unique_ptr<A, void(*)(void*)> p(new A); // error, no function given to delete the pointer! +</pre></blockquote> + +</li> + +</ul> + +<p><i>[ +Kona (2007): We don't like the solution given to the first bullet in +light of concepts. The second bullet solves the problem of supporting +fancy pointers for one library component only. The full LWG needs to +decide whether to solve the problem of supporting fancy pointers +piecemeal, or whether a paper addressing the whole library is needed. We +think that the third bullet is correct. +]</i></p> + + +<p><i>[ +Post Kona: Howard adds example user code related to the first bullet: +]</i></p> + + +<blockquote> +<pre>void legacy_code(void*, std::size_t); + +void foo(std::size_t N) +{ + std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free); + legacy_code(ptr.get(), N); +} // unique_ptr used for exception safety purposes +</pre> +</blockquote> + +<p> +I.e. <tt>unique_ptr<void></tt> <i>is</i> a useful tool that we don't want +to disable with concepts. The only part of <tt>unique_ptr<void></tt> we +want to disable (with concepts or by other means) are the two member functions: +</p> + +<blockquote><pre>T& operator*() const; +T* operator->() const; +</pre></blockquote> + + + +<p><b>Proposed resolution:</b></p> + +<p><i>[ +I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review +the proposed resolutions below. +]</i></p> + + +<ul> +<li> + +<p> +Change 20.7.11.2 [unique.ptr.single]: +</p> + +<blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr { + ... + <del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const; + ... +}; +</pre></blockquote> + +<p> +Change 20.7.11.2.4 [unique.ptr.single.observers]: +</p> + +<blockquote><pre><del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const; +</pre></blockquote> + +</li> + +<li> +<p> +Change 20.7.11.2 [unique.ptr.single]: +</p> + +<blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr { +public: + <ins>typedef <i>implementation (see description below)</i> pointer;</ins> + ... + explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p); + ... + unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d); + unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d); + ... + <del>T*</del> <ins>pointer</ins> operator->() const; + <del>T*</del> <ins>pointer</ins> get() const; + ... + <del>T*</del> <ins>pointer</ins> release(); + void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>); +}; +</pre></blockquote> + +<p> +<ins> +-3- If the type <tt>remove_reference<D>::type::pointer</tt> +exists, then <tt>unique_ptr<T, D>::pointer</tt> is a typedef to +<tt>remove_reference<D>::type::pointer</tt>. Otherwise +<tt>unique_ptr<T, D>::pointer</tt> is a typedef to <tt>T*</tt>. +The type <tt>unique_ptr<T, D>::pointer</tt> shall be <tt>CopyConstructible</tt> +and <tt>CopyAssignable</tt>. +</ins> +</p> + +<p> +Change 20.7.11.2.1 [unique.ptr.single.ctor]: +</p> + +<blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p); +... +unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); +unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); +... +unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A& d); +unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&& d); +... +unique_ptr(<del>T*</del> <ins>pointer</ins> p, A& d); +unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&& d); +... +unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A& d); +unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&& d); +... +</pre></blockquote> + +<p> +-23- <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> +<del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a +reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt> +(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr<U,E>::pointer</tt></ins> +<del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del> +<ins>pointer</ins>. +</p> + +<p> +-25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before +the construction, modulo any required offset adjustments resulting from +the cast from <del><tt>U*</tt></del> +<ins><tt>unique_ptr<U,E>::pointer</tt></ins> to <del><tt>T*</tt></del> +<ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the +internally stored deleter which was constructed from +<tt>u.get_deleter()</tt>. +</p> + +<p> +Change 20.7.11.2.3 [unique.ptr.single.asgn]: +</p> + +<blockquote> +<p> +-8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue +<tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del> +<ins><tt>unique_ptr<U,E>::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly +convertible to <del><tt>T*</tt></del> <ins>pointer</ins>. +</p> +</blockquote> + +<p> +Change 20.7.11.2.4 [unique.ptr.single.observers]: +</p> + +<blockquote> +<pre><del>T*</del> <ins>pointer</ins> operator->() const;</pre> +... +<pre><del>T*</del> <ins>pointer</ins> get() const;</pre> +</blockquote> + +<p> +Change 20.7.11.2.5 [unique.ptr.single.modifiers]: +</p> + +<blockquote> +<pre><del>T*</del> <ins>pointer</ins> release();</pre> +... +<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre> +</blockquote> + +<p> +Change 20.7.11.3 [unique.ptr.runtime]: +</p> + +<blockquote><pre>template <class T, class D> class unique_ptr<T[], D> { +public: + <ins>typedef <i>implementation</i> pointer;</ins> + ... + explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p); + ... + unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); + unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); + ... + <del>T*</del> <ins>pointer</ins> get() const; + ... + <del>T*</del> <ins>pointer</ins> release(); + void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>); +}; +</pre></blockquote> + +<p> +Change 20.7.11.3.1 [unique.ptr.runtime.ctor]: +</p> + +<blockquote> +<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p); +unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); +unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); +</pre> + +<p> +These constructors behave the same as in the primary template except +that they do not accept pointer types which are convertible to +<del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One +implementation technique is to create private templated overloads of +these members. <i>-- end note</i>] +</p> +</blockquote> + +<p> +Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]: +</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> + +</li> + +<li> + +<p> +Change 20.7.11.2.1 [unique.ptr.single.ctor]: +</p> + +<blockquote> +<pre>unique_ptr();</pre> +<blockquote> +<p> +<i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that +construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a +reference type <ins>or pointer type (diagnostic required)</ins>. +</p> +</blockquote> +<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre> +<blockquote> +<p> +<i>Requires:</i> The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed. +The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. +<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic +required)</ins>. +</p> +</blockquote> +</blockquote> + +</li> + +</ul> + + + + + + +<hr> +<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</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#WP">WP</a> + <b>Submitter:</b> Peter Dimov <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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose +any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate +and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p> +Change 20.7.12.2 [util.smartptr.shared] as follows: +</p> + +<blockquote> +<pre>template<class Y> explicit shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r); +<ins>template<class Y, class D> explicit shared_ptr(const unique_ptr<Y,D>& r) = delete; +template<class Y, class D> explicit shared_ptr(unique_ptr<Y,D>&& r);</ins> +... +template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r); +<ins>template<class Y, class D> shared_ptr& operator=(const unique_ptr<Y,D>& r) = delete; +template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre> +</blockquote> + +<p> +Change 20.7.12.2.1 [util.smartptr.shared.const] as follows: +</p> + +<blockquote> +<pre><ins>template<class Y> shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r);</ins></pre> +</blockquote> + +<p> +Add to 20.7.12.2.1 [util.smartptr.shared.const]: +</p> + +<blockquote> +<pre><ins>template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);</ins></pre> +<blockquote> + +<p><ins> +<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is + not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt> + otherwise. +</ins></p> + +<p><ins> +<i>Exception safety:</i> If an exception is thrown, the constructor has no effect. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows: +</p> + +<blockquote> +<pre>template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r);</pre> +</blockquote> + +<p> +Add to 20.7.12.2.3 [util.smartptr.shared.assign]: +</p> + +<blockquote> +<pre><ins>template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre> + +<blockquote> +<p><ins> +-4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>. +</ins></p> +<p><ins> +-5- <i>Returns:</i> <tt>*this</tt>. +</ins></p> +</blockquote> + +</blockquote> + + + +<p><i>[ +Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>) to deal with the question of +whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>. +]</i></p> + + + + + +<hr> +<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</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#WP">WP</a> + <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>seed_seq::randomize</tt> provides a mechanism for initializing random number +engines which ideally would yield "distant" states when given "close" +seeds. The algorithm for <tt>seed_seq::randomize</tt> given in the current +Working Draft for C++, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a> +(2007-05-08), has 3 weaknesses +</p> + +<ol> +<li> +<p> Collisions in state. Because of the way the state is initialized, + seeds of different lengths may result in the same state. The + current version of seed_seq has the following properties:</p> +<ul> +<li> For a given <tt>s <= n</tt>, each of the 2^(32s) seed vectors results in a + distinct state.</li> +</ul> +<p> + The proposed algorithm (below) has the considerably stronger + properties:</p> +<ul> +<li> All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s < n</tt> + result in distinct states. +</li> +<li> All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in + distinct states. +</li> +</ul> +</li> +<li> +<p> Poor mixing of <tt>v'</tt>s entropy into the state. Consider <tt>v.size() == n</tt> + and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>, + a total of <tt>2^(16n)</tt> possibilities. Because of the simple recursion + used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64 + possible states.</p> + +<p> The proposed algorithm uses a more complex recursion which results + in much better mixing.</p> +</li> +<li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>. The proposed + algorithm remedies this. +</li> +</ol> +<p> +The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the +initialization procedure for the Mersenne Twister by Makoto Matsumoto +and Takuji Nishimura. The weakness (2) given above was communicated to +me by Matsumoto last year. +</p> +<p> +The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito, +a student of Matsumoto, and is given in the implementation of the +SIMD-oriented Fast Mersenne Twister random number generator SFMT. +<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a> +<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a> +</p> +<p> +See +Mutsuo Saito, +An Application of Finite Field: Design and Implementation of 128-bit +Instruction-Based Fast Pseudorandom Number Generator, +Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007) +<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a> +</p> +<p> +One change has been made here, namely to treat the case of small <tt>n</tt> +(setting <tt>t = (n-1)/2</tt> for <tt>n < 7</tt>). +</p> +<p> +Since <tt>seed_seq</tt> was introduced relatively recently there is little cost +in making this incompatible improvement to it. +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +for some further discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="678"></a>678. Changes for [rand.req.eng]</h3> +<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Section 26.4.1.3 [rand.req.eng] Random number engine requirements: +</p> + +<p> +This change follows naturally from the proposed change to +<tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>. +</p> + +<p> +In table 104 the description of <tt>X(q)</tt> contains a special treatment of +the case <tt>q.size() == 0</tt>. This is undesirable for 4 reasons: +</p> + +<ol> +<li>It replicates the functionality provided by <tt>X()</tt>.</li> +<li>It leads to the possibility of a collision in the state provided + by some other <tt>X(q)</tt> with <tt>q.size() > 0</tt>.</li> +<li>It is inconsistent with the description of the <tt>X(q)</tt> in +paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where +there is no special treatment of <tt>q.size() == 0</tt>.</li> +<li>The proposed replacement for <tt>seed_seq::randomize</tt> given above + allows for the case <tt>q.size() == 0</tt>.</li> +</ol> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +for some further discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="679"></a>679. resize parameter by value</h3> +<p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The C++98 standard specifies that one member function alone of the containers +passes its parameter (<tt>T</tt>) by value instead of by const reference: +</p> + +<blockquote><pre>void resize(size_type sz, T c = T()); +</pre></blockquote> + +<p> +This fact has been discussed / debated repeatedly over the years, the first time +being even before C++98 was ratified. The rationale for passing this parameter by +value has been: +</p> + +<blockquote> +<p> +So that self referencing statements are guaranteed to work, for example: +</p> +<blockquote><pre>v.resize(v.size() + 1, v[0]); +</pre></blockquote> +</blockquote> + +<p> +However this rationale is not convincing as the signature for <tt>push_back</tt> is: +</p> + +<blockquote><pre>void push_back(const T& x); +</pre></blockquote> + +<p> +And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append). +And <tt>push_back</tt> must also work in the self referencing case: +</p> + +<blockquote><pre>v.push_back(v[0]); // must work +</pre></blockquote> + +<p> +The problem with passing <tt>T</tt> by value is that it can be significantly more +expensive than passing by reference. The converse is also true, however when it is +true it is usually far less dramatic (e.g. for scalar types). +</p> + +<p> +Even with move semantics available, passing this parameter by value can be expensive. +Consider for example <tt>vector<vector<int>></tt>: +</p> + +<blockquote><pre>std::vector<int> x(1000); +std::vector<std::vector<int>> v; +... +v.resize(v.size()+1, x); +</pre></blockquote> + +<p> +In the pass-by-value case, <tt>x</tt> is copied once to the parameter of +<tt>resize</tt>. And then internally, since the code can not know at compile +time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is +usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place +within the <tt>vector</tt>. +</p> + +<p> +With pass-by-const-reference, the <tt>x</tt> in the above example need be copied +only once. In this case, <tt>x</tt> has an expensive copy constructor and so any +copies that can be saved represents a significant savings. +</p> + +<p> +If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt> +as well. The resize taking a reference parameter has been coded and shipped in the +CodeWarrior library with no reports of problems which I am aware of. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 23.2.2 [deque], p2: +</p> + +<blockquote><pre>class deque { + ... + void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + +<p> +Change 23.2.2.2 [deque.capacity], p3: +</p> + +<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + +<p> +Change 23.2.4 [list], p2: +</p> + +<blockquote><pre>class list { + ... + void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + +<p> +Change 23.2.4.2 [list.capacity], p3: +</p> + +<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + +<p> +Change 23.2.6 [vector], p2: +</p> + +<blockquote><pre>class vector { + ... + void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + +<p> +Change 23.2.6.2 [vector.capacity], p11: +</p> + +<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="680"></a>680. move_iterator operator-> return</h3> +<p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>move_iterator</tt>'s <tt>operator-></tt> return type <tt>pointer</tt> +does not consistently match the type which is returned in the description +in 24.4.3.3.5 [move.iter.op.ref]. +</p> + +<blockquote><pre>template <class Iterator> +class move_iterator { +public: + ... + typedef typename iterator_traits<Iterator>::pointer pointer; + ... + pointer operator->() const {return current;} + ... +private: + Iterator current; // exposition only +}; +</pre></blockquote> + + +<p> +There are two possible fixes. +</p> + +<ol> +<li><tt>pointer operator->() const {return &*current;}</tt></li> +<li><tt>typedef Iterator pointer;</tt></li> +</ol> + +<p> +The first solution is the one chosen by <tt>reverse_iterator</tt>. A potential +disadvantage of this is it may not work well with iterators which return a +proxy on dereference and that proxy has overloaded <tt>operator&()</tt>. Proxy +references often need to overloaad <tt>operator&()</tt> to return a proxy +pointer. That proxy pointer may or may not be the same type as the iterator's +<tt>pointer</tt> type. +</p> + +<p> +By simply returning the <tt>Iterator</tt> and taking advantage of the fact that +the language forwards calls to <tt>operator-></tt> automatically until it +finds a non-class type, the second solution avoids the issue of an overloaded +<tt>operator&()</tt> entirely. +</p> + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 24.4.3.1 [move.iterator]: +</p> + +<blockquote><pre>typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3> +<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 28.9.2 [re.submatch.op] of N2284, +operator functions numbered 31-42 seem impossible to compare. E.g.: +</p> + +<blockquote> +<pre>template <class BiIter> + bool operator==(typename iterator_traits<BiIter>::value_type const& lhs, + const sub_match<BiIter>& rhs); +</pre> +<blockquote> +<p> +-31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>. +</p> +</blockquote> +</blockquote> + +<p> +When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits<BiIter>::value_type</tt> would be +<tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object +of <tt>std::basic_string<char></tt>. However, the behaviour of comparison between +these two types is not defined in 21.3.8 [string.nonmembers] of N2284. + This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3> +<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this +constructor: +</p> +<blockquote><pre>template <class InputIterator> + basic_regex(InputIterator first, InputIterator last, + flag_type f = regex_constants::ECMAScript); +</pre></blockquote> + +<p> +In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature: +</p> + +<blockquote><pre>template <class ForwardIterator> + basic_regex(ForwardIterator first, ForwardIterator last, + flag_type f = regex_constants::ECMAScript); +</pre></blockquote> + +<p> +<tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong. +</p> + +<p><i>[ +John adds: +]</i></p> + + +<blockquote> +<p> +I think either could be implemented? Although an input iterator would +probably require an internal copy of the string being made. +</p> +<p> +I have no strong feelings either way, although I think my original intent +was <tt>InputIterator</tt>. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3> +<p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-06-10</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In C++03 the difference between two <tt>reverse_iterators</tt> +</p> +<blockquote><pre>ri1 - ri2 +</pre></blockquote> +<p> +is possible to compute only if both iterators have the same base +iterator. The result type is the <tt>difference_type</tt> of the base iterator. +</p> +<p> +In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff] +</p> +<blockquote><pre>template<class Iterator1, class Iterator2> +typename reverse_iterator<Iterator>::difference_type + operator-(const reverse_iterator<Iterator1>& x, + const reverse_iterator<Iterator2>& y); +</pre></blockquote> +<p> +The return type is the same as the C++03 one, based on the no longer +present <tt>Iterator</tt> template parameter. +</p> +<p> +Besides being slightly invalid, should this operator work only when +<tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the +implementation choose one of them? Which one? +</p> +<p> +The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt> +24.4.3.3.14 [move.iter.nonmember]. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 24.4.1.1 [reverse.iterator]: +</p> + +<blockquote> +<pre>template <class Iterator1, class Iterator2> + <del>typename reverse_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-( + const reverse_iterator<Iterator1>& x, + const reverse_iterator<Iterator2>& y)<ins> -> decltype(y.current - x.current)</ins>; +</pre> +</blockquote> + +<p> +Change 24.4.1.3.19 [reverse.iter.opdiff]: +</p> + +<blockquote> +<pre>template <class Iterator1, class Iterator2> + <del>typename reverse_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-( + const reverse_iterator<Iterator1>& x, + const reverse_iterator<Iterator2>& y)<ins> -> decltype(y.current - x.current)</ins>; +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>y.current - x.current</tt>. +</p> +</blockquote> +</blockquote> + + +<p> +Change the synopsis in 24.4.3.1 [move.iterator]: +</p> + +<blockquote> +<pre>template <class Iterator1, class Iterator2> + <del>typename move_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-( + const move_iterator<Iterator1>& x, + const move_iterator<Iterator2>& y)<ins> -> decltype(x.base() - y.base())</ins>; +</pre> +</blockquote> + +<p> +Change 24.4.3.3.14 [move.iter.nonmember]: +</p> + +<blockquote> +<pre>template <class Iterator1, class Iterator2> + <del>typename move_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-( + const move_iterator<Iterator1>& x, + const move_iterator<Iterator2>& y)<ins> -> decltype(x.base() - y.base())</ins>; +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>x.base() - y.base()</tt>. +</p> +</blockquote> +</blockquote> + +<p><i>[ +Pre Bellevue: This issue needs to wait until the <tt>auto -> return</tt> language feature +goes in. +]</i></p> + + + + + + + +<hr> +<h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3> +<p><b>Section:</b> 20.7.12.2.1 [util.smartptr.shared.const], 20.7.12.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Since all conversions from <tt>shared_ptr<T></tt> to <tt>shared_ptr<U></tt> have the same +rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user +code that works with raw pointers fails with <tt>shared_ptr</tt>: +</p> + +<blockquote><pre>void f( shared_ptr<void> ); +void f( shared_ptr<int> ); + +int main() +{ + f( shared_ptr<double>() ); // ambiguous +} +</pre></blockquote> + +<p> +Now that we officially have <tt>enable_if</tt>, we can constrain the constructor +and the corresponding assignment operator to only participate in the +overload resolution when the pointer types are compatible. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.7.12.2.1 [util.smartptr.shared.const], change: +</p> + +<blockquote><p> +-14- <i>Requires:</i> <del>For the second constructor</del> <ins>The +second constructor shall not participate in the overload resolution +unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible +to <tt>T*</tt>. +</p></blockquote> + +<p> +In 20.7.12.3.1 [util.smartptr.weak.const], change: +</p> + +<blockquote> +<pre><del>template<class Y> weak_ptr(shared_ptr<Y> const& r);</del> +<del>weak_ptr(weak_ptr const& r);</del> +<del>template<class Y> weak_ptr(weak_ptr<Y> const& r);</del> +<ins>weak_ptr(weak_ptr const& r);</ins> +<ins>template<class Y> weak_ptr(weak_ptr<Y> const& r);</ins> +<ins>template<class Y> weak_ptr(shared_ptr<Y> const& r);</ins> +</pre> +<blockquote><p> +-4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and +third constructors<del>,</del> <ins>shall not participate in the +overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del> +<ins>is implicitly</ins> convertible to <tt>T*</tt>. +</p></blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary +motivation behind this is the safety problem with respect to rvalues, +which is addressed by the proposed resolution of the previous issue. +Therefore we should consider relaxing the requirements on the +constructor since requests for the implicit conversion keep resurfacing. +</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> +Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the +proposed resolution of the previous issue is accepted, remove the +<tt>explicit</tt> from the <tt>T&&</tt> constructor as well to keep them in sync. +</p> + + + + + +<hr> +<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The <code>bitset</code> class template provides the member function +<code>any()</code> to determine whether an object of the type has any +bits set, and the member function <code>none()</code> to determine +whether all of an object's bits are clear. However, the template does +not provide a corresponding function to discover whether a +<code>bitset</code> object has all its bits set. While it is +possible, even easy, to obtain this information by comparing the +result of <code>count()</code> with the result of <code>size()</code> +for equality (i.e., via <code>b.count() == b.size()</code>) the +operation is less efficient than a member function designed +specifically for that purpose could be. (<code>count()</code> must +count all non-zero bits in a <code>bitset</code> a word at a time +while <code>all()</code> could stop counting as soon as it encountered +the first word with a zero bit). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add a declaration of the new member function <code>all()</code> to the +defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1, +right above the declaration of <code>any()</code> as shown below: +</p> + +<blockquote><pre>bool operator!=(const bitset<N>& rhs) const; +bool test(size_t pos) const; +<ins>bool all() const;</ins> +bool any() const; +bool none() const; +</pre></blockquote> + +<p> +Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text: +</p> +<blockquote><p> +<code>bool all() const;</code> +</p> +<blockquote> +<i>Returns</i>: <code>count() == size()</code>. +</blockquote> +</blockquote> + +<p> +In addition, change the description of <code>any()</code> and +<code>none()</code> for consistency with <code>all()</code> as +follows: +</p> +<blockquote><p> +<code>bool any() const;</code> +</p> +<blockquote> +<p> +<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code> +is one</del><ins><code>count() != 0</code></ins>. +</p> +</blockquote> +<p> +<code>bool none() const;</code> +</p> +<blockquote> +<p> +<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code> +is one</del><ins><code>count() == 0</code></ins>. +</p> +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></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#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Objects of the <code>bitset</code> class template specializations can +be constructed from and explicitly converted to values of the widest +C++ integer type, <code>unsigned long</code>. With the introduction +of <code>long long</code> into the language the template should be +enhanced to make it possible to interoperate with values of this type +as well, or perhaps <code>uintmax_t</code>. See c++std-lib-18274 for +a brief discussion in support of this change. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +For simplicity, instead of adding overloads for <code>unsigned long +long</code> and dealing with possible ambiguities in the spec, replace +the <code>bitset</code> ctor that takes an <code>unsigned long</code> +argument with one taking <code>unsigned long long</code> in the +definition of the template as shown below. (The standard permits +implementations to add overloads on other integer types or employ +template tricks to achieve the same effect provided they don't cause +ambiguities or changes in behavior.) +</p> +<blockquote> +<pre>// [bitset.cons] constructors: +bitset(); +bitset(unsigned <ins>long</ins> long val); +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); +</pre> +</blockquote> +<p> +Make a corresponding change in 23.3.5.1 [bitset.cons], p2: +</p> +<blockquote> +<p> +<code>bitset(unsigned <ins>long</ins> long val);</code> +</p> +<blockquote> +<i>Effects</i>: Constructs an object of class bitset<N>, +initializing the first <code><i>M</i></code> bit positions to the +corresponding bit values in <code><i>val</i></code>. +<code><i>M</i></code> is the smaller of <code><i>N</i></code> and the +number of bits in the value representation (section [basic.types]) of +<code>unsigned <ins> long</ins> long</code>. If <code><i>M</i> < +<i>N</i></code> <ins>is <code>true</code></ins>, the remaining bit +positions are initialized to zero. +</blockquote> +</blockquote> + +<p> +Additionally, introduce a new member function <code>to_ullong()</code> +to make it possible to convert <code>bitset</code> to values of the +new type. Add the following declaration to the definition of the +template, immediate after the declaration of <code>to_ulong()</code> +in 23.3.5 [template.bitset], p1, as shown below: +</p> +<blockquote> +<pre>// element access: +bool operator[](size_t pos) const; // for b[i]; +reference operator[](size_t pos); // for b[i]; +unsigned long to_ulong() const; +<ins>unsigned long long to_ullong() const;</ins> +template <class charT, class traits, class Allocator> +basic_string<charT, traits, Allocator> to_string() const; +</pre> +</blockquote> +<p> +And add a description of the new member function to 23.3.5.2 [bitset.members], +below the description of the existing <code>to_ulong()</code> (if +possible), with the following text: +</p> +<blockquote> +<p> +<code>unsigned long long to_ullong() const;</code> +</p> +<blockquote> +<i>Throws</i>: <code>overflow_error</code> if the integral value +<code><i>x</i></code> corresponding to the bits in <code>*this</code> +cannot be represented as type <code>unsigned long long</code>. +</blockquote> +<blockquote> +<i>Returns:</i> <code><i>x</i></code>. +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="695"></a>695. ctype<char>::classic_table() not accessible</h3> +<p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The <code>ctype<char>::classic_table()</code> static member +function returns a pointer to an array of const +<code>ctype_base::mask</code> objects (enums) that contains +<code>ctype<char>::table_size</code> elements. The table +describes the properties of the character set in the "C" locale (i.e., +whether a character at an index given by its value is alpha, digit, +punct, etc.), and is typically used to initialize the +<code>ctype<char></code> facet in the classic "C" locale (the +protected <code>ctype<char></code> member function +<code>table()</code> then returns the same value as +<code>classic_table()</code>). +</p> +<p> +However, while <code>ctype<char>::table_size</code> (the size of +the table) is a public static const member of the +<code>ctype<char></code> specialization, the +<code>classic_table()</code> static member function is protected. That +makes getting at the classic data less than convenient (i.e., one has +to create a whole derived class just to get at the masks array). It +makes little sense to expose the size of the table in the public +interface while making the table itself protected, especially when the +table is a constant object. +</p> +<p> +The same argument can be made for the non-static protected member +function <code>table()</code>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Make the <code>ctype<char>::classic_table()</code> and +<code>ctype<char>::table()</code> member functions public by +moving their declarations into the public section of the definition of +specialization in 22.2.1.3 [facet.ctype.special] as shown below: +</p> +<blockquote> +<pre> static locale::id id; + static const size_t table_size = IMPLEMENTATION_DEFINED; +<del>protected:</del> + const mask* table() const throw(); + static const mask* classic_table() throw(); +<ins>protected:</ins> + +~ctype(); // virtual +virtual char do_toupper(char c) const; +</pre> +</blockquote> + + + + + +<hr> +<h3><a name="699"></a>699. N2111 changes min/max</h3> +<p><b>Section:</b> 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a> +changes <tt>min/max</tt> in several places in random from member +functions to static data members. I believe this introduces +a needless backward compatibility problem between C++0X and +TR1. I'd like us to find new names for the static data members, +or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X. +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +for some further discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></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#WP">WP</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> +defines struct <tt>identity</tt> in <tt><utility></tt> which clashes with +the traditional definition of struct <tt>identity</tt> in <tt><functional></tt> +(not standard, but a common extension from old STL). Be nice +if we could avoid this name clash for backward compatibility. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.2.2 [forward]: +</p> + +<blockquote> +<pre>template <class T> struct identity +{ + typedef T type; + <ins>const T& operator()(const T& x) const;</ins> +}; +</pre> +<blockquote> +<pre><ins>const T& operator()(const T& x) const;</ins> +</pre> +<blockquote> +<p> +<ins><i>Returns:</i> <tt>x</tt>.</ins> +</p> +</blockquote> +</blockquote> + +</blockquote> + + + + + + +<hr> +<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3> +<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>map::at()</tt> need a complexity specification. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]: +</p> +<blockquote> +<p> +<i>Complexity:</i> logarithmic. +</p> +</blockquote> + + + + + +<hr> +<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</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#WP">WP</a> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current working draft has a type-trait <tt>decay</tt> in 20.5.7 [meta.trans.other]. +</p> + +<p> +Its use is to turn C++03 pass-by-value parameters into efficient C++0x +pass-by-rvalue-reference parameters. However, the current definition +introduces an incompatible change where the cv-qualification of the +parameter type is retained. The deduced type should loose such +cv-qualification, as pass-by-value does. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.5.7 [meta.trans.other] change the last sentence: +</p> + +<blockquote><p> +Otherwise the member typedef <tt>type</tt> equals <tt><ins>remove_cv<</ins>U<ins>>::type</ins></tt>. +</p></blockquote> + +<p> +In 20.4.1.3 [tuple.creation]/1 change: +</p> + +<blockquote><p> +<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&</tt> if, for the +corresponding type <tt>Ti</tt> in <tt>Types</tt>, +<tt>remove_cv<remove_reference<Ti>::type>::type</tt> equals +<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is +<tt>decay<Ti>::type</tt>.</del> +<ins>Let <tt>Ui</tt> be <tt>decay<Ti>::type</tt> for each +<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt> +is <tt>X&</tt> if <tt>Ui</tt> equals +<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is +<tt>Ui</tt>.</ins> +</p></blockquote> + + + + + + +<hr> +<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></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#WP">WP</a> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16 +and <tt>make_tuple()</tt> in 20.4.1.3 [tuple.creation]. +<tt>make_tuple()</tt> detects the presence of +<tt>reference_wrapper<X></tt> arguments and "unwraps" the reference in +such cases. <tt>make_pair()</tt> would OTOH create a +<tt>reference_wrapper<X></tt> member. I suggest that the two +functions are made to behave similar in this respect to minimize +confusion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.2 [utility] change the synopsis for make_pair() to read +</p> + +<blockquote><pre>template <class T1, class T2> + pair<<del>typename decay<T1>::type</del> <ins>V1</ins>, <del>typename decay<T2>::type</del> <ins>V2</ins>> make_pair(T1&&, T2&&); +</pre></blockquote> + +<p> +In 20.2.3 [pairs]/16 change the declaration to match the above synopsis. +Then change the 20.2.3 [pairs]/17 to: +</p> + +<blockquote> +<p> +<i>Returns:</i> <tt>pair<<del>typename decay<T1>::type</del> <ins>V1</ins>,<del>typename decay<T2>::type</del> <ins>V2</ins>>(forward<T1>(x),forward<T2>(y))</tt> <ins>where <tt>V1</tt> and +<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be +<tt>decay<Ti>::type</tt> for each <tt>Ti</tt>. Then each +<tt>Vi</tt> is <tt>X&</tt> if <tt>Ui</tt> equals +<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is +<tt>Ui</tt>.</ins> +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="710"></a>710. Missing postconditions</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#WP">WP</a> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</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#WP">WP</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 <tt>shared_ptr</tt> move constructor and the cast functions are +missing postconditions for the <tt>get()</tt> accessor. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Move to "ready", adopting the first (Peter's) proposed resolution. +</p> +<p> +Note to the project editor: there is an editorial issue here. The +wording for the postconditions of the casts is slightly awkward, and the +editor should consider rewording "If w is the return value...", e. g. as +"For a return value w...". +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to 20.7.12.2.1 [util.smartptr.shared.const]: +</p> + +<blockquote> +<pre>shared_ptr(shared_ptr&& r); +template<class Y> shared_ptr(shared_ptr<Y>&& r); +</pre> +<blockquote> +<p> +<i>Postconditions:</i> <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt> +shall be empty. <ins><tt>r.get() == 0</tt>.</ins> +</p> +</blockquote> +</blockquote> + +<p> +Add to 20.7.12.2.10 [util.smartptr.shared.cast]: +</p> + +<blockquote> +<pre>template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const& r); +</pre> +<blockquote> +<p> +<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, +<tt>w.get() == static_cast<T*>(r.get()) && w.use_count() == r.use_count()</tt>.</ins> +</p> +</blockquote> +</blockquote> + +<blockquote> +<pre>template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r); +</pre> +<blockquote> +<p> +<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast<T*>(r.get())</tt>.</ins> +</p> +</blockquote> +</blockquote> + +<blockquote> +<pre>template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r); +</pre> +<blockquote> +<p> +<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, +<tt>w.get() == const_cast<T*>(r.get()) && w.use_count() == r.use_count()</tt>.</ins> +</p> +</blockquote> +</blockquote> + +<p> +Alberto Ganesh Barbati has written an +<a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a> +where he suggests (among other things) that the casts be respecified in terms of +the aliasing constructor as follows: +</p> + +<p> +Change 20.7.12.2.10 [util.smartptr.shared.cast]: +</p> + +<blockquote> +<p> +-2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty +shared_ptr<T>;</tt> otherwise, a <tt>shared_ptr<T></tt> +object that stores <tt>static_cast<T*>(r.get())</tt> and shares ownership with +<tt>r</tt>.</del> <ins><tt>shared_ptr<T>(r, static_cast<T*>(r.get())</tt>.</ins> +</p> +</blockquote> + +<blockquote> +<p> +-6- <i>Returns:</i> +</p> +<ul> +<li><del>When <tt>dynamic_cast<T*>(r.get())</tt> returns a nonzero value, +a <tt>shared_ptr<T></tt> object that stores a copy +of it and <i>shares ownership</i> with <tt>r</tt>;</del></li> +<li><del>Otherwise, an <i>empty</i> <tt>shared_ptr<T></tt> object.</del></li> +<li><ins>If <tt>p = dynamic_cast<T*>(r.get())</tt> is a non-null pointer, <tt>shared_ptr<T>(r, p);</tt></ins></li> +<li><ins>Otherwise, <tt>shared_ptr<T>()</tt>.</ins></li> +</ul> +</blockquote> + +<blockquote> +<p> +-10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty +shared_ptr<T>;</tt> otherwise, a <tt>shared_ptr<T></tt> +object that stores <tt>const_cast<T*>(r.get())</tt> and shares ownership with +<tt>r</tt>.</del> <ins><tt>shared_ptr<T>(r, const_cast<T*>(r.get())</tt>.</ins> +</p> +</blockquote> + +<p> +This takes care of the missing postconditions for the casts by bringing +in the aliasing constructor postcondition "by reference". +</p> + + + + + + +<hr> +<h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</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#WP">WP</a> + <b>Submitter:</b> Marc Paterno <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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +One of the motivations for incorporating <tt>seed_seq::size()</tt> +was to simplify the wording +in other parts of 26.4 [rand]. +As a side effect of resolving related issues, +all such references +to <tt>seed_seq::size()</tt> will have been excised. +More importantly, +the present specification is contradictory, +as "The number of 32-bit units the object can deliver" +is not the same as "the result of <tt>v.size()</tt>." +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +for some further discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Adopt the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>. +</p> + + +<p><i>[ +Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue. +The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. +]</i></p> + + + + + +<hr> +<h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</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#WP">WP</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.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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 * +(last - first ) - 2, 0)</tt> applications of the corresponding comparisons", +i.e. the worst case complexity is no better than calling <tt>min_element</tt> and +<tt>max_element</tt> separately. This is gratuitously inefficient. There is a +well known technique that does better: see section 9.1 of CLRS +(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 25.3.7 [alg.min.max] to: +</p> + +<blockquote> +<pre>template<class ForwardIterator> + pair<ForwardIterator, ForwardIterator> + minmax_element(ForwardIterator first , ForwardIterator last); +template<class ForwardIterator, class Compare> + pair<ForwardIterator, ForwardIterator> + minmax_element(ForwardIterator first , ForwardIterator last , Compare comp); +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is +<del><tt>min_element(first, last)</tt> or <tt>min_element(first, last, +comp)</tt></del> <ins>the first iterator in <tt>[first, +last)</tt> such that no iterator in the range refers to a smaller element,</ins> and +<ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or +<tt>max_element(first, last, comp)</tt></del> <ins>the last iterator +in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</ins>. +</p> +<p> +<i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del> +<ins><tt>max(⌊(3/2) (N-1)⌋, 0)</tt></ins> applications of the +corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>. +</p> +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the listing of 26.7 [c.math], table 108: Header <tt><cmath></tt> synopsis I miss +the following C99 functions (from 7.12.11.2): +</p> + +<blockquote><pre>float nanf(const char *tagp); +long double nanl(const char *tagp); +</pre></blockquote> + +<p> +(Note: These functions cannot be overloaded and they are also not +listed anywhere else) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt> +just after the existing entry <tt>nan</tt>. +</p> + + + + + +<hr> +<h3><a name="740"></a>740. Please remove <tt>*_ptr<T[N]></tt></h3> +<p><b>Section:</b> 20.7.11.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Please don't provide <tt>*_ptr<T[N]></tt>. It doesn't enable any useful +bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a +<tt>shared_ptr<T[N]></tt> yields a <tt>shared_ptr<T[N-1]></tt>, but that promising path +immediately falters on <tt>op--</tt> which can't reliably dereference because we +don't know the lower bound). Also, most buffers you'd want to point to +don't have a compile-time known size. +</p> + +<p> +To enable any bounds-checking would require run-time information, with +the usual triplet: base (lower bound), current offset, and max offset +(upper bound). And I can sympathize with the point of view that you +wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not +follow the <tt><T[N]></tt> path, especially not with additional functions to +query the bounds etc., because this sets wrong user expectations by +embarking on a path that doesn't go all the way to bounds checking as it +seems to imply. +</p> + +<p> +If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g., +<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that +user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on +debug builds and not doing so on release builds (for example). +</p> + +<p> +Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart +pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I +don't agree, but if that were true that would be another reason to +remove <tt>*_ptr<T[N]></tt> which equally makes the smart pointer more like +<tt>std::array.</tt> :-) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p>Suggestion that fixed-size array instantiations are going to fail at +compile time anyway (if we remove specialization) due to pointer decay, +at least that appears to be result from available compilers. +</p> +<p> +So concerns about about requiring static_assert seem unfounded. +</p> +<p>After a little more experimentation with compiler, it appears that +fixed size arrays would only work at all if we supply these explicit +specialization. So removing them appears less breaking than originally +thought. +</p> +<p> +straw poll unanimous move to Ready. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis under 20.7.11 [unique.ptr] p2: +</p> + +<blockquote><pre>... +template<class T> struct default_delete; +template<class T> struct default_delete<T[]>; +<del>template<class T, size_t N> struct default_delete<T[N]>;</del> + +template<class T, class D = default_delete<T>> class unique_ptr; +template<class T, class D> class unique_ptr<T[], D>; +<del>template<class T, class D, size_t N> class unique_ptr<T[N], D>;</del> +... +</pre></blockquote> + +<p> +Remove the entire section 20.7.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>. +</p> + +<p> +Remove the entire section 20.7.11.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b> +and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [unique.ptr.compiletime.observers], +20.7.11.4.3 [unique.ptr.compiletime.modifiers]. +</p> + + + + + + +<hr> +<h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3> +<p><b>Section:</b> 20.7.12.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made: +</p> + +<blockquote><p> +We may need to open an issue to deal with the question of +whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>. +</p></blockquote> + +<p> +This issue was opened in response to that note. +</p> + +<p> +I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both +appropriate, and consistent with how other library components are currently specified. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Concern that the three signatures for swap is needlessly complicated, +but this issue merely brings shared_ptr into equal complexity with the +rest of the library. Will open a new issue for concern about triplicate +signatures. +</p> +<p> +Adopt issue as written. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 20.7.12.2 [util.smartptr.shared]: +</p> + +<blockquote><pre>void swap(shared_ptr&<ins>&</ins> r); +... +template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b); +<ins>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b); +template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</ins> +</pre></blockquote> + +<p> +Change 20.7.12.2.4 [util.smartptr.shared.mod]: +</p> + +<blockquote><pre>void swap(shared_ptr&<ins>&</ins> r); +</pre></blockquote> + +<p> +Change 20.7.12.2.9 [util.smartptr.shared.spec]: +</p> + +<blockquote><pre>template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b); +<ins>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b); +template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</ins> +</pre></blockquote> + + + + + +<hr> +<h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</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#WP">WP</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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Without some lifetime guarantee, it is hard to know how this type can be +used. Very specifically, I don't see how the current wording would +guarantee and exception_ptr caught at the end of one thread could be safely +stored and rethrown in another thread - the original motivation for this +API. +</p> +<p> +(Peter Dimov agreed it should be clearer, maybe a non-normative note to +explain?) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Agree the issue is real. +</p> +<p> +Intent is lifetime is similar to a shared_ptr (and we might even want to +consider explicitly saying that it is a shared_ptr< unspecified type >). +</p> +<p> +We expect that most implementations will use shared_ptr, and the +standard should be clear that the exception_ptr type is intended to be +something whose semantics are smart-pointer-like so that the user does +not need to worry about lifetime management. We still need someone to +draught those words - suggest emailing Peter Dimov. +</p> +<p> +Move to Open. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 18.7.5 [propagation]/7: +</p> + +<blockquote> +-7- Returns: An <tt>exception_ptr</tt> object that refers to the currently +handled exception or a copy of the currently handled exception, or a +null <tt>exception_ptr</tt> object if no exception is being handled. +<ins>The referenced object remains valid at least as long as there is an +<tt>exception_ptr</tt> that refers to it.</ins> +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>. It is unspecified whether the return values of two successive +calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i> +that is, it is unspecified whether <tt>current_exception</tt> creates a new copy +each time it is called. <i>--end note</i>] +</blockquote> + + + + + +<hr> +<h3><a name="746"></a>746. current_exception may fail with bad_alloc</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#WP">WP</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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I understand that the attempt to copy an exception may run out of memory, +but I believe this is the only part of the standard that mandates failure +with specifically <tt>bad_alloc</tt>, as opposed to allowing an +implementation-defined type derived from <tt>bad_alloc</tt>. For instance, the Core +language for a failed new expression is: +</p> +<blockquote> +<p> +Any other allocation function that fails to allocate storage shall indicate +failure only by throwing an exception of a type that would match a handler +(15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1). +</p> +</blockquote> +<p> +I think we should allow similar freedom here (or add a blanket +compatible-exception freedom paragraph in 17) +</p> +<p> +I prefer the clause 17 approach myself, and maybe clean up any outstanding +wording that could also rely on it. +</p> +<p> +Although filed against a specific case, this issue is a problem throughout +the library. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Is issue bigger than library? +</p> +<p> +No - Core are already very clear about their wording, which is inspiration for the issue. +</p> +<p> +While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue. +</p> +<p> +Accept the broad view and move to ready +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following exemption clause to 17.4.4.9 [res.on.exception.handling]: +</p> + +<blockquote> +A function may throw a type not listed in its <i>Throws</i> clause so long as it is +derived from a class named in the <i>Throws</i> clause, and would be caught by an +exception handler for the base type. +</blockquote> + + + + + +<hr> +<h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor<T>::value</tt> is true if T has 'a' nothrow copy constructor.</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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Unfortunately a class can have multiple copy constructors, and I believe to +be useful this trait should only return true is ALL copy constructors are +no-throw. +</p> +<p> +For instance: +</p> +<blockquote> +<pre>struct awkward { + awkward( const awkward & ) throw() {} + awkward( awkward & ) { throw "oops"; } }; +</pre> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.5.4.3 [meta.unary.prop]: +</p> + +<blockquote> +<pre>has_trivial_copy_constructor</pre> +<blockquote> +<tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del> +<ins>where all copy constructors are trivial</ins> (12.8). +</blockquote> +</blockquote> + +<blockquote> +<pre>has_trivial_assign</pre> +<blockquote> +<tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9) +or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8). +</blockquote> +</blockquote> + +<blockquote> +<pre>has_nothrow_copy_constructor</pre> +<blockquote> +<tt>has_trivial_copy_constructor<T>::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with +a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins> +known not to throw any exceptions or <tt>T</tt> is an +array of such a class type +</blockquote> +</blockquote> + +<blockquote> +<pre>has_nothrow_assign</pre> +<blockquote> +<tt>T</tt> is neither <tt>const</tt> nor a reference type, and +<tt>has_trivial_assign<T>::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del> +<ins>where all</ins> copy +assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to +throw any exceptions or <tt>T</tt> is an array of such a class type. +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3> +<p><b>Section:</b> 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-10-31</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom: +</p> + +<blockquote><pre>vector<int> v; +... +v.swap(vector<int>(v)); // shrink to fit +</pre> +<blockquote><p> +or: +</p></blockquote> +<pre>vector<int>(v).swap(v); // shrink to fit +</pre> +<blockquote><p> +or: +</p></blockquote> +<pre>swap(v, vector<int>(v)); // shrink to fit +</pre> +</blockquote> + +<p> +A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via: +</p> + +<blockquote><pre>string s; +... +s.reserve(0); +</pre></blockquote> + +<p> +Neither of these is at all obvious to beginners, and even some +experienced C++ programmers are not aware that shrink-to-fit is +trivially available. +</p> +<p> +Lack of explicit functions to perform these commonly requested +operations makes vector and string less usable for non-experts. Because +the idioms are somewhat obscure, code readability is impaired. It is +also unfortunate that two similar vector-like containers use different +syntax for the same operation. +</p> +<p> +The proposed resolution addresses these concerns. The proposed function +takes no arguments to keep the solution simple and focused. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +To Class template basic_string 21.3 [basic.string] synopsis, +Class template vector 23.2.6 [vector] synopsis, and Class +vector<bool> 23.2.7 [vector.bool] synopsis, add: +</p> + +<blockquote><pre> +void shrink_to_fit(); +</pre></blockquote> + +<p> +To basic_string capacity 21.3.4 [string.capacity] and vector +capacity 23.2.6.2 [vector.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 +<tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to +allow latitude for implementation-specific optimizations. +<i>-- end note</i>] +</blockquote> +</blockquote> + +<p><i>[ +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a> has been added to deal with this issue with respect to <tt>deque</tt>. +]</i></p> + + + + + + +<hr> +<h3><a name="759"></a>759. A reference is not an object</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#WP">WP</a> + <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-11-06</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +23.1 [container.requirements] says: +</p> + +<blockquote> +-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No +diagnostic required. +</blockquote> + +<p> +A reference is not an object, but this sentence appears to claim so. +</p> + +<p> +What is probably meant here: +</p> +<blockquote> +An object bound to an rvalue +reference parameter of a member function of a container shall not be +an element of that container; no diagnostic required. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 23.1 [container.requirements]: +</p> + +<blockquote> +-12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del> +<ins>An object bound to an rvalue +reference parameter of a member function of a container shall not be +an element</ins> +of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o +diagnostic required. +</blockquote> + + + + + + +<hr> +<h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3> +<p><b>Section:</b> 23.4.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-15</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>. It acts +like <tt>operator[]()</tt>, except it throws an exception when the input key is +not found. It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the +key doesn't have a default constructor, it is an error if the key is +not found, or the user wants to avoid accidentally adding an element to +the map. For exactly these same reasons, <tt>at()</tt> would be equally useful +in <tt>std::unordered_map</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.4.1 [unord.map]): +</p> + +<blockquote><pre>mapped_type& at(const key_type& k); +const mapped_type &at(const key_type &k) const; +</pre></blockquote> + +<p> +Add the following definitions to 23.4.1.2 [unord.map.elem]: +</p> + +<blockquote> +<pre>mapped_type& at(const key_type& k); +const mapped_type &at(const key_type &k) const; +</pre> +<blockquote> +<p> +<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>. +</p> +<p> +<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element +is present. +</p> +</blockquote> +</blockquote> + +<p><i>[ +Bellevue: Editorial note: the "(unique)" differs from map. +]</i></p> + + + + + + + +<hr> +<h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3> +<p><b>Section:</b> 23.1 [container.requirements], 23.1.5.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Ion Gaztañaga <b>Date:</b> 2007-12-22</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +23.1 [container.requirements]p10 states: +</p> + +<blockquote> +<p> +Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following +additional requirements: +</p> +<ul> + +<li>[...]</li> + +<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li> + +</ul> +</blockquote> + +<p> +23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer +additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and +<tt>erase()</tt> members. However, 23.1 [container.requirements]p10 +does not mention 23.1.5.1 [unord.req.except] that specifies exception +safety guarantees +for unordered containers. In addition, 23.1.5.1 [unord.req.except]p1 +offers the following guaratee for +<tt>erase()</tt>: +</p> + +<blockquote> +No <tt>erase()</tt> function throws an exception unless that exception +is thrown by the container's Hash or Pred object (if any). +</blockquote> + +<p> +Summary: +</p> + +<p> +According to 23.1 [container.requirements]p10 no +<tt>erase()</tt> function should throw an exception unless otherwise +specified. Although does not explicitly mention 23.1.5.1 [unord.req.except], this section offers additional guarantees +for unordered containers, allowing <tt>erase()</tt> to throw if +predicate or hash function throws. +</p> + +<p> +In contrast, associative containers have no exception safety guarantees +section so no <tt>erase()</tt> function should throw, <em>including +<tt>erase(k)</tt></em> that needs to use the predicate function to +perform its work. This means that the predicate of an associative +container is not allowed to throw. +</p> + +<p> +So: +</p> + +<ol> +<li> +<tt>erase(k)</tt> for associative containers is not allowed to throw. On +the other hand, <tt>erase(k)</tt> for unordered associative containers +is allowed to throw. +</li> +<li> +<tt>erase(q)</tt> for associative containers is not allowed to throw. On +the other hand, <tt>erase(q)</tt> for unordered associative containers +is allowed to throw if it uses the hash or predicate. +</li> +<li> +To fulfill 1), predicates of associative containers are not allowed to throw. +Predicates of unordered associative containers are allowed to throw. +</li> +<li> +2) breaks a widely used programming pattern (flyweight pattern) for +unordered containers, where objects are registered in a global map in +their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is +allowed to throw, the destructor of the object would need to rethrow the +exception or swallow it, leaving the object registered. +</li> +</ol> + + +<p><b>Proposed resolution:</b></p> +<p> +Create a new sub-section of 23.1.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception +safety guarantees". +</p> + +<blockquote> +<p> +1 For associative containers, no <tt>clear()</tt> function throws an exception. +<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by +the container's Pred object (if any). +</p> + +<p> +2 For associative containers, if an exception is thrown by any operation +from within an <tt>insert()</tt> function inserting a single element, the +<tt>insert()</tt> function has no effect. +</p> + +<p> +3 For associative containers, no <tt>swap</tt> function throws an exception +unless that exception is thrown by the copy constructor or copy +assignment operator of the container's Pred object (if any). +</p> +</blockquote> + +<p> +Change 23.1.5.1 [unord.req.except]p1: +</p> + +<blockquote> +For unordered associative containers, no <tt>clear()</tt> function +throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt> +<del>function</del> <ins>does not</ins> throw<del>s</del> an exception +unless that exception is thrown by the container's Hash or Pred object +(if any). +</blockquote> + +<p> +Change 23.1 [container.requirements]p10 to add references to new sections: +</p> + +<blockquote> +Unless otherwise specified (see [deque.modifiers]<ins>,</ins> +<del>and</del> [vector.modifiers]<ins>, [associative.req.except], +[unord.req.except]</ins>) all container types defined in this clause meet +the following additional requirements: +</blockquote> + +<p> +Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>: +</p> + +<blockquote> +<ul> +<li> +no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown +by the copy constructor or assignment operator of the container's +Compare object (if any; see [associative.reqmts])</del>. +</li> +</ul> +</blockquote> + + + + + + +<hr> +<h3><a name="768"></a>768. Typos in [atomics]?</h3> +<p><b>Section:</b> 29.3.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2007-12-28</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +in the latest publicly available draft, paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>, +in section 29.3.3 [atomics.types.generic], the following specialization of the template +<tt>atomic<></tt> is provided for pointers: +</p> + +<blockquote><pre>template <class T> struct atomic<T*> : atomic_address { + T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + + atomic() = default; + constexpr explicit atomic(T); + atomic(const atomic&) = delete; + atomic& operator=(const atomic&) = delete; + + T* operator=(T*) volatile; + T* operator++(int) volatile; + T* operator--(int) volatile; + T* operator++() volatile; + T* operator--() volatile; + T* operator+=(ptrdiff_t) volatile; + T* operator-=(ptrdiff_t) volatile; +}; +</pre></blockquote> + +<p> +First of all, there is a typo in the non-default constructor which +should take a <tt>T*</tt> rather than a <tt>T</tt>. +</p> + +<p> +As you can see, the specialization redefine and therefore hide a few +methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>, +<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened +to the other methods, in particular these ones: +</p> + +<blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile; +T* load( memory_order = memory_order_seq_cst ) volatile; +T* swap( T*, memory_order = memory_order_seq_cst ) volatile; +bool compare_swap( T*&, T*, memory_order, memory_order ) volatile; +bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile; +</pre></blockquote> + +<p> +By reading paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>, +I see that the +definition of the specialization <tt>atomic<T*></tt> matches the one in the +draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt> +and <tt>compare_swap()</tt> are indeed present. +</p> + +<p> +Strangely, the example implementation does not redefine the method +<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not +hiding the <tt>void*</tt> signature from the base class makes the class +error-prone to say the least: it lets you assign pointers of any type to +a <tt>T*</tt>, without any hint from the compiler. +</p> + +<p> +Is there a true intent to remove them from the specialization or are +they just missing from the definition because of a mistake? +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +The proposed revisions are accepted. +</p> +<p> +Further discussion: why is the ctor labeled "constexpr"? Lawrence said +this permits the object to be statically initialized, and that's +important because otherwise there would be a race condition on +initialization. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 29.3.3 [atomics.types.generic]: +</p> + +<blockquote><pre>template <class T> struct atomic<T*> : atomic_address { + <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins> + <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins> + <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins> + <ins>bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;</ins> + <ins>bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;</ins> + + T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + + atomic() = default; + constexpr explicit atomic(T<ins>*</ins>); + atomic(const atomic&) = delete; + atomic& operator=(const atomic&) = delete; + + T* operator=(T*) volatile; + T* operator++(int) volatile; + T* operator--(int) volatile; + T* operator++() volatile; + T* operator--() volatile; + T* operator+=(ptrdiff_t) volatile; + T* operator-=(ptrdiff_t) volatile; +}; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="770"></a>770. std::function should use rvalue swap</h3> +<p><b>Section:</b> 20.6.15 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It is expected that typical implementations of <tt>std::function</tt> will +use dynamic memory allocations at least under given conditions, +so it seems appropriate to change the current lvalue swappabilty of +this class to rvalue swappability. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.6 [function.objects], header <tt><functional></tt> synopsis, just below of +</p> + +<blockquote><pre>template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&); +<ins>template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&); +template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins> +</pre></blockquote> + +<p> +In 20.6.15.2 [func.wrap.func] class <tt>function</tt> definition, change +</p> + +<blockquote><pre>void swap(function&<ins>&</ins>); +</pre></blockquote> + +<p> +In 20.6.15.2 [func.wrap.func], just below of +</p> + +<blockquote><pre>template <class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&); +<ins>template <class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&); +template <class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins> +</pre></blockquote> + +<p> +In 20.6.15.2.2 [func.wrap.func.mod] change +</p> + +<blockquote><pre>void swap(function&<ins>&</ins> other); +</pre></blockquote> + +<p> +In 20.6.15.2.7 [func.wrap.func.alg] add the two overloads +</p> + +<blockquote><pre><ins>template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2); +template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);</ins> +</pre></blockquote> + + + + + + +<hr> +<h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3> +<p><b>Section:</b> 20.4.1.4 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-16</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The tuple element access API identifies the element in the sequence +using signed integers, and then goes on to enforce the requirement that +I be >= 0. There is a much easier way to do this - declare I as +<tt>unsigned</tt>. +</p> +<p> +In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API. +</p> +<p> +A second suggestion is that it is hard to imagine an API that deduces +and index at compile time and returns a reference throwing an exception. +Add a specific <em>Throws:</em> Nothing paragraph to each element +access API. +</p> +<p> +In addition to <code>tuple</code>, update the API applies to +<code>pair</code> and <code>array</code>, and should be updated +accordingly. +</p> + +<p> +A third observation is that the return type of the <code>get</code> +functions for <code>std::pair</code> is pseudo-code, but it is not +clearly marked as such. There is actually no need for pseudo-code as +the return type can be specified precisely with a call to +<code>tuple_element</code>. This is already done for +<code>std::tuple</code>, and <code>std::array</code> does not have a +problem as all elements are of type <code>T</code>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Update header <utility> synopsis in 20.2 [utility] +</p> +<pre><em>// 20.2.3, tuple-like access to pair:</em> +template <class T> class tuple_size; +template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; + +template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >; +template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >; +template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >; + +template<<del>int</del><ins>size_t</ins> I, class T1, class T2> + <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(std::pair<T1, T2>&); +template<<del>int</del><ins>size_t</ins> I, class T1, class T2> + const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const std::pair<T1, T2>&); +</pre> +<p> +Update <strong>20.2.3 [pairs] Pairs</strong> +</p> +<pre>template<<del>int</del><ins>size_t</ins> I, class T1, class T2> + <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(pair<T1, T2>&); +template<<del>int</del><ins>size_t</ins> I, class T1, class T2> + const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const pair<T1, T2>&); +</pre> +<p> +<del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del> +</p> +<p> +25 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>. +</p> +<p> +<ins><em>Throws:</em> Nothing.</ins> +</p> + + +<p> +Update header <tuple> synopsis in 20.4 [tuple] with a APIs as below: +</p> +<pre>template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// undefined</em> +template <<del>int</del><ins>size_t</ins> I, class... Types> class tuple_element<I, tuple<Types...> >; + +<em>// 20.3.1.4, element access:</em> +template <<del>int</del><ins>size_t</ins> I, class... Types> + typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&); +template <<del>int</del><ins>size_t</ins> I, class ... types> + typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&); +</pre> + +<p> +Update <strong>20.4.1.4 [tuple.helper] Tuple helper classes</strong> +</p> +<pre>template <<del>int</del><ins>size_t</ins> I, class... Types> +class tuple_element<I, tuple<Types...> > { +public: + typedef TI type; +};</pre> +<p> +1 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds. +</p> +<p> +2 <em>Type:</em> <code>TI</code> is the type of the <code>I</code>th element of <code>Types</code>, where indexing is zero-based. +</p> +<p> +Update <strong>20.4.1.5 [tuple.elem] Element access</strong> +</p> +<pre>template <<del>int</del><ins>size_t</ins> I, class... types > +typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t); +</pre> +1 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds. +<p> +2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based. +</p> +<ins><em>Throws:</em> Nothing.</ins> +<pre>template <<del>int</del><ins>size_t</ins> I, class... types> +typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t); +</pre> +<p> +3 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds. +</p> +<p> +4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based. +</p> +<p> +<ins><em>Throws:</em> Nothing.</ins> +</p> + + +<p> +Update header <array> synopsis in 20.2 [utility] +</p> +<pre>template <class T> class tuple_size; <em>// forward declaration</em> +template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// forward declaration</em> +template <class T, size_t N> + struct tuple_size<array<T, N> >; +template <<del>int</del><ins>size_t</ins> I, class T, size_t N> + struct tuple_element<I, array<T, N> >; +template <<del>int</del><ins>size_t</ins> I, class T, size_t N> + T& get(array<T, N>&); +template <<del>int</del><ins>size_t</ins> I, class T, size_t N> + const T& get(const array<T, N>&); +</pre> + +<p> +Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong> +</p> +<pre>tuple_element<<ins>size_t </ins>I, array<T, N> >::type +</pre> +<p> +3 <em>Requires:</em> <code><del>0 <= </del>I < N.</code> The program is ill-formed if <code>I</code> is out of bounds. +</p> +<p> +4 <em>Value:</em> The type <code>T</code>. +</p> +<pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> T& get(array<T, N>& a); +</pre> +<p> +5 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds. +</p> +<p> +<em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based. +</p> +<p> +<ins><em>Throws:</em> Nothing.</ins> +</p> +<pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> const T& get(const array<T, N>& a); +</pre> +<p> +6 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds. +</p> +<p> +7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based. +</p> +<p> +<ins><em>Throws:</em> Nothing.</ins> +</p> + + +<p><i>[ +Bellevue: Note also that the phrase "The program is ill-formed if I is +out of bounds" in the requires clauses are probably unnecessary, and +could be removed at the editor's discretion. Also std:: qualification +for pair is also unnecessary. +]</i></p> + + + + +<hr> +<h3><a name="777"></a>777. Atomics Library Issue</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#WP">WP</a> + <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-01-21</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The load functions are defined as +</p> + +<blockquote><pre>C atomic_load(volatile A* object); +C atomic_load_explicit(volatile A* object, memory_order); +C A::load(memory_order order = memory_order_seq_cst) volatile; +</pre></blockquote> + +<p> +which prevents their use in <tt>const</tt> contexts. +</p> + +<p><i>[ +post Bellevue Peter adds: +]</i></p> + + +<blockquote> +<p> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a +subtle point here. Atomic loads do not generally write to the object, except +potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the +architecture, a dummy write with the same value may be required to be issued +by the atomic load to maintain sequential consistency. This, in turn, may +make the following code: +</p> + +<blockquote><pre>const atomic_int x{}; + +int main() +{ + x.load(); +} +</pre></blockquote> + +<p> +dump core under a straightforward implementation that puts const objects in +a read-only section. +</p> +<p> +There are ways to sidestep the problem, but it needs to be considered. +</p> +<p> +The tradeoff is between making the data member of the atomic types +mutable and requiring the user to explicitly mark atomic members as +mutable, as is already the case with mutexes. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>. +</p> + +<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object); +C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order); +C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</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#WP">WP</a> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-01-24</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#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p> +<p><b>Discussion:</b></p> +<p> +A small issue with <tt>std::bitset</tt>: it does not have any constructor +taking a string literal, which is clumsy and looks like an oversigt when +we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library. +</p> + +<p> +Suggestion: Add +</p> + +<blockquote><pre>explicit bitset( const char* str ); +</pre></blockquote> + +<p> +to std::bitset. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to synopsis in 23.3.5 [template.bitset] +</p> + +<blockquote><pre>explicit bitset( const char* str ); +</pre></blockquote> + +<p> +Add to synopsis in 23.3.5.1 [bitset.cons] +</p> + +<blockquote><pre>explicit bitset( const char* str ); +</pre> +<p> +<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>. +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3> +<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +A comparision of the N2461 header <tt><complex></tt> synopsis ([complex.synopsis]) +with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show +some complex functions that are missing in C++. These are: +</p> + +<ol> +<li> +7.3.9.4: (required elements of the C99 library)<br> +The <tt>cproj</tt> functions +</li> +<li> +7.26.1: (optional elements of the C99 library)<br> +<pre>cerf cerfc cexp2 +cexpm1 clog10 clog1p +clog2 clgamma ctgamma +</pre> +</li> +</ol> + +<p> +I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent +C++ functions. This addition is easy to do in one sentence (delegation to C99 +function). +</p> + +<p> +Please note also that the current entry <tt>polar</tt> +in 26.3.9 [cmplx.over]/1 +should be removed from the mentioned overload list. It does not make sense to require that a +function already expecting <em>scalar</em> arguments +should cast these arguments into corresponding +<tt>complex<T></tt> arguments, which are not accepted by +this function. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>: +</p> + +<blockquote><pre>template<class T> complex<T> conj(const complex<T>&); +<ins>template<class T> complex<T> proj(const complex<T>&);</ins> +template<class T> complex<T> fabs(const complex<T>&); +</pre></blockquote> + +<p> +In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add: +</p> + +<blockquote> +<pre>template<class T> complex<T> proj(const complex<T>& x); +</pre> +<blockquote> + +<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in +subclause 7.3.9.4." +</blockquote> +</blockquote> + +<p> +In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to +the overload list. +</p> + +<blockquote> +<p> +The following function templates shall have additional overloads: +</p> +<blockquote><pre>arg norm +conj <del>polar</del> <ins>proj</ins> +imag real +</pre></blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</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#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-27</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Part of the resolution of n2423, issue 8 was the proposal to +extend the <tt>seed_seq</tt> constructor accepting an input range +as follows (which is now part of N2461): +</p> + +<blockquote><pre>template<class InputIterator, +size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits> +seed_seq(InputIterator begin, InputIterator end); +</pre></blockquote> + +<p> +First, the expression <tt>iterator_traits<InputIterator>::value_type</tt> +is invalid due to missing <tt>typename</tt> keyword, which is easy to +fix. +</p> + +<p> +Second (and worse), while the language now supports default +template arguments of function templates, this customization +point via the second <tt>size_t</tt> template parameter is of no advantage, +because <tt>u</tt> can never be deduced, and worse - because it is a +constructor function template - it can also never be explicitly +provided (14.8.1 [temp.arg.explicit]/7). +</p> + +<p> +The question arises, which advantages result from a compile-time +knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge +suffices, this parameter should be provided as normal function +default argument [Resolution marked (A)], if compile-time knowledge +is important, this could be done via a tagging template or more +user-friendly via a standardized helper generator function +(<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)]. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Fermilab does not have a strong opinion. Would prefer to go with +solution A. Bill agrees that solution A is a lot simpler and does the +job. +</p> +<p> +Proposed Resolution: Accept Solution A. +</p> +</blockquote> + +<p> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot. +</p> + + + +<p><b>Proposed resolution:</b></p> +<ol type="A"> +<li> +<p> +In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace: +</p> + +<blockquote><pre>class seed_seq +{ +public: + ... + template<class InputIterator<del>, + size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>> + seed_seq(InputIterator begin, InputIterator end<ins>, + size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</ins>); + ... +}; +</pre></blockquote> + +<p> +and do a similar replacement in the member description between +p.3 and p.4. +</p> +</li> + +<li> +<p> +In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the +member description between p.3 and p.4 replace: +</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); +<ins>template<class InputIterator, size_t u> +seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins> +</pre></blockquote> + +<p> +In 26.4.2 [rand.synopsis], header <tt><random></tt> synopsis, immediately after the +class <tt>seed_seq</tt> declaration <em>and</em> in 26.4.7.1 [rand.util.seedseq]/2, immediately +after the class <tt>seed_seq</tt> definition add: +</p> + +<blockquote><pre>template<size_t u, class InputIterator> + seed_seq make_seed_seq(InputIterator begin, InputIterator end); +</pre></blockquote> + +<p> +In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs: +</p> + +<blockquote> +<p> +The first constructor behaves as if it would provide an +integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value +<tt>numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</tt>. +</p> +<p> +The second constructor uses an implementation-defined mechanism +to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and +is called by the function <tt>make_seed_seq</tt>. +</p> +</blockquote> + +<p> +In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add: +</p> + +<blockquote> +<pre>template<size_t u, class InputIterator> + seed_seq make_seed_seq(InputIterator begin, InputIterator end); +</pre> +<blockquote> +<p> +where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type. +</p> +<p> +<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>; +</p> +</blockquote> +</blockquote> + +</li> +</ol> + + + + + + +<hr> +<h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3> +<p><b>Section:</b> 30.2.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Hans Boehm <b>Date:</b> 2008-02-01</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current working paper +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>, +integrated just before Bellevue) is +not completely clear whether a given <tt>thread::id</tt> value may be reused once +a thread has exited and has been joined or detached. Posix allows +thread ids (<tt>pthread_t</tt> values) to be reused in this case. Although it is +not completely clear whether this originally was the right decision, it +is clearly the established practice, and we believe it was always the +intent of the C++ threads API to follow Posix and allow this. Howard +Hinnant's example implementation implicitly relies on allowing reuse +of ids, since it uses Posix thread ids directly. +</p> + +<p> +It is important to be clear on this point, since it the reuse of thread +ids often requires extra care in client code, which would not be +necessary if thread ids were unique across all time. For example, a +hash table indexed by thread id may have to be careful not to associate +data values from an old thread with a new one that happens to reuse the +id. Simply removing the old entry after joining a thread may not be +sufficient, if it creates a visible window between the join and removal +during which a new thread with the same id could have been created and +added to the table. +</p> + +<p><i>[ +post Bellevue Peter adds: +]</i></p> + + +<blockquote> +<p> +There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to +reconsider fixing this by disallowing reuse, rather than explicitly allowing +it. Dealing with thread id reuse is an incredibly painful exercise that +would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over +and over. +</p> +<p> +In addition, it would be nice if a <tt>thread::id</tt> could be manipulated +atomically in a lock-free manner, as motivated by the recursive lock +example: +</p> + +<p> +<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a> +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add a sentence to 30.2.1.1 [thread.thread.id]/p1: +</p> + +<blockquote> +<p> +An object of type <code>thread::id</code> provides +a unique identifier for each thread of execution +and a single distinct value for all thread objects +that do not represent a thread of execution ([thread.threads.class]). +Each thread of execution has a <code>thread::id</code> +that is not equal to the <code>thread::id</code> +of other threads of execution +and that is not equal to +the <code>thread::id</code> of <code>std::thread</code> objects +that do not represent threads of execution. +<ins>The library may reuse the value of a <code>thread::id</code> of a +terminated thread that can no longer be joined.</ins> +</p> +</blockquote> + + + + + +<hr> +<h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3> +<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Non-controversial. Bill is right, but Fermilab believes that this is +easy to use badly and hard to use right, and so it should be removed +entirely. Got into TR1 by well defined route, do we have permission to +remove stuff? Should probably check with Jens, as it is believed he is +the originator. Broad consensus that this is not a robust engine +adapter. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis]. +</p> +<p> +Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>. +</p> + + + + + +<hr> +<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>piecewise_constant_distribution</tt> is undefined for a range with just one +endpoint. (Probably should be the same as an empty range.) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b: +</p> + +<blockquote> +b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>, +</blockquote> + + + + + +<hr> +<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3> +<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a> +and its earlier predecessors have moved the old binders from +[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming +of the template parameter names (<tt>Operation -> Fn</tt>). During this +renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to +<tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if +this user access point is probably rarely used. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change D.8.1 [depr.lib.binder.1st]: +</p> + +<blockquote> +<pre>template <class Fn> +class binder1st + : public unary_function<typename Fn::second_argument_type, + typename Fn::result_type> { +protected: + Fn <del>fn</del> <ins>op</ins>; + typename Fn::first_argument_type value; +public: + binder1st(const Fn& x, + const typename Fn::first_argument_type& y); + typename Fn::result_type + operator()(const typename Fn::second_argument_type& x) const; + typename Fn::result_type + operator()(typename Fn::second_argument_type& x) const; +}; +</pre> + +<blockquote> +<p> +-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>. +</p> +<p> +-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>. +</p> +</blockquote> +</blockquote> + +<p> +Change D.8.3 [depr.lib.binder.2nd]: +</p> + +<blockquote> +<pre>template <class Fn> +class binder2nd + : public unary_function<typename Fn::first_argument_type, + typename Fn::result_type> { +protected: + Fn <del>fn</del> <ins>op</ins>; + typename Fn::second_argument_type value; +public: + binder2nd(const Fn& x, + const typename Fn::second_argument_type& y); + typename Fn::result_type + operator()(const typename Fn::first_argument_type& x) const; + typename Fn::result_type + operator()(typename Fn::first_argument_type& x) const; +}; +</pre> + +<blockquote> +<p> +-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>. +</p> +<p> +-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>. +</p> +</blockquote> +</blockquote> + + + + + + +</body></html>
\ No newline at end of file diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/PythonPoweredSmall.gif b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/PythonPoweredSmall.gif Binary files differnew file mode 100644 index 000000000..268980706 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/PythonPoweredSmall.gif diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/acks.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/acks.html new file mode 100644 index 000000000..6612a4a81 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/acks.html @@ -0,0 +1,65 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Acknowledgments</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Acknowledgments</h1> + + <ol> + <li>This library was partially written at <a href= + "http://www.haifa.il.ibm.com/">IBM's Haifa Research + Labs</a>.</li> + + <li>The library is based heavily on policy-based design and + uses many useful techniques from [<a href= + "references.html#alexandrescu01modern">alexandrescu01modern</a>].</li> + + <li>Two ideas are borrowed from the SGI-STL implementation + [<a href="references.html#sgi_stl">sgi_stl</a>]: + + <ol> + <li>The prime-based resize policies use a list of primes + taken from the SGI-STL implementation.</li> + + <li>The red-black trees contain both a root node and a + header node (containing metadata), connected in a way + that forward and reverse iteration can be performed + efficiently.</li> + </ol> + </li> + + <li>Some test utilities borrow ideas from [<a href= + "references.html#boost_timer">boost_timer</a>].</li> + + <li>We would like to thank Scott Meyers for useful comments + (without attributing to him any flaws in the design or + implementation of the library).</li> + + <li>Much of the documentation is <a href= + "http://www.python.org/"><img src="PythonPoweredSmall.gif" + align="middle" width="55" height="22" alt="[Python Powered]" + border="0" /></a> (especially through <a href= + "http://home.gna.org/pychart/">PyChart</a>, <a href= + "http://www.crummy.com/software/BeautifulSoup/">Beautiful + Soup</a>, and <a href= + "http://starship.python.net/crew/aaron_watters/kjbuckets/">kjbuckets</a>) + and uses <a href="http://tidy.sourceforge.net/"><img src= + "checked_by_tidy.gif" align="middle" width="55" height="45" + alt="[HTML tidy]" border="0" /></a>. The CSS-driven menus are + slightly modified from <a href= + "http://www.brothercake.com/scripts/navmeister/page.php">Brothercake</a> + (hopefully without introducing errors).</li> + </ol> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.png Binary files differnew file mode 100644 index 000000000..16cc6da87 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.svg b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.svg new file mode 100644 index 000000000..02be62416 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.svg @@ -0,0 +1,491 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> +<svg + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://web.resource.org/cc/" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="11in" + height="8.5in" + id="svg2" + sodipodi:version="0.32" + inkscape:version="0.43" + version="1.0" + sodipodi:docbase="/mnt/share/src/policy_based_data_structures/pb_ds_images" + sodipodi:docname="assoc_tag_diagram_2.svg" + inkscape:export-filename="/mnt/share/src/policy_based_data_structures/pb_ds_images/assoc_tag_diagram_2.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90"> + <defs + id="defs4"> + <marker + inkscape:stockid="Arrow1Mstart" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Mstart" + style="overflow:visible"> + <path + id="path3311" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none" + transform="scale(0.4)" /> + </marker> + <marker + inkscape:stockid="Arrow2Sstart" + orient="auto" + refY="0" + refX="0" + id="Arrow2Sstart" + style="overflow:visible"> + <path + id="path3319" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(0.3,0,0,0.3,-1.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Sstart" + orient="auto" + refY="0" + refX="0" + id="Arrow1Sstart" + style="overflow:visible"> + <path + id="path3337" + d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none" + transform="scale(0.2,0.2)" /> + </marker> + <marker + inkscape:stockid="Arrow2Send" + orient="auto" + refY="0" + refX="0" + id="Arrow2Send" + style="overflow:visible"> + <path + id="path3316" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(-0.3,0,0,-0.3,1.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend" + style="overflow:visible"> + <path + id="path3322" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(-0.6,0,0,-0.6,3,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Lend" + style="overflow:visible"> + <path + id="path3346" + d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none" + transform="scale(-0.8,-0.8)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lstart" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lstart" + style="overflow:visible"> + <path + id="path3331" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(1.1,0,0,1.1,-5.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lend" + style="overflow:visible"> + <path + id="path3328" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(-1.1,0,0,-1.1,5.5,0)" /> + </marker> + </defs> + <sodipodi:namedview + id="base" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="2" + inkscape:cx="613.85775" + inkscape:cy="310.05621" + inkscape:document-units="in" + inkscape:current-layer="layer1" + showguides="true" + inkscape:guide-bbox="true" + inkscape:window-width="1278" + inkscape:window-height="973" + inkscape:window-x="0" + inkscape:window-y="0" + gridtolerance="0.125in" + guidetolerance="0.125in"> + <sodipodi:guide + orientation="horizontal" + position="629" + id="guide1307" /> + <sodipodi:guide + orientation="horizontal" + position="449" + id="guide1309" /> + <sodipodi:guide + orientation="horizontal" + position="269" + id="guide1311" /> + <sodipodi:guide + orientation="vertical" + position="496" + id="guide1313" /> + <sodipodi:guide + orientation="vertical" + position="361" + id="guide1315" /> + <sodipodi:guide + orientation="vertical" + position="226" + id="guide1317" /> + <sodipodi:guide + orientation="vertical" + position="631" + id="guide1319" /> + <sodipodi:guide + orientation="vertical" + position="766" + id="guide1321" /> + <sodipodi:guide + orientation="vertical" + position="91" + id="guide1345" /> + <sodipodi:guide + orientation="vertical" + position="901" + id="guide1347" /> + <sodipodi:guide + orientation="horizontal" + position="539" + id="guide3390" /> + <sodipodi:guide + orientation="horizontal" + position="359" + id="guide3392" /> + <sodipodi:guide + orientation="vertical" + position="280.5" + id="guide3324" /> + <sodipodi:guide + orientation="vertical" + position="172" + id="guide3326" /> + <sodipodi:guide + orientation="vertical" + position="427" + id="guide3328" /> + <sodipodi:guide + orientation="vertical" + position="711.5" + id="guide3340" /> + <sodipodi:guide + orientation="horizontal" + position="179" + id="guide1395" /> + </sodipodi:namedview> + <metadata + id="metadata7"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:creator> + <cc:Agent> + <dc:title>Benjamin Kosnik</dc:title> + </cc:Agent> + </dc:creator> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1"> + <rect + y="562.32806" + x="237.8916" + height="23.200001" + width="80.769417" + id="rect1495" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.94391561;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.94391561;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect1497" + width="80.769417" + height="23.200001" + x="132.8916" + y="562.32806" /> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.94391561;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect1493" + width="80.769417" + height="23.200001" + x="21.891602" + y="562.32806" /> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect1425" + width="141.64481" + height="23.200001" + x="209.57762" + y="382.56177" /> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3378" + width="141.64481" + height="23.200001" + x="640.77765" + y="382.56177" /> + <text + xml:space="preserve" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans;stroke-miterlimit:4;stroke-dasharray:none" + x="710.40002" + y="397.09772" + id="use1337" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1391" + x="710.40003" + y="397.09772">basic_hash_table_tag</tspan></text> + <text + xml:space="preserve" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="280" + y="397.09772" + id="text1339" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1385" + x="280" + y="397.09772">basic_tree_tag</tspan></text> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3418" + width="141.64481" + height="23.200001" + x="101.57762" + y="472.5618" /> + <rect + y="472.5618" + x="317.57761" + height="23.200001" + width="141.64481" + id="rect3420" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <text + xml:space="preserve" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="171.20001" + y="486.29773" + id="text3394" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1387" + x="171.20001" + y="486.29773">tree_tag</tspan></text> + <text + sodipodi:linespacing="100%" + id="text3400" + y="486.29773" + x="388.39999" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1389" + x="388.39999" + y="486.29773">trie_tag</tspan></text> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3380" + width="141.64481" + height="23.200001" + x="425.57764" + y="292.56177" /> + <text + xml:space="preserve" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="495.20001" + y="307.09772" + id="text1323" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1384" + x="495.20001" + y="307.09772">associative_container_tag</tspan></text> + <path + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none" + d="M 170.97058,472.5 L 170.97058,451 L 387.51871,450 L 387.51871,472.5" + id="path2244" /> + <path + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="M 280.5,450.53297 L 280.5,410.62445" + id="path3332" /> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3422" + width="141.64481" + height="23.200001" + x="533.57764" + y="472.5618" /> + <rect + y="472.5618" + x="748.77765" + height="23.200001" + width="141.64481" + id="rect3424" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <text + sodipodi:linespacing="100%" + id="text3406" + y="486.29773" + x="601.20001" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1393" + x="601.20001" + y="486.29773">cc_hash_table_tag</tspan></text> + <text + xml:space="preserve" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="818" + y="486.29773" + id="text3412" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1395" + x="818" + y="486.29773">gp_hash_table_tag</tspan></text> + <path + id="path3353" + d="M 601.47058,472.5 L 601.47058,451 L 818.01871,450 L 818.01871,472.5" + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none" /> + <path + id="path3355" + d="M 711,450.53297 L 711,410.62445" + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <path + id="path3344" + d="M 281.18218,383.28102 L 281.18218,361.78102 L 711.79281,360.78102 L 711.79281,383.28102" + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none" /> + <rect + y="383.1962" + x="425.625" + height="23.200001" + width="141.64481" + id="rect3376" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <text + sodipodi:linespacing="100%" + id="use1329" + y="397.73215" + x="497.24741" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1382" + x="497.24741" + y="397.73215">list_update_tag</tspan></text> + <path + id="path3347" + d="M 497.79886,384.13056 L 497.79886,323.40547" + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <text + xml:space="preserve" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="61.152512" + y="577.07874" + id="text1423" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1418" + x="61.152512" + y="577.07874">rb_tree_tag</tspan></text> + <text + sodipodi:linespacing="100%" + id="text1427" + y="577.07874" + x="277.95251" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1414" + x="277.95252" + y="577.07874">splay_tree_tag</tspan></text> + <path + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none" + d="M 61.42308,563.28102 L 61.42308,541.78102 L 277.97121,540.78102 L 277.97121,563.28102" + id="path1431" /> + <path + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="M 170.9525,561.5357 L 170.9525,503.81235" + id="path1433" /> + <rect + y="562.17499" + x="347.8916" + height="23.200001" + width="80.769417" + id="rect1469" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.94391561;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <text + sodipodi:linespacing="100%" + id="text1471" + y="576.71094" + x="388.80002" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1412" + x="388.80002" + y="576.71094">pat_trie_tag</tspan></text> + <path + id="path1475" + d="M 389.35146,563.10936 L 389.35146,502.38427" + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <text + xml:space="preserve" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="173.95251" + y="577.07874" + id="text1487" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1416" + x="173.95251" + y="577.07874">ov_tree_tag</tspan></text> + </g> +</svg> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_traits.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_traits.html new file mode 100644 index 000000000..7814712c3 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_traits.html @@ -0,0 +1,170 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>container_traits Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>container_traits</tt> Interface</h1> + + <p>Traits of an associative-container based on its underlying + data structure.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Cntnr59189" id="Cntnr59189"><b>class</b> Cntnr</a> +</pre> + </td> + + <td> + <p>Container type.</p> + </td> + + <td>-</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">Container Attributes</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="invalidation_guarantee3793555937" id= +"invalidation_guarantee3793555937">invalidation_guarantee</a> +</pre> + </td> + + <td> + <pre> +Invalidation guarantee. +</pre> + </td> + + <td> + <p>Invalidation-guarantee type.</p> + + <p>This is either <a href= + "basic_invalidation_guarantee.html"><span class= + "c2"><tt>basic_invalidation_guarantee</tt></span></a>, + <a href="point_invalidation_guarantee.html"><span class= + "c2"><tt>point_invalidation_guarantee</tt></span></a>, or + <a href="range_invalidation_guarantee.html"><span class= + "c2"><tt>range_invalidation_guarantee</tt></span></a></p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="order_preserving1910229172" id= +"order_preserving1910229172">order_preserving</a> +</pre> + </td> + + <td> + <pre> +True only if Cntnr objects guarantee storing keys by order. +</pre> + </td> + + <td> + <p>Order-preserving indicator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="erase_can_throw153323856" id= +"erase_can_throw153323856">erase_can_throw</a> +</pre> + </td> + + <td> + <pre> +True only if erasing a key can throw. +</pre> + </td> + + <td> + <p>Erase-throw indicator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="reverse_iteration894617078" id= +"reverse_iteration894617078">reverse_iteration</a> +</pre> + </td> + + <td> + <pre> +True only reverse iterators are supported. +</pre> + </td> + + <td> + <p>Reverse iteration indicator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="split_join_can_throw3200477759" id= +"split_join_can_throw3200477759">split_join_can_throw</a> +</pre> + </td> + + <td> + <pre> +True only if split or join operations can throw. +</pre> + </td> + + <td> + <p>Split-join throw indicator.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_design.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_design.html new file mode 100644 index 000000000..6c501e26b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_design.html @@ -0,0 +1,46 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Associative Containers</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Associative-Container Design</h1> + + <ol> + <li><a href="ds_gen.html">Data-Structure Genericity</a></li> + + <li class="c1">Genericity discusses generic manipulation of + containers based on different underlying + data structures.</li> + + <li class="c1">Genericity discusses generic manipulation of + containers with different mapping semantics.</li> + + <li><a href="tree_based_containers.html">Tree-Based + Containers</a> describes the design and policies of + tree-based containers.</li> + + <li><a href="trie_based_containers.html">Trie-Based + Containers</a> describes the design and policies of + trie-based containers.</li> + + <li><a href="hash_based_containers.html">Hash-Based + Containers</a> describes the design and policies of + hash-based containers.</li> + + <li><a href="lu_based_containers.html">List-Based + Containers</a> describes the design and policies of + list-based containers with update policies.</li> + </ol> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html new file mode 100644 index 000000000..b64c74745 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html @@ -0,0 +1,151 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Examples</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Associative-Container Examples</h1> + + <h2><a name="basic_usage" id="basic_usage">Basic Use</a></h2> + + <ol> + <li> + <a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_map.cc"><tt>basic_map.cc</tt></a> + Basic use of "maps".</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_set.cc"><tt>basic_set.cc</tt></a> + Basic use of "sets".</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/erase_if.cc"><tt>erase_if.cc</tt></a> + Conditionally erasing values from a container object.</li> + </ol> + + <h2><a name="generics" id="generics">Generics</a></h2> + + <ol> + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/assoc_container_traits.cc"><tt>assoc_container_traits.cc</tt></a> + Using <a href= + "assoc_container_traits.html"><tt>container_traits</tt></a> to query + about underlying data structure behavior.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_find_neg.cc"><tt>hash_find_neg.cc</tt></a> + A non-compiling example showing wrong use of finding keys in + hash-based containers.</li> + </ol> + + <h2><a name="hash_based" id="hash_based">Hash-Based + Containers</a></h2> + + + <h3><a name="resize_related" id="resize_related">Resize + Related</a></h3> + + + <ol> + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_initial_size.cc"><tt>hash_initial_size.cc</tt></a> + Setting the initial size of a hash-based container + object.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_resize_neg.cc"><tt>hash_resize_neg.cc</tt></a> + A non-compiling example showing how not to resize a + hash-based container object.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_resize.cc"><tt>hash_resize.cc</tt></a> + Resizing the size of a hash-based container object.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_illegal_resize.cc"><tt>hash_illegal_resize.cc</tt></a> + Showing an illegal resize of a hash-based container + object.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_load_set_change.cc"><tt>hash_load_set_change.cc</tt></a> + Changing the load factors of a hash-based container + object.</li> + </ol> + + <h3><a name="hash_related" id="hash_related">Hash-Function + Related</a></h3> + + + <ol> + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_mod.cc"><tt>hash_mod.cc</tt></a> + Using a modulo range-hashing function for the case of an + unknown skewed key distribution.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_shift_mask.cc"><tt>shift_mask.cc</tt></a> + Writing a range-hashing functor for the case of a known + skewed key distribution.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/store_hash.cc"><tt>store_hash.cc</tt></a> + Storing the hash value along with each key.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/ranged_hash.cc"><tt>ranged_hash.cc</tt></a> + Writing a ranged-hash functor.</li> + </ol> + + <h2><a name="tree_like_based" id= "tree_like_based">Tree-Like Containers (Trees and + Tries)</a></h2> + + + <h3><a name="node_invariants" id= + "node_invariants">Node-Invariants</a></h3> + + + <ol> + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_order_statistics.cc"><tt>tree_order_statistics.cc</tt></a> + Using trees for order statistics.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_intervals.cc"><tt>tree_intervals.cc</tt></a> + Augmenting trees to support operations on line + intervals.</li> + </ol> + + <h3><a name="split_join" id="split_join">Split and + Join</a></h3> + + + <ol> + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_join.cc"><tt>tree_join.cc</tt></a> + Joining two tree-based container objects.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/trie_split.cc"><tt>trie_split.cc</tt></a> + Splitting a PATRICIA trie container object.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_order_statistics_join.cc"><tt>tree_order_statistics_join.cc</tt></a> + Order statistics while joining two tree-based container + objects.</li> + </ol> + + <h2><a name="trie_based" id="trie_based">Trie-Based + Containers</a></h2> + + + <ol> + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/trie_dna.cc"><tt>trie_dna.cc</tt></a> + Using a PATRICIA trie for DNA strings.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/trie_prefix_search.cc"><tt>trie_prefix_search.cc</tt></a> + Using a PATRICIA trie for finding all entries whose key + matches a given prefix.</li> + </ol> + + <h2><a name="mmaps" id="mmaps">"Multimaps" and + "Multisets".</a></h2> + <ol> + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_multimap.cc"><tt>basic_multimap.cc</tt></a> + Basic use of "multimaps".</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_multiset.cc"><tt>basic_multiset.cc</tt></a> + Basic use of "multisets".</li> + </ol> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_performance_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_performance_tests.html new file mode 100644 index 000000000..642f84809 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_performance_tests.html @@ -0,0 +1,345 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Associative-Container Performance Tests</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1><a name="assoc" id="assoc">Associative-Container + Performance Tests</a></h1> +<h2><a name="settings" id="settings">Settings</a></h2> +<p>This section describes performance tests and their results. + In the following, <a href="#gcc"><u>g++</u></a>, <a href="#msvc"><u>msvc++</u></a>, and <a href="#local"><u>local</u></a> (the build used for generating this + documentation) stand for three different builds:</p> +<div id="gcc_settings_div"> +<div class="c1"> +<h3><a name="gcc" id="gcc"><u>g++</u></a></h3> +<ul> +<li>CPU speed - cpu MHz : 2660.644</li> +<li>Memory - MemTotal: 484412 kB</li> +<li>Platform - + Linux-2.6.12-9-386-i686-with-debian-testing-unstable</li> +<li>Compiler - g++ (GCC) 4.0.2 20050808 (prerelease) + (Ubuntu 4.0.1-4ubuntu9) Copyright (C) 2005 Free Software + Foundation, Inc. This is free software; see the source + for copying conditions. There is NO warranty; not even + for MERCHANTABILITY or FITNESS FOR A PARTICULAR + PURPOSE.</li> +</ul> +</div> +<div class="c2"></div> +</div> +<div id="msvc_settings_div"> +<div class="c1"> +<h3><a name="msvc" id="msvc"><u>msvc++</u></a></h3> +<ul> +<li>CPU speed - cpu MHz : 2660.554</li> +<li>Memory - MemTotal: 484412 kB</li> +<li>Platform - Windows XP Pro</li> +<li>Compiler - Microsoft (R) 32-bit C/C++ Optimizing + Compiler Version 13.10.3077 for 80x86 Copyright (C) + Microsoft Corporation 1984-2002. All rights + reserved.</li> +</ul> +</div> +<div class="c2"></div> +</div> +<div id="local_settings_div"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h3><a name = "local"><u>local</u></a></h3><ul> +<li>CPU speed - cpu MHz : 2250.000</li> +<li>Memory - MemTotal: 2076248 kB</li> +<li>Platform - Linux-2.6.16-1.2133_FC5-i686-with-redhat-5-Bordeaux</li> +<li>Compiler - g++ (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) +Copyright (C) 2006 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +</li> +</ul> +</div><div style = "width: 100%; height: 20px"></div></div> +<h2><a name="assoc_tests" id="assoc_tests">Tests</a></h2> +<h3><a name="hash_based" id="hash_based">Hash-Based + Containers</a></h3> +<ol> +<li><a href="hash_text_find_find_timing_test.html">Hash-Based + Text <tt>find</tt> Find Timing Test</a></li> +<li><a href="hash_random_int_find_find_timing_test.html">Hash-Based + Random-Integer <tt>find</tt> Find Timing Test</a></li> +<li><a href="hash_random_int_subscript_find_timing_test.html">Hash-Based + Random-Integer Subscript Find Timing Test</a></li> +<li><a href="hash_random_int_subscript_insert_timing_test.html">Hash-Based + Random-Integer Subscript Insert Timing Test</a></li> +<li><a href="hash_zlob_random_int_find_find_timing_test.html">Hash-Based + Skewed-Distribution Random-Integer <tt>find</tt> Find Timing + Test</a></li> +<li><a href="hash_random_int_erase_mem_usage_test.html">Hash-Based Erase + Memory Use Test</a></li> +</ol> +<h3><a name="tree_like_based" id="tree_like_based">Tree-Like-Based Containers</a></h3> +<ol> +<li><a href="tree_text_insert_timing_test.html">Tree-Based + and Trie-Based Text Insert Timing Test</a></li> +<li><a href="tree_text_find_find_timing_test.html">Tree-Based + and Trie-Based Text <tt>find</tt> Find Timing Test</a></li> +<li><a href="tree_text_lor_find_find_timing_test.html">Tree-Based + Locality-of-Reference Text <tt>find</tt> Find Timing + Test</a></li> +<li><a href="tree_random_int_find_find_timing_test.html">Tree-Based + Random-Integer <tt>find</tt> Find Timing Test</a></li> +<li><a href="tree_split_join_timing_test.html">Tree Split and + Join Timing Test</a></li> +<li><a href="tree_order_statistics_timing_test.html">Tree + Order-Statistics Timing Test</a></li> +</ol> +<h3><a name="multimaps" id="multimaps">Multimaps</a></h3> +<ol> +<li><a href="multimap_text_find_timing_test_small.html">"Multimap" + Text Find Timing Test with <u>Small</u> Average Secondary-Key + to Primary-Key Ratio</a></li> +<li><a href="multimap_text_find_timing_test_large.html">"Multimap" + Text Find Timing Test with <u>Large</u> Average Secondary-Key + to Primary-Key Ratio</a></li> +<li><a href="multimap_text_insert_timing_test_small.html">"Multimap" + Text Insert Timing Test with <u>Small</u> Average + Secondary-Key to Primary-Key Ratio</a></li> +<li><a href="multimap_text_insert_timing_test_large.html">"Multimap" + Text Insert Timing Test with <u>Large</u> Average + Secondary-Key to Primary-Key Ratio</a></li> +<li><a href="multimap_text_insert_mem_usage_test_small.html">"Multimap" + Text Insert Memory-Use Test with <u>Small</u> Average + Secondary-Key to Primary-Key Ratio</a></li> +<li><a href="multimap_text_insert_mem_usage_test_large.html">"Multimap" + Text Insert Memory-Use Test with <u>Large</u> Average + Secondary-Key to Primary-Key Ratio</a></li> +</ol> +<h2><a name="assoc_observations" id="assoc_observations">Observations</a></h2> +<h3><a name="dss_family_choice" id="dss_family_choice">Underlying Data-Structure Families</a></h3> +<p>In general, hash-based containers (see <a href="hash_based_containers.html">Design::Associative + Containers::Hash-Based Containers</a>) have better timing + performance than containers based on different underlying-data + structures. The main reason to choose a tree-based (see + <a href="tree_based_containers.html">Design::Associative + Containers::Tree-Based Containers</a>) or trie-based container + (see <a href="trie_based_containers.html">Design::Associative + Containers::Trie-Based Containers</a>) is if a byproduct of the + tree-like structure is required: either order-preservation, or + the ability to utilize node invariants (see <a href="tree_based_containers.html#invariants">Design::Associative + Containers::Tree-Based Containers::Node Invariants</a> and + <a href="trie_based_containers.html#invariants">Design::Associative + Containers::Trie-Based Containers::Node Invariants</a>). If + memory-use is the major factor, an ordered-vector tree (see + <a href="tree_based_containers.html">Design::Associative + Containers::Tree-Based Containers</a>) gives optimal results + (albeit with high modificiation costs), and a list-based + container (see <a href="lu_based_containers.html">Design::Associative + Containers::List-Based Containers</a>) gives reasonable + results.</p> +<h3><a name="hash_based_types" id="hash_based_types">Hash-Based + Container Types</a></h3> +<p>Hash-based containers are typically either collision + chaining or probing (see <a href="hash_based_containers.html">Design::Associative + Containers::Hash-Based Containers</a>). Collision-chaining + containers are more flexible internally, and so offer better + timing performance. Probing containers, if used for simple + value-types, manage memory more efficiently (they perform far + fewer allocation-related calls). In general, therefore, a + collision-chaining table should be used. A probing container, + conversely, might be used efficiently for operations such as + eliminating duplicates in a sequence, or counting the number of + occurrences within a sequence. Probing containers might be more + useful also in multithreaded applications where each thread + manipulates a hash-based container: in the STL, allocators have + class-wise semantics (see [<a href="references.html#meyers96more">meyers96more</a>] - Item 10); a + probing container might incur less contention in this case.</p> +<h3><a name="hash_based_policies" id="hash_based_policies">Hash-Based Containers' Policies</a></h3> +<p>In hash-based containers, the range-hashing scheme (see + <a href="hash_based_containers.html#hash_policies">Design::Associative + Containers::Hash-Based Containers::Hash Policies</a>) seems to + affect performance more than other considerations. In most + settings, a mask-based scheme works well (or can be made to + work well). If the key-distribution can be estimated a-priori, + a simple hash function can produce nearly uniform hash-value + distribution. In many other cases (<i>e.g.</i>, text hashing, + floating-point hashing), the hash function is powerful enough + to generate hash values with good uniformity properties + [<a href="references.html#knuth98sorting">knuth98sorting</a>]; + a modulo-based scheme, taking into account all bits of the hash + value, appears to overlap the hash function in its effort.</p> +<p>The range-hashing scheme determines many of the other + policies (see <a href="hash_based_containers.html#policy_interaction">Design::Hash-Based + Containers::Policy Interaction</a>). A mask-based scheme works + well with an exponential-size policy (see <a href="hash_based_containers.html#resize_policies">Design::Associative + Containers::Hash-Based Containers::Resize Policies</a>) ; for + probing-based containers, it goes well with a linear-probe + function (see <a href="hash_based_containers.html#hash_policies">Design::Associative + Containers::Hash-Based Containers::Hash Policies</a>).</p> +<p>An orthogonal consideration is the trigger policy (see + <a href="hash_based_containers.html#resize_policies">Design::Associative + Containers::Hash-Based Containers::Resize Policies</a>). This + presents difficult tradeoffs. <i>E.g.</i>, different load + factors in a load-check trigger policy yield a + space/amortized-cost tradeoff.</p> +<h3><a name="tree_like_based_types" id="tree_like_based_types">Tree-Like-Based Container + Types</a></h3> +<p>In general, there are several families of tree-based + underlying data structures: balanced node-based trees + (<i>e.g.</i>, red-black or AVL trees), high-probability + balanced node-based trees (<i>e.g.</i>, random treaps or + skip-lists), competitive node-based trees (<i>e.g.</i>, splay + trees), vector-based "trees", and tries. (Additionally, there + are disk-residing or network-residing trees, such as B-Trees + and their numerous variants. An interface for this would have + to deal with the execution model and ACID guarantees; this is + out of the scope of this library.) Following are some + observations on their application to different settings.</p> +<p>Of the balanced node-based trees, this library includes a + red-black tree (see <a href="tree_based_containers.html">Design::Associative + Containers::Tree-Based Containers</a>), as does STL (in + practice). This type of tree is the "workhorse" of tree-based + containers: it offers both reasonable modification and + reasonable lookup time. Unfortunately, this data structure + stores a huge amount of metadata. Each node must contain, + besides a value, three pointers and a boolean. This type might + be avoided if space is at a premium [<a href="references.html#austern00noset">austern00noset</a>].</p> +<p>High-probability balanced node-based trees suffer the + drawbacks of deterministic balanced trees. Although they are + fascinating data structures, preliminary tests with them showed + their performance was worse than red-black trees. The library + does not contain any such trees, therefore.</p> +<p>Competitive node-based trees have two drawbacks. They are + usually somewhat unbalanced, and they perform a large number of + comparisons. Balanced trees perform one comparison per each + node they encounter on a search path; a splay tree performs two + comparisons. If the keys are complex objects, <i>e.g.</i>, + <tt>std::string</tt>, this can increase the running time. + Conversely, such trees do well when there is much locality of + reference. It is difficult to determine in which case to prefer + such trees over balanced trees. This library includes a splay + tree (see <a href="tree_based_containers.html">Design::Associative + Containers::Tree-Based Containers</a>).</p> +<p>Ordered-vector trees (see <a href="tree_based_containers.html">Design::Associative + Containers::Tree-Based Containers</a>) use very little space + [<a href="references.html#austern00noset">austern00noset</a>]. + They do not have any other advantages (at least in this + implementation).</p> +<p>Large-fan-out PATRICIA tries (see <a href="trie_based_containers.html">Design::Associative + Containers::Trie-Based Containers</a>) have excellent lookup + performance, but they do so through maintaining, for each node, + a miniature "hash-table". Their space efficiency is low, and + their modification performance is bad. These tries might be + used for semi-static settings, where order preservation is + important. Alternatively, red-black trees cross-referenced with + hash tables can be used. [<a href="references.html#okasaki98mereable">okasaki98mereable</a>] + discusses small-fan-out PATRICIA tries for integers, but the + cited results seem to indicate that the amortized cost of + maintaining such trees is higher than that of balanced trees. + Moderate-fan-out trees might be useful for sequences where each + element has a limited number of choices, <i>e.g.</i>, DNA + strings (see <a href="assoc_examples.html#trie_based">Examples::Associative + Containers::Trie-Based Containers</a>).</p> +<h3><a name="msc" id="msc">Mapping-Semantics + Considerations</a></h3> +<p>Different mapping semantics were discussed in <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Alternative to Multiple Equivalent Keys</a> and + <a href="tutorial.html#assoc_ms">Tutorial::Associative + Containers::Associative Containers Others than Maps</a>. We + will focus here on the case where a keys can be composed into + primary keys and secondary keys. (In the case where some keys + are completely identical, it is trivial that one should use an + associative container mapping values to size types.) In this + case there are (at least) five possibilities:</p> +<ol> +<li>Use an associative container that allows equivalent-key + values (such as <tt>std::multimap</tt>)</li> +<li>Use a unique-key value associative container that maps + each primary key to some complex associative container of + secondary keys, say a tree-based or hash-based container (see + <a href="tree_based_containers.html">Design::Associative + Containers::Tree-Based Containers</a> and <a href="hash_based_containers.html">Design::Associative + Containers::Hash-Based Containers</a>)</li> +<li>Use a unique-key value associative container that maps + each primary key to some simple associative container of + secondary keys, say a list-based container (see <a href="lu_based_containers.html">Design::Associative + Containers::List-Based Containers</a>)</li> +<li>Use a unique-key value associative container that maps + each primary key to some non-associative container + (<i>e.g.</i>, <tt>std::vector</tt>)</li> +<li>Use a unique-key value associative container that takes + into account both primary and secondary keys.</li> +</ol> +<p>We do not think there is a simple answer for this (excluding + option 1, which we think should be avoided in all cases).</p> +<p>If the expected ratio of secondary keys to primary keys is + small, then 3 and 4 seem reasonable. Both types of secondary + containers are relatively lightweight (in terms of memory use + and construction time), and so creating an entire container + object for each primary key is not too expensive. Option 4 + might be preferable to option 3 if changing the secondary key + of some primary key is frequent - one cannot modify an + associative container's key, and the only possibility, + therefore, is erasing the secondary key and inserting another + one instead; a non-associative container, conversely, can + support in-place modification. The actual cost of erasing a + secondary key and inserting another one depends also on the + allocator used for secondary associative-containers (The tests + above used the standard allocator, but in practice one might + choose to use, <i>e.g.</i>, [<a href="references.html#boost_pool">boost_pool</a>]). Option 2 is + definitely an overkill in this case. Option 1 loses out either + immediately (when there is one secondary key per primary key) + or almost immediately after that. Option 5 has the same + drawbacks as option 2, but it has the additional drawback that + finding all values whose primary key is equivalent to some key, + might be linear in the total number of values stored (for + example, if using a hash-based container).</p> +<p>If the expected ratio of secondary keys to primary keys is + large, then the answer is more complicated. It depends on the + distribution of secondary keys to primary keys, the + distribution of accesses according to primary keys, and the + types of operations most frequent.</p> +<p>To be more precise, assume there are <i>m</i> primary keys, + primary key <i>i</i> is mapped to <i>n<sub>i</sub></i> + secondary keys, and each primary key is mapped, on average, to + <i>n</i> secondary keys (<i>i.e.</i>, + <i><b>E</b>(n<sub>i</sub>) = n</i>).</p> +<p>Suppose one wants to find a specific pair of primary and + secondary keys. Using 1 with a tree based container + (<tt>std::multimap</tt>), the expected cost is + <i><b>E</b>(Θ(log(m) + n<sub>i</sub>)) = Θ(log(m) + + n)</i>; using 1 with a hash-based container + (<tt>std::tr1::unordered_multimap</tt>), the expected cost is + <i>Θ(n)</i>. Using 2 with a primary hash-based container + and secondary hash-based containers, the expected cost is + <i>O(1)</i>; using 2 with a primary tree-based container and + secondary tree-based containers, the expected cost is (using + the Jensen inequality [<a href="references.html#motwani95random">motwani95random</a>]) + <i><b>E</b>(O(log(m) + log(n<sub>i</sub>)) = O(log(m)) + + <b>E</b>(O(log(n<sub>i</sub>)) = O(log(m)) + O(log(n))</i>, + assuming that primary keys are accessed equiprobably. 3 and 4 + are similar to 1, but with lower constants. Using 5 with a + hash-based container, the expected cost is <i>O(1)</i>; using 5 + with a tree based container, the cost is + <i><b>E</b>(Θ(log(mn))) = Θ(log(m) + + log(n))</i>.</p> +<p>Suppose one needs the values whose primary key matches some + given key. Using 1 with a hash-based container, the expected + cost is <i>Θ(n)</i>, but the values will not be ordered + by secondary keys (which may or may not be required); using 1 + with a tree-based container, the expected cost is + <i>Θ(log(m) + n)</i>, but with high constants; again the + values will not be ordered by secondary keys. 2, 3, and 4 are + similar to 1, but typically with lower constants (and, + additionally, if one uses a tree-based container for secondary + keys, they will be ordered). Using 5 with a hash-based + container, the cost is <i>Θ(mn)</i>.</p> +<p>Suppose one wants to assign to a primary key all secondary + keys assigned to a different primary key. Using 1 with a + hash-based container, the expected cost is <i>Θ(n)</i>, + but with very high constants; using 1 with a tree-based + container, the cost is <i>Θ(nlog(mn))</i>. Using 2, 3, + and 4, the expected cost is <i>Θ(n)</i>, but typically + with far lower costs than 1. 5 is similar to 1.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_regression_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_regression_tests.html new file mode 100644 index 000000000..9b6b6b839 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_regression_tests.html @@ -0,0 +1,93 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Associative-Container Regression Tests</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> +<base href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/regression/"> + </head> + +<body> + <div id="page"> + <h1>Associative-Container Regression Tests</h1> + + <h2><a name="assoc_desc" id="assoc_desc">Description</a></h2> + + <p>The library contains a single comprehensive regression test. + For a given container type in <tt>pb_ds</tt>, the test creates + an object of the container type and an object of the + corresponding STL type (<i>e.g.</i>, <tt>std::set</tt>). It + then performs a random sequence of methods with random + arguments (<i>e.g.</i>, inserts, erases, and so forth) on both + objects. At each operation, the test checks the return value of + the method, and optionally both compares <tt>pb_ds</tt>'s + object with the STL's object as well as performing other + consistency checks on <tt>pb_ds</tt>'s object (<i>e.g.</i>, + order preservation, when applicable, or node invariants, when + applicable).</p> + + <p>Additionally, the test integrally checks exception safety + and resource leaks. This is done as follows. A special + allocator type, written for the purpose of the test, both + randomly throws an exceptions when allocations are performed, + and tracks allocations and de-allocations. The exceptions thrown + at allocations simulate memory-allocation failures; the + tracking mechanism checks for memory-related bugs (<i>e.g.</i>, + resource leaks and multiple de-allocations). Both + <tt>pb_ds</tt>'s containers and the containers' value-types are + configured to use this allocator.</p> + + <p>Due to compiler constraints, the test is split into the + several sources, each checking only some containers.</p> + + <h2><a name="assoc_tests" id="assoc_tests">Tests</a></h2> + + <h3><a name="assoc_tests_set" id="assoc_tests_set">"Set" + Tests</a></h3> + + <p>The following check all "set" types:</p> + + <ol> + <li><a href= + "hash_no_data_map_rand.cc"><tt>hash_no_data_map_rand.cc</tt></a> + checks all hash-based "set" types.</li> + + <li><a href= + "list_update_no_data_map_rand.cc"><tt>list_update_no_data_map_rand.cc</tt></a> + checks all list-based "set" types.</li> + + <li><a href= + "tree_no_data_map_rand.cc"><tt>tree_no_data_map_rand.cc</tt></a> + checks all tree-based "set" types.</li> + + <li><a href= + "trie_no_data_map_rand.cc"><tt>trie_no_data_map_rand.cc</tt></a> + checks all PATRICIA-trie-based "set" types.</li> + </ol> + + <h3><a name="assoc_tests_map" id="assoc_tests_map">"Map" + Tests</a></h3> + + <p>The following check all "map" types:</p> + + <ol> + <li><a href= "hash_data_map_rand.cc"><tt>hash_data_map_rand.cc</tt></a> + checks all hash-based "map" types.</li> + + <li><a href= "list_update_data_map_rand.cc"><tt>list_update_data_map_rand.cc</tt></a> + checks all list-based "map" types.</li> + + <li><a href= "tree_data_map_rand.cc"><tt>tree_data_map_rand.cc</tt></a> + checks all tree-based "map" types.</li> + + <li><a href= "trie_data_map_rand.cc"><tt>trie_data_map_rand.cc</tt></a> + checks all PATRICIA-trie-based "map" types.</li> + </ol> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_tests.html new file mode 100644 index 000000000..6e4474945 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_tests.html @@ -0,0 +1,24 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Associative-Container Tests</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Associative-Container Tests</h1> + + <p><a href="assoc_regression_tests.html">Associative-Container + Regression Tests</a> describes the regression tests; <a href= + "assoc_performance_tests.html">Associative-Container + Performance Tests</a> describes the performance tests.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/associative_container_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/associative_container_tag.html new file mode 100644 index 000000000..ceb91cdc7 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/associative_container_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>associative_container_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>associative_container_tag</tt> Interface</h1> + + <p>Basic associative-container data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="container_tag.html"><span class= +"c2"><tt>container_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/balls_and_bins.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/balls_and_bins.png Binary files differnew file mode 100644 index 000000000..529c3ae41 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/balls_and_bins.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_table.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_table.html new file mode 100644 index 000000000..668e681d8 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_table.html @@ -0,0 +1,436 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>basic_hash_table Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>basic_hash_table</tt> Interface</h1> + + <p>An abstract basic hash-based associative container.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Key2501" id="Key2501"><b>typename</b> Key</a> +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a> +</pre> + </td> + + <td> + <p>Mapped type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Hash_Fn1515835" id= +"Hash_Fn1515835"><b>class</b> Hash_Fn</a> +</pre> + </td> + + <td> + <p>Hash functor.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Eq_Fn60085" id="Eq_Fn60085"><b>class</b> Eq_Fn</a> +</pre> + </td> + + <td> + <p>Equivalence functor.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Resize_Policy566860465" id= +"Resize_Policy566860465"><b>class</b> Resize_Policy</a> +</pre> + </td> + + <td> + <p>Resize policy.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Store_Hash218262104" id= +"Store_Hash218262104"><b>bool</b> Store_Hash</a> +</pre> + </td> + + <td> + <p>Indicates whether the hash value will be stored along + with each key.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Tag278938" id="Tag278938"><b>class</b> Tag</a> +</pre> + </td> + + <td> + <p>Mapped-structure tag.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator</a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td>-</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#Resize_Policy566860465"><tt>Resize_Policy</tt></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="container_base.html"><span class= +"c2"><tt>container_base</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Types and + Constants</a></h2> + + <h3><a name="link4" id="link4">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="hash_fn2015995" id="hash_fn2015995">hash_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a> +</pre> + </td> + + <td> + <p>Hash functor type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="eq_fn80245" id="eq_fn80245">eq_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Eq_Fn60085"><tt>Eq_Fn</tt></a> +</pre> + </td> + + <td> + <p>Equivalence functor type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="resize_policy4084493169" id= +"resize_policy4084493169">resize_policy</a> +</pre> + </td> + + <td> + <pre> +<a href="#Resize_Policy566860465"><tt>Resize_Policy</tt></a> +</pre> + </td> + + <td> + <p>Resize policy type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="store_hash280766104" id= +"store_hash280766104">store_hash</a> +</pre> + </td> + + <td> + <pre> +<a href="#Store_Hash218262104"><tt>Store_Hash</tt></a> +</pre> + </td> + + <td> + <p>Indicates whether a hash value is stored with each + entry.</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Public Methods</a></h2> + + <h3><a name="link6" id="link6">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~basic_hash_table + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Policy Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#hash_fn2015995"><tt>hash_fn</tt></a> & + get_hash_fn + () +</pre> + </td> + + <td> + <p>Access to the <a href= + "#hash_fn2015995"><tt>hash_fn</tt></a> object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>const</b> <a href="#hash_fn2015995"><tt>hash_fn</tt></a> & + get_hash_fn + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access to the <a href= + "#hash_fn2015995"><tt>hash_fn</tt></a> object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#eq_fn80245"><tt>eq_fn</tt></a> & + get_eq_fn + () +</pre> + </td> + + <td> + <p>Access to the <a href="#eq_fn80245"><tt>eq_fn</tt></a> + object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>const</b> <a href="#eq_fn80245"><tt>eq_fn</tt></a> & + get_eq_fn + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access to the <a href= + "#eq_fn80245"><tt>eq_fn</tt></a> object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#resize_policy4084493169"><tt>resize_policy</tt></a> & + get_resize_policy + () +</pre> + </td> + + <td> + <p>Access to the <a href= + "#resize_policy4084493169"><tt>resize_policy</tt></a> + object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>const</b> <a href= +"#resize_policy4084493169"><tt>resize_policy</tt></a> & + get_resize_policy + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access to the <a href= + "#resize_policy4084493169"><tt>resize_policy</tt></a> + object.</p> + </td> + </tr> + </table> + + <h2><a name="link8" id="link8">Private Methods</a></h2> + + <h3><a name="link9" id="link9">Resize Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <b>void</b> + do_resize + (size_type new_size) +</pre> + </td> + + <td> + <p>Resizes the container object to <span class= + "c1"><tt>new_size</tt></span>.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_tag.html new file mode 100644 index 000000000..9dc5e6d86 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>basic_hash_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>basic_hash_tag</tt> Interface</h1> + + <p>Basic hash data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="associative_container_tag.html"><span class= +"c2"><tt>associative_container_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_invalidation_guarantee.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_invalidation_guarantee.html new file mode 100644 index 000000000..d4a0df23f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_invalidation_guarantee.html @@ -0,0 +1,26 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>basic_invalidation_guarantee Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>basic_invalidation_guarantee</tt> Interface</h1> + + <p>Signifies a basic invalidation guarantee that any iterator, + pointer, or reference to a container object's mapped value type + is valid as long as the container is not modified.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree.html new file mode 100644 index 000000000..3811707fa --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree.html @@ -0,0 +1,660 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>basic_tree Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>basic_tree</tt> Interface</h1> + + <p>An abstract basic tree-like-based associative container.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Key2501" id="Key2501"><b>typename</b> Key</a> +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a> +</pre> + </td> + + <td> + <p>Mapped type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Tag278938" id="Tag278938"><b>class</b> Tag</a> +</pre> + </td> + + <td> + <p>Mapped-structure tag.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Node_Update841554648" id= +"Node_Update841554648"><b>class</b> Node_Update</a> +</pre> + </td> + + <td> + <p>Node updater.</p> + + <p>Restores node-invariants when invalidated.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Policy_Tl42017403" id= +"Policy_Tl42017403"><b>class</b> Policy_Tl</a> +</pre> + </td> + + <td> + <p>Policy typelist.</p> + + <p>Contains subclasses' policies.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator</a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td>-</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#Node_Update841554648"><tt>Node_Update</tt></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="container_base.html"><span class= +"c2"><tt>container_base</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Types and + Constants</a></h2> + + <h3><a name="link4" id="link4">Key-Type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_key_reference3185471705" id= +"const_key_reference3185471705">const_key_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href="container_base.html"><span class= +"c2"><tt>container_base</tt></span></a>::const_key_reference +</pre> + </td> + + <td> + <p>Const key reference type.</p> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="node_update2404554648" id= +"node_update2404554648">node_update</a> +</pre> + </td> + + <td> + <pre> +<a href="#Node_Update841554648"><tt>Node_Update</tt></a> +</pre> + </td> + + <td> + <p>Node updater type.</p> + </td> + </tr> + </table> + + <h3><a name="link6" id="link6">Iterator Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_iterator98626788" id= +"const_iterator98626788">const_iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href="container_base.html"><span class= +"c2"><tt>container_base</tt></span></a>::const_iterator +</pre> + </td> + + <td> + <p>Const range-type iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="iterator10418194" id="iterator10418194">iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href="container_base.html"><span class= +"c2"><tt>container_base</tt></span></a>::iterator +</pre> + </td> + + <td> + <p>Range-type iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_reverse_iterator4151293083" id= +"const_reverse_iterator4151293083">const_reverse_iterator</a> +</pre> + </td> + + <td> + <pre> +Const reverse range-type iterator. +</pre> + </td> + + <td> + <p>Const reverse range-type <a href= + "#iterator10418194"><tt>iterator</tt></a>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="reverse_iterator1896910345" id= +"reverse_iterator1896910345">reverse_iterator</a> +</pre> + </td> + + <td> + <pre> +Reverse range-type iterator.<br /> +If <a href="#Mapped318655"><tt>Mapped</tt></a> is <a href= +"null_mapped_type.html"><span class= +"c2"><tt>null_mapped_type</tt></span></a>, then this is synonymous to <a href="#const_reverse_iterator4151293083"><tt>const_reverse_iterator</tt></a> +</pre> + </td> + + <td> + <p>Reverse range-type <a href= + "#iterator10418194"><tt>iterator</tt></a>.</p> + </td> + </tr> + </table> + + <h2><a name="link7" id="link7">Public Methods</a></h2> + + <h3><a name="link8" id="link8">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~basic_tree + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + </table> + + <h3><a name="link9" id="link9">Policy Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#node_update2404554648"><tt>node_update</tt></a> & + get_node_update + () +</pre> + </td> + + <td> + <p>Access to the <a href= + "#node_update2404554648"><tt>node_update</tt></a> + object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>const</b> <a href= +"#node_update2404554648"><tt>node_update</tt></a> & + get_node_update + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access to the <a href= + "#node_update2404554648"><tt>node_update</tt></a> + object.</p> + </td> + </tr> + </table> + + <h3><a name="link10" id="link10">Find Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#iterator10418194"><tt>iterator</tt></a> + lower_bound + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) +</pre> + </td> + + <td> + <p>Returns an <a href= + "#iterator10418194"><tt>iterator</tt></a> corresponding + to the entry whose key is the smallest one at least as + large as <span class="c1"><tt>r_key</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#const_iterator98626788"><tt>const_iterator</tt></a> + lower_bound + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <tt><b>const</b></tt> <a href= + "#iterator10418194"><tt>iterator</tt></a> corresponding + to the entry whose key is the smallest one at least as + large as <span class="c1"><tt>r_key</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#iterator10418194"><tt>iterator</tt></a> + upper_bound + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) +</pre> + </td> + + <td> + <p>Returns an <a href= + "#iterator10418194"><tt>iterator</tt></a> corresponding + to the entry whose key is the smallest one larger than + <span class="c1"><tt>r_key</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#const_iterator98626788"><tt>const_iterator</tt></a> + upper_bound + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> + corresponding to the entry whose key is the smallest one + larger than <span class="c1"><tt>r_key</tt></span>.</p> + </td> + </tr> + </table> + + <h3><a name="link11" id="link11">Erase Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#iterator10418194"><tt>iterator</tt></a> + erase + (<a href="#iterator10418194"><tt>iterator</tt></a> it) +</pre> + </td> + + <td> + <p>Erases the value_type corresponding to the <a href= + "#iterator10418194"><tt>iterator</tt></a> <span class= + "c1"><tt>it</tt></span>. Returns the <a href= + "#iterator10418194"><tt>iterator</tt></a> corresponding + to the next value_type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#reverse_iterator1896910345"><tt>reverse_iterator</tt></a> + erase + (<a href= +"#reverse_iterator1896910345"><tt>reverse_iterator</tt></a> it) +</pre> + </td> + + <td> + <p>Erases the value_type corresponding to the <a href= + "#reverse_iterator1896910345"><tt>reverse_iterator</tt></a> + <span class="c1"><tt>it</tt></span>. Returns the <a href= + "#reverse_iterator1896910345"><tt>reverse_iterator</tt></a> + corresponding to the previous value_type.</p> + </td> + </tr> + </table> + + <h3><a name="link12" id="link12">Iteration Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#reverse_iterator1896910345"><tt>reverse_iterator</tt></a> + rbegin + () +</pre> + </td> + + <td> + <p>Returns a <a href= + "#reverse_iterator1896910345"><tt>reverse_iterator</tt></a> + corresponding to the last value_type in the + container.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href= +"#const_reverse_iterator4151293083"><tt>const_reverse_iterator</tt></a> + rbegin + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_reverse_iterator4151293083"><tt>const_reverse_iterator</tt></a> + corresponding to the last value_type in the + container.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#reverse_iterator1896910345"><tt>reverse_iterator</tt></a> + rend + () +</pre> + </td> + + <td> + <p>Returns a <a href= + "#reverse_iterator1896910345"><tt>reverse_iterator</tt></a> + corresponding to the just-before-first value_type in the + container.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href= +"#const_reverse_iterator4151293083"><tt>const_reverse_iterator</tt></a> + rend + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_reverse_iterator4151293083"><tt>const_reverse_iterator</tt></a> + corresponding to the just-before-first value_type in the + container.</p> + </td> + </tr> + </table> + + <h3><a name="link13" id="link13">Split and join + Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + join + (<span class= +"c2"><tt>basic_tree</tt></span> &other) +</pre> + </td> + + <td> + <p>Joins two trees. When this function returns, + <span class="c1"><tt>other</tt></span> will be + empty.</p> + + <p>When calling this method, <span class= + "c1"><tt>other</tt></span>'s keys must be all larger or + all smaller than this object's keys, and <span class= + "c1"><tt>other</tt></span>'s policies must be + equivalent to this object's policies.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + split + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key, + <span class= +"c2"><tt>basic_tree</tt></span> &other) +</pre> + </td> + + <td> + <p>Splits into two trees. When this function returns, + <span class="c1"><tt>other</tt></span> will contain + only keys larger than <span class= + "c1"><tt>r_key</tt></span>.</p> + + <p>When calling this method, <span class= + "c1"><tt>other</tt></span>'s policies must be + equivalent to this object's policies.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html new file mode 100644 index 000000000..5647f551e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html @@ -0,0 +1,383 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>tree::const_node_iterator + Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt><span class= + "c2"><tt>tree</tt></span>::const_node_iterator</tt> + Interface</h1> + + <p>Const node iterator.</p> + + <p>This is an &qout;iterator to an iterator&qout; - it + iterates over nodes, and de-referencing it returns one of the + tree's iterators</p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">Iterator Definitions</a></h3> + + <table class="c2" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="iterator_category2821876439" id= +"iterator_category2821876439">iterator_category</a> +</pre> + </td> + + <td> + <pre> +trivial_iterator_tag +</pre> + </td> + + <td> + <p>Category.</p> + + <p>This tag identifies that the iterator has none of the + STL's iterators' movement abilities.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="difference_type868028452" id= +"difference_type868028452">difference_type</a> +</pre> + </td> + + <td> + <pre class="c1"> +void +</pre> + </td> + + <td> + <p>Difference type.</p> + </td> + </tr> + </table> + + <h3><a name="link3" id="link3">Value-Type Definitions</a></h3> + + <p>Note that a node iterator's value type is actually a tree + iterator.</p> + + <table class="c2" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="value_type279018186" id= +"value_type279018186">value_type</a> +</pre> + </td> + + <td> + <pre> +<a href= +"container_base.html#const_iterator98626788"><span class="c2"><tt>container_base</tt></span>::const_iterator</a> +</pre> + </td> + + <td> + <p>Iterator's value type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="reference54418471" id="reference54418471">reference</a> +</pre> + </td> + + <td> + <pre> +<a href= +"container_base.html#const_iterator98626788"><span class="c2"><tt>container_base</tt></span>::const_iterator</a> +</pre> + </td> + + <td> + <p>Iterator's reference type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_reference495461441" id= +"const_reference495461441">const_reference</a> +</pre> + </td> + + <td> + <pre> +<a href= +"container_base.html#const_iterator98626788"><span class="c2"><tt>container_base</tt></span>::const_iterator</a> +</pre> + </td> + + <td> + <p>Iterator's const <a href= + "#reference54418471"><tt>reference</tt></a> type.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">Metadata Definitions</a></h3> + + <p>These are only defined if <a href= + "basic_tree.html#Node_Update841554648"><span class="c2"> + <tt>basic_tree</tt></span>::Node_Update</a> + is not <a href="null_tree_node_update.html"><span class= + "c2"><tt>null_tree_node_update</tt></span></a></p> + + <table class="c2" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_type2849297114" id= +"metadata_type2849297114">metadata_type</a> +</pre> + </td> + + <td> + <pre> +<tt><b>typename</b></tt> <a href= +"basic_tree.html#Node_Update841554648"><span class="c2"><tt>basic_tree</tt></span>::Node_Update</a><tt>::metadata_type</tt> +</pre> + </td> + + <td> + <p>Metadata type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_metadata_reference1108857465" id= +"const_metadata_reference1108857465">const_metadata_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> Allocator::<b>template</b> rebind< + <a href= +"#metadata_type2849297114"><tt>metadata_type</tt></a>>::other::<a href="#const_reference495461441"><tt>const_reference</tt></a> +</pre> + </td> + + <td> + <p>Const metadata <a href= + "#reference54418471"><tt>reference</tt></a> type.</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Public Methods</a></h2> + + <h3><a name="link6" id="link6">Constructors, Destructor, and + Related</a></h3> + + <table class="c2" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> + const_node_iterator + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Access Methods</a></h3> + + <table class="c2" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"#const_reference495461441"><tt>const_reference</tt></a> + <b>operator</b>* + () <b>const</b> +</pre> + </td> + + <td> + <p>Access.</p> + </td> + </tr> + </table> + + <h3><a name="link8" id="link8">Metadata Access Methods</a></h3> + + <p>These are only defined if <a href= + "basic_tree.html#Node_Update841554648"><span class="c2"> + <tt>basic_tree</tt></span>::Node_Update</a> + is not <a href="null_tree_node_update.html"><span class= + "c2"><tt>null_tree_node_update</tt></span></a></p> + + <table class="c2" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"#const_metadata_reference1108857465"><tt>const_metadata_reference</tt></a> + get_metadata + () <b>const</b> +</pre> + </td> + + <td> + <p>Metadata access.</p> + </td> + </tr> + </table> + + <h3><a name="link9" id="link9">Movement Methods</a></h3> + + <table class="c2" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <span class="c2"><tt>const_node_iterator</tt></span> + get_l_child + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns the const node iterator associated with the + left node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <span class="c2"><tt>const_node_iterator</tt></span> + get_r_child + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns the const node iterator associated with the + right node.</p> + </td> + </tr> + </table> + + <h3><a name="link10" id="link10">Comparison Methods</a></h3> + + <table class="c2" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + <b>operator</b>== + (<b>const</b> <span class= +"c2"><tt>const_node_iterator</tt></span> &other) <b>const</b> +</pre> + </td> + + <td> + <p>Compares to a different iterator object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + <b>operator</b>!= + (<b>const</b> <span class= +"c2"><tt>const_node_iterator</tt></span> &other) <b>const</b> +</pre> + </td> + + <td> + <p>Compares (negatively) to a different iterator + object.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_tag.html new file mode 100644 index 000000000..8eca2a818 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>basic_tree_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>basic_tree_tag</tt> Interface</h1> + + <p>Basic tree-like data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="associative_container_tag.html"><span class= +"c2"><tt>associative_container_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_heap_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_heap_tag.html new file mode 100644 index 000000000..47873b1cf --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_heap_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>binary_heap_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>binary_heap_tag</tt> Interface</h1> + + <p>Binary-heap (array-based) data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="priority_queue_tag.html"><span class= +"c2"><tt>priority_queue_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..07f0953a6 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_local.png Binary files differnew file mode 100644 index 000000000..76e02f134 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..b8a3b2371 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binomial_heap_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binomial_heap_tag.html new file mode 100644 index 000000000..fde6a913b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binomial_heap_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>binomial_heap_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>binomial_heap_tag</tt> Interface</h1> + + <p>Binomial-heap data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="priority_queue_tag.html"><span class= +"c2"><tt>priority_queue_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html new file mode 100644 index 000000000..a6b512b0d --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html @@ -0,0 +1,532 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>cc_hash_max_collision_check_resize_trigger + Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>cc_hash_max_collision_check_resize_trigger</tt> + Interface</h1> + + <p>A resize trigger policy based on collision checks. It keeps + the simulated load factor lower than some given load + factor.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="External_Load_Access1313998607" id= +"External_Load_Access1313998607"><b>bool</b> External_Load_Access </a> +</pre> + </td> + + <td> + <p>Specifies whether the load factor can be accessed + externally. The two options have different trade-offs in + terms of flexibility, genericity, and encapsulation.</p> + </td> + + <td><tt><b>false</b></tt></td> + </tr> + + <tr> + <td> + <pre> +<a name="Size_Type42920436" id= +"Size_Type42920436"><b>typename</b> Size_Type </a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + + <td>size_t</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#Size_Type42920436"><tt>Size_Type</tt></a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="external_load_access3976598639" id= +"external_load_access3976598639">external_load_access</a> +</pre> + </td> + + <td> + <pre> +<a href= +"#External_Load_Access1313998607"><tt>External_Load_Access</tt></a> +</pre> + </td> + + <td> + <p>Indicates whether loads can be accessed externally</p> + </td> + </tr> + </table> + + <h2><a name="link4" id="link4">Public Methods</a></h2> + + <h3><a name="link5" id="link5">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + cc_hash_max_collision_check_resize_trigger + (float load = 0.5) +</pre> + </td> + + <td> + <p>Default constructor, or constructor taking + <span class="c1"><tt>load</tt></span>, a load factor + which it will attempt to maintain.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class= +"c2"><tt>cc_hash_max_collision_check_resize_trigger</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h3><a name="link6" id="link6">Load Access Methods</a></h3> + + <p>These methods are only available if the external access + parameter is set.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> float + get_load + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns the current load.</p> + + <p>Calling this method will not compile when <a href= + "#External_Load_Access1313998607"><tt>External_Load_Access</tt></a> + == <tt><b>false</b></tt>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + set_load + (float load) +</pre> + </td> + + <td> + <p>Sets the <span class="c1"><tt>load</tt></span>; does + not resize the container.</p> + + <p>It is the responsibility of the user to pass an + appropriate <span class="c1"><tt>load</tt></span> to this + function. Calling this method will not compile when + <a href= + "#External_Load_Access1313998607"><tt>External_Load_Access</tt></a> + == <tt><b>false</b></tt>.</p> + </td> + </tr> + </table> + + <h2><a name="link7" id="link7">Protected Methods</a></h2> + + <h3><a name="link8" id="link8">Insert Search + Notifications.</a></h3> + + <p>Notifications called during an insert operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link9" id="link9">Find Search + Notifications.</a></h3> + + <p>Notifications called during a find operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link10" id="link10">Erase Search + Notifications.</a></h3> + + <p>Notifications called during an insert operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link11" id="link11">Content Change + Notifications</a></h3> + + <p>Notifications called when the content of the table changes + in a way that can affect the resize policy.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_inserted + (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries) +</pre> + </td> + + <td> + <p>Notifies an element was inserted.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erased + (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries) +</pre> + </td> + + <td> + <p>Notifies an element was erased.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_cleared + () +</pre> + </td> + + <td> + <p>Notifies the table was cleared.</p> + </td> + </tr> + </table> + + <h3><a name="link12" id="link12">Size Change + Notifications</a></h3> + + <p>Notifications called when the table changes size.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Notifies the table was resized as a result of this + object's signifying that a resize is needed.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_externally_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Notifies the table was resized externally.</p> + </td> + </tr> + </table> + + <h3><a name="link13" id="link13">Queries</a></h3> + + <p>Called to query whether/how to resize.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + is_resize_needed + () <b>const</b> +</pre> + </td> + + <td> + <p>Queries whether a resize is needed.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + is_grow_needed + (<a href= +"#size_type55424436"><tt>size_type</tt></a> size, <a href= +"#size_type55424436"><tt>size_type</tt></a> num_entries) <b>const</b> +</pre> + </td> + + <td> + <p>Queries whether a grow is needed.</p> + + <p>This method is called only if this object indicated is + needed.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..85b9eca4f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_local.png Binary files differnew file mode 100644 index 000000000..4f578c65b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..d1234aa11 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_gcc.png Binary files differnew file mode 100644 index 000000000..1db2cc0c6 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_local.png Binary files differnew file mode 100644 index 000000000..ca4db96f4 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_msvc.png Binary files differnew file mode 100644 index 000000000..0b51d9432 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_gcc.png Binary files differnew file mode 100644 index 000000000..6e4940381 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_local.png Binary files differnew file mode 100644 index 000000000..48fcf76c0 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_msvc.png Binary files differnew file mode 100644 index 000000000..39c96ad8d --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_table.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_table.html new file mode 100644 index 000000000..0557732a5 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_table.html @@ -0,0 +1,724 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>cc_hash_table Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>cc_hash_table</tt> Interface</h1> + + <p>A concrete collision-chaining hash-based associative + container.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Key2501" id="Key2501"><b>typename</b> Key</a> +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a> +</pre> + </td> + + <td> + <p>Mapped type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Hash_Fn1515835" id= +"Hash_Fn1515835"><b>class</b> Hash_Fn </a> +</pre> + </td> + + <td> + <p>Hash functor.</p> + </td> + + <td> + <pre> +__gnu_cxx::hash<<a href="#Key2501"><tt>Key</tt></a>> +</pre>if using gcc; + <pre> +stdext::hash_value<<a href="#Key2501"><tt>Key</tt></a>> +</pre>if using Visual C++ .net + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Eq_Fn60085" id="Eq_Fn60085"><b>class</b> Eq_Fn </a> +</pre> + </td> + + <td> + <p>Equivalence functor.</p> + </td> + + <td> + <pre> +std::equal_to<<a href="#Key2501"><tt>Key</tt></a>> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Comb_Hash_Fn320611039" id= +"Comb_Hash_Fn320611039"><b>class</b> Comb_Hash_Fn </a> +</pre> + </td> + + <td> + <p>Combining hash functor.</p> + + <p>If <a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a> is + not <a href="null_hash_fn.html"><span class= + "c2"><tt>null_hash_fn</tt></span></a>, then this is the + ranged-hash functor; otherwise, this is the range-hashing + functor.</p> + + <p>(See <a href= + "hash_based_containers.html#hash_policies">Design::Hash-Based + Containers::Hash Policies</a>.)</p> + </td> + + <td> + <pre> +<a href="direct_mask_range_hashing.html"><span class= +"c2"><tt>direct_mask_range_hashing</tt></span></a> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Resize_Policy566860465" id= +"Resize_Policy566860465"><b>class</b> Resize_Policy </a> +</pre> + </td> + + <td> + <p>Resize policy.</p> + </td> + + <td> + If <tt><a href= + "#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a></tt> + is <tt><a href= + "direct_mask_range_hashing.html"><span class= + "c2"><tt>direct_mask_range_hashing</tt></span></a></tt>, + then + <pre> +<a href="hash_standard_resize_policy.html"><span class= +"c2"><tt>hash_standard_resize_policy</tt></span></a>< + <a href="hash_exponential_size_policy.html"><span class= +"c2"><tt>hash_exponential_size_policy</tt></span></a>< + <b>typename</b> <a href= +"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type>, + <a href="hash_load_check_resize_trigger.html"><span class= +"c2"><tt>hash_load_check_resize_trigger</tt></span></a>< + <b>typename</b> <a href= +"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type>, + <b>false</b>, + <b>typename</b> <a href= +"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type> +</pre>otherwise, + <pre> +<a href="hash_standard_resize_policy.html"><span class= +"c2"><tt>hash_standard_resize_policy</tt></span></a>< + <a href="hash_exponential_size_policy.html"><span class= +"c2"><tt>hash_exponential_size_policy</tt></span></a>< + <b>typename</b> <a href= +"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type>, + <a href="hash_load_check_resize_trigger.html"><span class= +"c2"><tt>hash_load_check_resize_trigger</tt></span></a>< + <b>typename</b> <a href= +"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type>, + <b>false</b>, + <b>typename</b> <a href= +"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Store_Hash218262104" id= +"Store_Hash218262104"><b>bool</b> Store_Hash </a> +</pre> + </td> + + <td> + <p>Indicates whether the hash value will be stored along + with each key.</p> + + <p>If <tt><a href= + "#hash_fn2015995"><tt>hash_fn</tt></a></tt> is <a href= + "null_hash_fn.html"><span class= + "c2"><tt>null_hash_fn</tt></span></a>, then the container + will not compile if this value is + <tt><b>true</b></tt></p> + </td> + + <td> + <pre> +<tt><b>false</b></tt> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator </a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td> + <pre> +std::allocator<<b>char</b>> +</pre> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="basic_hash_table.html"><span class= +"c2"><tt>basic_hash_table</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Types and + Constants</a></h2> + + <h3><a name="link4" id="link4">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="hash_fn2015995" id="hash_fn2015995">hash_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a> +</pre> + </td> + + <td> + <p>Hash functor type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="eq_fn80245" id="eq_fn80245">eq_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Eq_Fn60085"><tt>Eq_Fn</tt></a> +</pre> + </td> + + <td> + <p>Equivalence functor type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="resize_policy4084493169" id= +"resize_policy4084493169">resize_policy</a> +</pre> + </td> + + <td> + <pre> +<a href="#Resize_Policy566860465"><tt>Resize_Policy</tt></a> +</pre> + </td> + + <td> + <p>Resize policy type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="comb_hash_fn1883611199" id= +"comb_hash_fn1883611199">comb_hash_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a> +</pre> + </td> + + <td> + <p>Combining hash functor type.</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Public Methods</a></h2> + + <h3><a name="link6" id="link6">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + cc_hash_table + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> + cc_hash_table + (<b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a> object of + the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + cc_hash_table + (<b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, and <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + cc_hash_table + (<b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn, + <b>const</b> <a href= +"#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> &r_comb_hash_fn) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object, and <span class= + "c1"><tt>r_comb_hash_fn</tt></span> will be copied by the + <a href= + "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> + object of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + cc_hash_table + (<b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn, + <b>const</b> <a href= +"#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> &r_comb_hash_fn, + <b>const</b> <a href= +"#resize_policy4084493169"><tt>resize_policy</tt></a> &r_resize_policy) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object, <span class= + "c1"><tt>r_comb_hash_fn</tt></span> will be copied by the + <a href= + "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> + object of the container object, and <span class= + "c1"><tt>r_resize_policy</tt></span> will be copied by + the <a href= + "#resize_policy4084493169"><tt>resize_policy</tt></a> + object of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + cc_hash_table + (It first_it, + It last_it) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of + value_types. The value_types between <span class= + "c1"><tt>first_it</tt></span> and <span class= + "c1"><tt>last_it</tt></span> will be inserted into the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + cc_hash_table + (It first_it, + It last_it, + <b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects. The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + cc_hash_table + (It first_it, + It last_it, + <b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, and <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + cc_hash_table + (It first_it, + It last_it, + <b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn, + <b>const</b> <a href= +"#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> &r_comb_hash_fn) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object, and <span class= + "c1"><tt>r_comb_hash_fn</tt></span> will be copied by the + <a href= + "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> + object of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + cc_hash_table + (It first_it, + It last_it, + <b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn, + <b>const</b> <a href= +"#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> &r_comb_hash_fn, + <b>const</b> <a href= +"#resize_policy4084493169"><tt>resize_policy</tt></a> &r_resize_policy) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object, <span class= + "c1"><tt>r_comb_hash_fn</tt></span> will be copied by the + <a href= + "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> + object of the container object, and <span class= + "c1"><tt>r_resize_policy</tt></span> will be copied by + the <a href= + "#resize_policy4084493169"><tt>resize_policy</tt></a> + object of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + cc_hash_table + (<b>const</b> <span class= +"c2"><tt>cc_hash_table</tt></span> &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~cc_hash_table + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<span class="c2"><tt>cc_hash_table</tt></span> & + <b>operator</b>= + (<b>const</b> <span class= +"c2"><tt>cc_hash_table</tt></span> &other) +</pre> + </td> + + <td> + <p>Assignment operator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class= +"c2"><tt>cc_hash_table</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Policy Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> & + get_comb_hash_fn + () +</pre> + </td> + + <td> + <p>Access to the <a href= + "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> + object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>const</b> <a href= +"#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> & + get_comb_hash_fn + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access to the <a href= + "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> + object.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_tag.html new file mode 100644 index 000000000..1923e20fb --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>cc_hash_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>cc_hash_tag</tt> Interface</h1> + + <p>Collision-chaining hash data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="basic_hash_tag.html"><span class= +"c2"><tt>basic_hash_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_gcc.png Binary files differnew file mode 100644 index 000000000..fde6b41bf --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_local.png Binary files differnew file mode 100644 index 000000000..2449e1de3 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_msvc.png Binary files differnew file mode 100644 index 000000000..11dca77fc --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/checked_by_tidy.gif b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/checked_by_tidy.gif Binary files differnew file mode 100644 index 000000000..47c2c4859 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/checked_by_tidy.gif diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/concepts.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/concepts.html new file mode 100644 index 000000000..9f6c22462 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/concepts.html @@ -0,0 +1,118 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Concepts</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Concepts</h1> + + <h2><a name="concepts_find_and_range_iterators" id= + "concepts_find_and_range_iterators">Point and Range Methods and + Iterators</a></h2> + + <p>A point-type iterator is an iterator that refers to a + specific element, <i>e.g.</i> as returned through an + associative-container's <tt>find</tt> method; a range-type + iterator is an iterator that is used to go over a sequence of + elements, <i>e.g.</i>, as returned by a container's + <tt>find</tt> method. A point-type method is a method that + returns a point-type iterator; a range-type method is a method + that returns a range-type iterator.</p> + + <p>For most containers, these types are synonymous; for + self-organizing containers, such as hash-based containers or + priority queues, these are inherently different (in any + implementation, including that of the STL), but in + <tt>pb_ds</tt> this is made explicit - they are distinct + types.</p> + + + <h2><a name="invalidation_guarantees" id= + "invalidation_guarantees">Invalidation Guarantees</a></h2> + + <p>If one manipulates a container object, then iterators + previously obtained from it can be invalidated. In some cases a + previously-obtained iterator cannot be de-referenced; in other + cases, the iterator's next or previous element might have + changed unpredictably. This corresponds exactly to the question + whether a point-type or range-type iterator (see previous + concept) is valid or not. In <tt>pb_ds</tt> one can query a + container (in compile time) what are its invalidation + guarantees.</p> + + <h2><a name="prm_sec" id="prm_sec">Primary and Secondary Keys + and Associative Containers</a></h2> + + <p>In <tt>pb_ds</tt> there are no associative containers which + allow multiple values with equivalent keys (such as the STL's + <tt>std::multimap</tt>, for example). Instead, one maps the + unique part of a key - the primary key, into an + associative-container of the (originally) non-unique parts of + the key - the secondary key. A primary associative-container is + an associative container of primary keys; a secondary + associative-container is an associative container of secondary + keys.</p> + + + <h2><a name="concepts_null_policies" id= + "concepts_null_policies">Null Policy Classes</a></h2> + + <p>Associative containers are typically parametrized by + various policies. For example, a hash-based associative + container is parametrized by a hash-functor, transforming each + key into an non-negative numerical type. Each such value is + then further mapped into a position within the table. The + mapping of a key into a position within the table is therefore + a two-step process.</p> + + <p>In some cases, instantiations are <i>redundant</i>. For + example, when the keys are integers, it is possible to use a + <i>redundant</i> hash policy, which transforms each key into + its value.</p> + + <p>In some other cases, these policies are <i>irrelevant</i>. + For example, a hash-based associative container might transform + keys into positions within a table by a different method than + the two-step method described above. In such a case, the hash + functor is simply irrelevant.</p> + + <p><tt>pb_ds</tt> uses special pre-defined "null policies" + classes for these cases. Some null policies in <tt>pb_ds</tt> + are:</p> + + <ol> + <li><a href= + "null_mapped_type.html"><tt>null_mapped_type</tt></a></li> + + <li><a href= + "null_tree_node_update.html"><tt>null_tree_node_update</tt></a></li> + + <li><a href= + "null_trie_node_update.html"><tt>null_trie_node_update</tt></a></li> + + <li><a href= + "null_hash_fn.html"><tt>null_hash_fn</tt></a></li> + + <li><a href= + "null_probe_fn.html"><tt>null_probe_fn</tt></a></li> + </ol> + + <p>A "set" in <tt>pb_ds</tt>, for example, is an associative + container with its <tt>Data_Parameter</tt> instantiated by + <a href="null_mapped_type.html"><tt>null_mapped_type</tt></a>. + <a href= + "tree_based_containers.html#invariants">Design::Tree-Based + Containers::Node Invariants</a> explains another case where a + null policy is needed.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/contact.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/contact.html new file mode 100644 index 000000000..3d506c975 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/contact.html @@ -0,0 +1,22 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Contact</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Contact</h1> + + <p>For anything relevant, please write to <a href= + "mailto:pbassoc@gmail.com">pbassoc@gmail.com</a></p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_base.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_base.html new file mode 100644 index 000000000..359e02459 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_base.html @@ -0,0 +1,1063 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>container_base Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>container_base</tt> Interface</h1> + + <p>An abstract basic associative container.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Key2501" id="Key2501"><b>typename</b> Key</a> +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a> +</pre> + </td> + + <td> + <p>Mapped type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Tag278938" id="Tag278938"><b>class</b> Tag</a> +</pre> + </td> + + <td> + <p>Data structure tag.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Policy_Tl42017403" id= +"Policy_Tl42017403"><b>class</b> Policy_Tl</a> +</pre> + </td> + + <td> + <p>Policy typelist.</p> + + <p>Contains subclasses' policies.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator</a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td>-</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Container + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::size_type +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="difference_type868028452" id= +"difference_type868028452">difference_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::difference_type +</pre> + </td> + + <td> + <p>Difference type.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">Categories</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="container_category1247973216" id= +"container_category1247973216">container_category</a> +</pre> + </td> + + <td> + <pre> +<a href="#Tag278938"><tt>Tag</tt></a> +</pre> + </td> + + <td> + <p>The underlying mapped-structure tag of the + container.</p> + + <p>This is one of:</p> + + <ol> + <li><a href="cc_hash_tag.html"><span class= + "c2"><tt>cc_hash_tag</tt></span></a></li> + + <li><a href="gp_hash_tag.html"><span class= + "c2"><tt>gp_hash_tag</tt></span></a></li> + + <li><a href="rb_tree_tag.html"><span class= + "c2"><tt>rb_tree_tag</tt></span></a></li> + + <li><a href="ov_tree_tag.html"><span class= + "c2"><tt>ov_tree_tag</tt></span></a></li> + + <li><a href="splay_tree_tag.html"><span class= + "c2"><tt>splay_tree_tag</tt></span></a></li> + + <li><a href="pat_trie_tag.html"><span class= + "c2"><tt>pat_trie_tag</tt></span></a></li> + + <li><a href="list_update_tag.html"><span class= + "c2"><tt>list_update_tag</tt></span></a></li> + </ol> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="allocator48440069" id="allocator48440069">allocator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Allocator35940069"><tt>Allocator</tt></a> +</pre> + </td> + + <td> + <p><a href="#Allocator35940069"><tt>Allocator</tt></a> + type.</p> + </td> + </tr> + </table> + + <h3><a name="link6" id="link6">Key-Type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="key_type10393186" id="key_type10393186">key_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href="#Key2501"><tt>Key</tt></a>>::other::value_type +</pre> + </td> + + <td> + <p><a href="#Key2501"><tt>Key</tt></a> type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="key_reference2411522399" id= +"key_reference2411522399">key_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#key_type10393186"><tt>key_type</tt></a>>::other::reference +</pre> + </td> + + <td> + <p><a href="#Key2501"><tt>Key</tt></a> reference + type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_key_reference3185471705" id= +"const_key_reference3185471705">const_key_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#key_type10393186"><tt>key_type</tt></a>>::other::const_reference +</pre> + </td> + + <td> + <p>Const key reference type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="key_pointer1299054769" id= +"key_pointer1299054769">key_pointer</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#key_type10393186"><tt>key_type</tt></a>>::other::pointer +</pre> + </td> + + <td> + <p><a href="#Key2501"><tt>Key</tt></a> pointer type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_key_pointer3735194427" id= +"const_key_pointer3735194427">const_key_pointer</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#key_type10393186"><tt>key_type</tt></a>>::other::const_pointer +</pre> + </td> + + <td> + <p>Const key pointer type.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Mapped-Type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="mapped_type1308374436" id= +"mapped_type1308374436">mapped_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#Mapped318655"><tt>Mapped</tt></a> +</pre> + </td> + + <td> + <p><a href="#Mapped318655"><tt>Mapped</tt></a> type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="mapped_reference4153801225" id= +"mapped_reference4153801225">mapped_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#mapped_type1308374436"><tt>mapped_type</tt></a>>::other::reference +</pre> + </td> + + <td> + <p><a href="#Mapped318655"><tt>Mapped</tt></a> reference + type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_mapped_reference2113216667" id= +"const_mapped_reference2113216667">const_mapped_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#mapped_type1308374436"><tt>mapped_type</tt></a>>::other::const_reference +</pre> + </td> + + <td> + <p>Const mapped reference type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="mapped_pointer337953771" id= +"mapped_pointer337953771">mapped_pointer</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#mapped_type1308374436"><tt>mapped_type</tt></a>>::other::pointer +</pre> + </td> + + <td> + <p><a href="#Mapped318655"><tt>Mapped</tt></a> pointer + type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_mapped_pointer4207700301" id= +"const_mapped_pointer4207700301">const_mapped_pointer</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#mapped_type1308374436"><tt>mapped_type</tt></a>>::other::const_pointer +</pre> + </td> + + <td> + <p>Const mapped pointer type.</p> + </td> + </tr> + </table> + + <h3><a name="link8" id="link8">Value-Type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="value_type279018186" id= +"value_type279018186">value_type</a> +</pre> + </td> + + <td> + <pre> +<br /> +If <a href="#Mapped318655"><tt>Mapped</tt></a> is <a href= +"null_mapped_type.html"><span class= +"c2"><tt>null_mapped_type</tt></span></a>, then <a href= +"#Key2501"><tt>Key</tt></a><br /> +Otherwise, <a href="#Mapped318655"><tt>Mapped</tt></a> +</pre> + </td> + + <td> + <p>Value type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="reference54418471" id="reference54418471">reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#value_type279018186"><tt>value_type</tt></a>>::other::reference +</pre> + </td> + + <td> + <p>Value reference type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_reference495461441" id= +"const_reference495461441">const_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#value_type279018186"><tt>value_type</tt></a>>::other::const_reference +</pre> + </td> + + <td> + <p>Const value <a href= + "#reference54418471"><tt>reference</tt></a> type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="pointer2179769" id="pointer2179769">pointer</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#value_type279018186"><tt>value_type</tt></a>>::other::pointer +</pre> + </td> + + <td> + <p>Value pointer type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_pointer878814947" id= +"const_pointer878814947">const_pointer</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#value_type279018186"><tt>value_type</tt></a>>::other::const_pointer +</pre> + </td> + + <td> + <p>Const Value <a href= + "#pointer2179769"><tt>pointer</tt></a> type.</p> + </td> + </tr> + </table> + + <h3><a name="link9" id="link9">Iterator Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_point_iterator2364676009" id= +"const_point_iterator2364676009">const_point_iterator</a> +</pre> + </td> + + <td> + <pre> +Const point-type iterator. +</pre> + </td> + + <td> + <p>Const point-type iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="point_iterator2789896775" id= +"point_iterator2789896775">point_iterator</a> +</pre> + </td> + + <td> + <pre> +<br /> +Point-type iterator.<br /> +If <a href="#Mapped318655"><tt>Mapped</tt></a> is <a href= +"null_mapped_type.html"><span class= +"c2"><tt>null_mapped_type</tt></span></a>, then this is synonymous to <a href="#const_point_iterator2364676009"><tt>const_point_iterator</tt></a> +</pre> + </td> + + <td> + <p>Point-type iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_iterator98626788" id= +"const_iterator98626788">const_iterator</a> +</pre> + </td> + + <td> + <pre> +Const range-type iterator. +</pre> + </td> + + <td> + <p>Const range-type iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="iterator10418194" id="iterator10418194">iterator</a> +</pre> + </td> + + <td> + <pre> +<br /> +Range-type iterator.<br /> +If <a href="#Mapped318655"><tt>Mapped</tt></a> is <a href= +"null_mapped_type.html"><span class= +"c2"><tt>null_mapped_type</tt></span></a>, then this is synonymous to <a href="#const_iterator98626788"><tt>const_iterator</tt></a> +</pre> + </td> + + <td> + <p>Range-type iterator.</p> + </td> + </tr> + </table> + + <h2><a name="link10" id="link10">Public Methods</a></h2> + + <h3><a name="link11" id="link11">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~container_base + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + </table> + + <h3><a name="link12" id="link12">Information Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + size + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns the number of distinct <a href= + "#value_type279018186"><tt>value_type</tt></a> objects + the container object is storing.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + max_size + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns an upper bound on the number of distinct + <a href="#value_type279018186"><tt>value_type</tt></a> + objects this container can store.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + empty + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns whether the container object is not storing + any <a href= + "#value_type279018186"><tt>value_type</tt></a> + objects.</p> + </td> + </tr> + </table> + + <h3><a name="link13" id="link13">Insert Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +std::pair<<a href= +"#point_iterator2789896775"><tt>point_iterator</tt></a>, <b>bool</b>> + insert + (<a href= +"#const_reference495461441"><tt>const_reference</tt></a> r_val) +</pre> + </td> + + <td> + <p>Inserts a <a href= + "#value_type279018186"><tt>value_type</tt></a> object. If + no <a href="#value_type279018186"><tt>value_type</tt></a> + with <span class="c1"><tt>r_val</tt></span>'s key was in + the container object, inserts and returns (<a href= + "#point_iterator2789896775"><tt>point_iterator</tt></a> + object associated with <span class= + "c1"><tt>r_val</tt></span>, <tt><b>true</b></tt>); + otherwise just returns (<a href= + "#point_iterator2789896775"><tt>point_iterator</tt></a> + object associated with <span class= + "c1"><tt>r_val</tt></span>'s key, + <tt><b>false</b></tt>).</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#mapped_reference4153801225"><tt>mapped_reference</tt></a> + <b>operator</b>[] + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) +</pre> + </td> + + <td> + <p>Subscript operator.</p> + </td> + </tr> + </table> + + <h3><a name="link14" id="link14">Find Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#point_iterator2789896775"><tt>point_iterator</tt></a> + find + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) +</pre> + </td> + + <td> + <p>Returns the <a href= + "#point_iterator2789896775"><tt>point_iterator</tt></a> + corresponding to the <a href= + "#value_type279018186"><tt>value_type</tt></a> with + <span class="c1"><tt>r_key</tt></span> as its key, or the + <a href= + "#point_iterator2789896775"><tt>point_iterator</tt></a> + corresponding to the just-after-last entry if no such + <a href= + "#value_type279018186"><tt>value_type</tt></a>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href= +"#const_point_iterator2364676009"><tt>const_point_iterator</tt></a> + find + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b> +</pre> + </td> + + <td> + <p>Returns the <a href= + "#const_point_iterator2364676009"><tt>const_point_iterator</tt></a> + corresponding to the <a href= + "#value_type279018186"><tt>value_type</tt></a> with + <span class="c1"><tt>r_key</tt></span> as its key, or the + <a href= + "#const_point_iterator2364676009"><tt>const_point_iterator</tt></a> + corresponding to the just-after-last entry if no such + <a href= + "#value_type279018186"><tt>value_type</tt></a>.</p> + </td> + </tr> + </table> + + <h3><a name="link15" id="link15">Erase Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>bool</b> + erase + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) +</pre> + </td> + + <td> + <p>Erases the <a href= + "#value_type279018186"><tt>value_type</tt></a> associated + with <span class="c1"><tt>r_key</tt></span>. returns + <tt><b>false</b></tt> iff <span class= + "c1"><tt>r_key</tt></span> was not contained.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> Pred> +<a href="#size_type55424436"><tt>size_type</tt></a> + erase_if + (Pred prd) +</pre> + </td> + + <td> + <p>Erases any <a href= + "#value_type279018186"><tt>value_type</tt></a> satisfying + the predicate <span class="c1"><tt>prd</tt></span> (this + is transactional, either all matching <a href= + "#value_type279018186"><tt>value_type</tt></a>s are + erased, or, if an exception is thrown (for types whose + erase can throw an exception) none); returns the number + of <a href= + "#value_type279018186"><tt>value_type</tt></a>s + erased.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + clear + () +</pre> + </td> + + <td> + <p>Clears the container object.</p> + </td> + </tr> + </table> + + <h3><a name="link16" id="link16">Iteration Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#iterator10418194"><tt>iterator</tt></a> + begin + () +</pre> + </td> + + <td> + <p>Returns an <a href= + "#iterator10418194"><tt>iterator</tt></a> corresponding + to the first <a href= + "#value_type279018186"><tt>value_type</tt></a> in the + container.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#const_iterator98626788"><tt>const_iterator</tt></a> + begin + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> + corresponding to the first <a href= + "#value_type279018186"><tt>value_type</tt></a> in the + container.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#iterator10418194"><tt>iterator</tt></a> + end + () +</pre> + </td> + + <td> + <p>Returns an <a href= + "#iterator10418194"><tt>iterator</tt></a> corresponding + to the just-after-last <a href= + "#value_type279018186"><tt>value_type</tt></a> in the + container.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#const_iterator98626788"><tt>const_iterator</tt></a> + end + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> + corresponding to the just-after-last <a href= + "#value_type279018186"><tt>value_type</tt></a> in the + container.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.png Binary files differnew file mode 100644 index 000000000..52553278c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.svg b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.svg new file mode 100644 index 000000000..3b5a98189 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.svg @@ -0,0 +1,418 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> +<svg + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://web.resource.org/cc/" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="11in" + height="8.5in" + id="svg2" + sodipodi:version="0.32" + inkscape:version="0.43" + version="1.0" + sodipodi:docbase="/mnt/share/src/policy_based_data_structures/current/pb_ds/doc" + sodipodi:docname="container_cd.svg" + inkscape:export-filename="/mnt/share/src/policy_based_data_structures/current/pb_ds/doc/container_cd.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90"> + <defs + id="defs4"> + <marker + inkscape:stockid="Arrow1Mstart" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Mstart" + style="overflow:visible"> + <path + id="path3311" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none" + transform="scale(0.4)" /> + </marker> + <marker + inkscape:stockid="Arrow2Sstart" + orient="auto" + refY="0" + refX="0" + id="Arrow2Sstart" + style="overflow:visible"> + <path + id="path3319" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(0.3,0,0,0.3,-1.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Sstart" + orient="auto" + refY="0" + refX="0" + id="Arrow1Sstart" + style="overflow:visible"> + <path + id="path3337" + d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none" + transform="scale(0.2,0.2)" /> + </marker> + <marker + inkscape:stockid="Arrow2Send" + orient="auto" + refY="0" + refX="0" + id="Arrow2Send" + style="overflow:visible"> + <path + id="path3316" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(-0.3,0,0,-0.3,1.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend" + style="overflow:visible"> + <path + id="path3322" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(-0.6,0,0,-0.6,3,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Lend" + style="overflow:visible"> + <path + id="path3346" + d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none" + transform="scale(-0.8,-0.8)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lstart" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lstart" + style="overflow:visible"> + <path + id="path3331" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(1.1,0,0,1.1,-5.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lend" + style="overflow:visible"> + <path + id="path3328" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(-1.1,0,0,-1.1,5.5,0)" /> + </marker> + </defs> + <sodipodi:namedview + id="base" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="2" + inkscape:cx="396.81316" + inkscape:cy="280" + inkscape:document-units="in" + inkscape:current-layer="layer1" + showguides="true" + inkscape:guide-bbox="true" + inkscape:window-width="1278" + inkscape:window-height="973" + inkscape:window-x="0" + inkscape:window-y="0" + gridtolerance="0.125in" + guidetolerance="0.125in"> + <sodipodi:guide + orientation="horizontal" + position="629" + id="guide1307" /> + <sodipodi:guide + orientation="horizontal" + position="449" + id="guide1309" /> + <sodipodi:guide + orientation="horizontal" + position="269" + id="guide1311" /> + <sodipodi:guide + orientation="vertical" + position="496" + id="guide1313" /> + <sodipodi:guide + orientation="vertical" + position="361" + id="guide1315" /> + <sodipodi:guide + orientation="vertical" + position="226" + id="guide1317" /> + <sodipodi:guide + orientation="vertical" + position="631" + id="guide1319" /> + <sodipodi:guide + orientation="vertical" + position="766" + id="guide1321" /> + <sodipodi:guide + orientation="vertical" + position="91" + id="guide1345" /> + <sodipodi:guide + orientation="vertical" + position="901" + id="guide1347" /> + <sodipodi:guide + orientation="horizontal" + position="539" + id="guide3390" /> + <sodipodi:guide + orientation="horizontal" + position="359" + id="guide3392" /> + <sodipodi:guide + orientation="vertical" + position="280.5" + id="guide3324" /> + <sodipodi:guide + orientation="vertical" + position="172" + id="guide3326" /> + <sodipodi:guide + orientation="vertical" + position="388" + id="guide3328" /> + <sodipodi:guide + orientation="vertical" + position="711.5" + id="guide3340" /> + </sodipodi:namedview> + <metadata + id="metadata7"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:creator> + <cc:Agent> + <dc:title>Benjamin Kosnik</dc:title> + </cc:Agent> + </dc:creator> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1"> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect1425" + width="141.64481" + height="23.200001" + x="209.57762" + y="382.56177" /> + <rect + y="382.56177" + x="425.57761" + height="23.200001" + width="141.64481" + id="rect3376" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3378" + width="141.64481" + height="23.200001" + x="640.77765" + y="382.56177" /> + <text + sodipodi:linespacing="100%" + id="use1329" + y="397.09772" + x="497.20001" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1703" + x="497.20001" + y="397.09772">list_update</tspan><tspan + sodipodi:role="line" + id="tspan1705" + x="497.20001" + y="406.69772" /></text> + <text + xml:space="preserve" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="712.40002" + y="397.09772" + id="use1337" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1707" + x="712.40002" + y="397.09772">basic_hash_table</tspan></text> + <text + xml:space="preserve" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="282" + y="397.09772" + id="text1339" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1701" + x="282" + y="397.09772">basic_tree</tspan></text> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3418" + width="141.64481" + height="23.200001" + x="101.57762" + y="472.5618" /> + <rect + y="472.5618" + x="317.57761" + height="23.200001" + width="141.64481" + id="rect3420" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3422" + width="141.64481" + height="23.200001" + x="533.57764" + y="472.5618" /> + <rect + y="472.5618" + x="748.77765" + height="23.200001" + width="141.64481" + id="rect3424" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <text + xml:space="preserve" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="171.20001" + y="486.29773" + id="text3394" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1715" + x="171.20001" + y="486.29773">tree</tspan><tspan + sodipodi:role="line" + id="tspan1717" + x="171.20001" + y="495.89773" /></text> + <text + sodipodi:linespacing="100%" + id="text3400" + y="486.29773" + x="386.39999" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1709" + x="386.39999" + y="486.29773">trie</tspan><tspan + sodipodi:role="line" + id="tspan1711" + x="386.39999" + y="495.89773" /></text> + <text + sodipodi:linespacing="100%" + id="text3406" + y="486.29773" + x="601.20001" + style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1713" + x="601.20001" + y="486.29773">cc_hash_table</tspan></text> + <text + xml:space="preserve" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="818" + y="486.29773" + id="text3412" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1719" + x="818" + y="486.29773">gp_hash_table</tspan></text> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3380" + width="141.64481" + height="23.200001" + x="425.57764" + y="292.56177" /> + <text + xml:space="preserve" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="497.20001" + y="307.09772" + id="text1323" + sodipodi:linespacing="100%" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90" + inkscape:export-filename="/mnt/share/src/policy_based_data_structures/pb_ds_images/container_diagram.png"><tspan + sodipodi:role="line" + id="tspan1369" + x="497.20001" + y="307.09772">container_base</tspan></text> + <path + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:0.97031623px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="M 170.97058,472.5 L 170.97058,451 L 387.51871,450 L 387.51871,472.5" + id="path2244" /> + <path + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="M 280.5,450.53297 L 280.5,410.62445" + id="path3332" /> + <path + id="path3353" + d="M 601.47058,472.5 L 601.47058,451 L 818.01871,450 L 818.01871,472.5" + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:0.97031623px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /> + <path + id="path3355" + d="M 711,450.53297 L 711,410.62445" + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <path + id="path3344" + d="M 281.18218,383.28102 L 281.18218,361.78102 L 711.79281,360.78102 L 711.79281,383.28102" + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.3682909px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /> + <path + id="path3347" + d="M 497.75146,383.49616 L 497.75146,322.77107" + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + </g> +</svg> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_tag.html new file mode 100644 index 000000000..de187a94d --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_tag.html @@ -0,0 +1,24 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>container _tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>container _tag</tt> Interface</h1> + + <p>Basic data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/counter_lu_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/counter_lu_policy.html new file mode 100644 index 000000000..d9d5112c0 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/counter_lu_policy.html @@ -0,0 +1,259 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>counter_lu_policy Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>counter_lu_policy</tt> Interface</h1> + + <p>A list-update policy that moves elements to the front of the + list based on the counter algorithm.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/list_update_policy.hpp"><tt>list_update_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Max_Count39887466" id= +"Max_Count39887466">size_t Max_Count </a> +</pre> + </td> + + <td> + <p>Maximum count.</p> + + <p>When some element is accessed this number of times, it + will be moved to the front of the list.</p> + </td> + + <td>5</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator </a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + + <p>This is used only for definitions, e.g., the size + type.</p> + </td> + + <td> + <pre> +std::allocator<<b>char</b>> +</pre> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="allocator48440069" id="allocator48440069">allocator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Allocator35940069"><tt>Allocator</tt></a> +</pre> + </td> + + <td> + <p><a href="#Allocator35940069"><tt>Allocator</tt></a> + type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="max_count52407466" id="max_count52407466">max_count</a> +</pre> + </td> + + <td> + <pre> +<a href="#Max_Count39887466"><tt>Max_Count</tt></a> +} +</pre> + </td> + + <td> + <p>Maximum count.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::size_type +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Metadata-Type + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_type2849297114" id= +"metadata_type2849297114">metadata_type</a> +</pre> + </td> + + <td> + <pre> +Some class containing a counter. +</pre> + </td> + + <td> + <p>Metadata on which this functor operates.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_reference583863863" id= +"metadata_reference583863863">metadata_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind< + <a href= +"#metadata_type2849297114"><tt>metadata_type</tt></a>>::other::reference +</pre> + </td> + + <td> + <p>Reference to metadata on which this functor + operates.</p> + </td> + </tr> + </table> + + <h2><a name="link6" id="link6">Public Methods</a></h2> + + <h3><a name="link7" id="link7">Metadata Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#metadata_type2849297114"><tt>metadata_type</tt></a> + <b>operator</b>() + () <b>const</b> +</pre> + </td> + + <td> + <p>Creates a metadata object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>bool</b> + <b>operator</b>() + (<a href= +"#metadata_reference583863863"><tt>metadata_reference</tt></a> r_metadata) <b>const</b> +</pre> + </td> + + <td> + <p>Decides whether a metadata object should be moved to + the front of the list.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/design.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/design.html new file mode 100644 index 000000000..e83bd4dd2 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/design.html @@ -0,0 +1,96 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Design</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Design</h1> + + <p>The <tt>pb_ds</tt> namespace contains:</p> + + <ol> + <li>Exception classes (see <a href= + "interface.html#exceptions_common">Interface::Exceptions::Common</a>)</li> + + <li>Invalidation-guarantee tags (see <a href= + "ds_gen.html#inv_guar">Design::Invalidation Guarantees</a> + and <a href= + "interface.html#ds_inv_tag">Interface::Data-Structure Tags + and Traits::Invalidation-Guarantee Tags</a>).</li> + + <li>Associative Containers (see <a href= + "tree_based_containers.html">Design::Associative + Containers::Tree-Based Containers</a>, <a href= + "trie_based_containers.html">Design::Associative + Containers::Trie-Based Containers</a>, <a href= + "hash_based_containers.html">Design::Associative + Containers::Hash-Based Containers</a>, and <a href= + "lu_based_containers.html">Design::Associative + Containers::List-Based Containers</a>, and <a href= + "interface.html#containers_assoc">Interface::Containers::Associative + Containers</a>).</li> + + <li>Associative Container tags and traits + (see <a href="ds_gen.html">Design::Associative + Containers::Data-Structure Genericity</a>, <a href= + "interface.html#ds_ts_assoc">Interface::Data-Structure Tags + and Traits::Data-Structure Tags::Associative-Containers</a>, + and <a href= + "interface.html#container_traits">Interface::Data-Structure Tags and + Traits::Data-Structure + Traits::Associative-Containers</a>).</li> + + <li>Associative Container policies (see + <a href="tree_based_containers.html">Design::Associative + Containers::Tree-Based Containers</a>, <a href= + "trie_based_containers.html">Design::Associative + Containers::Trie-Based Containers</a>, <a href= + "hash_based_containers.html">Design::Associative + Containers::Hash-Based Containers</a>, and <a href= + "lu_based_containers.html">Design::Associative + Containers::List-Based Containers</a>, and <a href= + "interface.html#ds_policy_classes">Interface::Container + Policy Classes</a>).</li> + + + <li>Mapped types for setting the mapping semantics of + associative containers (see <a href= + "tutorial.html#assoc_ms">Tutorial::Associative + Containers::Associative Containers Others than Maps</a> and + <a href="interface.html#ds_pol">Interface::Mapped-Type + Policies</a>).</li> + + + <li>Priority Queues (see <a href="pq_design.html">Design::Priority + Queues</a> and <a href= + "interface.html#containers_pq">Interface::Containers::Priority + Queues</a>).</li> + + <li>Priority Queue tags and traits + (see <a href="pq_design.html#pq_traits">Design::Priority + Queues::Traits</a>, <a href= + "interface.html#ds_ts_pq">Interface::Data-Structure Tags and + Traits::Data-Structure Tags::Priority Queues</a>, and + <a href="interface.html#container_traits">Interface::Data-Structure + Tags and Traits::Data-Structure Traits::Priority + Queues</a>).</li> + </ol> + + + <p><a href="assoc_design.html">Associative-Container Design</a> + describes associative-container design.</p> + + <p><a href="pq_design.html">Priority-Queue Design</a> describes + priority-queue design.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/different_underlying_dss.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/different_underlying_dss.png Binary files differnew file mode 100644 index 000000000..adee12636 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/different_underlying_dss.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mask_range_hashing.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mask_range_hashing.html new file mode 100644 index 000000000..19f8621c2 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mask_range_hashing.html @@ -0,0 +1,167 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>direct_mask_range_hashing Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>direct_mask_range_hashing</tt> Interface</h1> + + <p>A mask range-hashing class (uses a bit-mask).</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Size_Type42920436" id= +"Size_Type42920436"><b>typename</b> Size_Type </a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + + <td>size_t</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#Size_Type42920436"><tt>Size_Type</tt></a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link4" id="link4">Public Methods</a></h2> + + <h3><a name="link5" id="link5">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class= +"c2"><tt>direct_mask_range_hashing</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h2><a name="link6" id="link6">Protected Methods</a></h2> + + <h3><a name="link7" id="link7">Notification Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> size) +</pre> + </td> + + <td> + <p>Notifies the policy object that the container's size + has changed to <span class="c1"><tt>size</tt></span>.</p> + </td> + </tr> + </table> + + <h3><a name="link8" id="link8">Operators.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + <b>operator</b>() + (<a href= +"#size_type55424436"><tt>size_type</tt></a> hash) <b>const</b> +</pre> + </td> + + <td> + <p>Transforms the hash value <span class= + "c1"><tt>hash</tt></span> into a ranged-hash value (using + a bit-mask).</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mod_range_hashing.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mod_range_hashing.html new file mode 100644 index 000000000..f3f9295d4 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mod_range_hashing.html @@ -0,0 +1,144 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>direct_mod_range_hashing Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>direct_mod_range_hashing</tt> Interface</h1> + + <p>A mod range-hashing class (uses the modulo function).</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Size_Type42920436" id= +"Size_Type42920436"><b>typename</b> Size_Type </a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + + <td>size_t</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#Size_Type42920436"><tt>Size_Type</tt></a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link4" id="link4">Public Methods</a></h2> + + <h3><a name="link5" id="link5">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class= +"c2"><tt>direct_mod_range_hashing</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h2><a name="link6" id="link6">Protected Methods</a></h2> + + <h3><a name="link7" id="link7">Notification Methods</a></h3> + + <h3><a name="link8" id="link8">Operators.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + <b>operator</b>() + (<a href= +"#size_type55424436"><tt>size_type</tt></a> hash) <b>const</b> +</pre> + </td> + + <td> + <p>Transforms the hash value <span class= + "c1"><tt>hash</tt></span> into a ranged-hash value (using + a modulo operation).</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/disclaimer.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/disclaimer.html new file mode 100644 index 000000000..681af4edf --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/disclaimer.html @@ -0,0 +1,34 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>What, me worry?</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h2>Disclaimer and Copyright</h2> + + <p>Revised 16 February, 2004</p>© Copyright Ami Tavory and + Vladimir Dreizin, IBM-HRL, 2004, and Benjamin Kosnik, Red Hat, + 2004. + + <p>Permission to use, copy, modify, sell, and distribute this + software is hereby granted without fee, provided that the above + copyright notice appears in all copies, and that both that + copyright notice and this permission notice appear in + supporting documentation.</p> + + <p>None of the above authors, nor IBM Haifa Research + Laboratories, Red Hat, or both, make any representation about + the suitability of this software for any purpose. It is + provided "as is" without express or implied warranty.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ds_gen.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ds_gen.html new file mode 100644 index 000000000..ec99c4d5f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ds_gen.html @@ -0,0 +1,344 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Data-Structure Genericity</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Data-Structure Genericity</h1> + + <h2><a name="problem" id="problem">The Basic Problem</a></h2> + + <p>The design attempts to address the following problem. When + writing a function manipulating a generic container object, + what is the behavior of the object? <i>E.g.</i>, suppose one + writes</p> + <pre> +<b>template</b><<b>typename</b> Cntnr> +<b>void</b> +some_op_sequence(Cntnr &r_container) +{ + ... +} +</pre>then one needs to address the following questions in the body +of <tt>some_op_sequence</tt>: + + <ol> + <li>Which types and methods does <tt>Cntnr</tt> support? + Containers based on hash tables can be queries for the + hash-functor type and object; this is meaningless for + tree-based containers. Containers based on trees can be + split, joined, or can erase iterators and return the + following iterator; this cannot be done by hash-based + containers.</li> + + <li>What are the guarantees of <tt>Cntnr</tt>? A container + based on a probing hash-table invalidates all iterators when + it is modified; this is not the case for containers based on + node-based trees. Containers based on a node-based tree can + be split or joined without exceptions; this is not the case + for containers based on vector-based trees.</li> + + <li>How does the container maintain its elements? Tree-based + and Trie-based containers store elements by key order; + others, typically, do not. A container based on a splay trees + or lists with update policies "cache" "frequently accessed" + elements; containers based on most other underlying + data structures do not.</li> + </ol> + + <p>The remainder of this section deals with these issues.</p> + + <h2><a name="ds_hierarchy" id="ds_hierarchy">Container + Hierarchy</a></h2> + + <p>Figure <a href="#cd">Container class hierarchy</a> shows the + container hierarchy.</p> + + <h6 class="c1"><a name="cd" id="cd"><img src="container_cd.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Container class hierarchy.</h6> + + <ol> + <li><a href= + "container_base.html"><tt>container_base</tt></a> is an + abstract base class for associative containers.</li> + + <li>Tree-Like-Based Associative-Containers: + + <ol> + <li><a href= + "basic_tree.html"><tt>basic_tree</tt></a> + is an abstract base class for tree-like-based + associative-containers</li> + + <li><a href= + "tree.html"><tt>tree</tt></a> + is a concrete base class for tree-based + associative-containers</li> + + <li><a href= + "trie.html"><tt>trie</tt></a> + is a concrete base class trie-based + associative-containers</li> + </ol> + </li> + + <li>Hash-Based Associative-Containers: + + <ol> + <li><a href= + "basic_hash_table.html"><tt>basic_hash_table</tt></a> + is an abstract base class for hash-based + associative-containers</li> + + <li><a href= + "cc_hash_table.html"><tt>cc_hash_table</tt></a> + is a concrete collision-chaining hash-based + associative-containers</li> + + <li><a href= + "gp_hash_table.html"><tt>gp_hash_table</tt></a> + is a concrete (general) probing hash-based + associative-containers</li> + </ol> + </li> + + <li>List-Based Associative-Containers: + + <ol> + <li><a href= + "list_update.html"><tt>list_update</tt></a> - + list-based update-policy associative container</li> + </ol> + </li> + </ol> + + <p>The hierarchy is composed naturally so that commonality is + captured by base classes. Thus <tt><b>operator[]</b></tt> is + defined <a href= + "container_base.html"><tt>container_base</tt></a>, since + all containers support it. Conversely <tt>split</tt> is defined + in <a href= + "basic_tree.html"><tt>basic_tree</tt></a>, + since only tree-like containers support it. <a href= + "#container_traits">Data-Structure Tags and Traits</a> discusses how + to query which types and methods each container supports.</p> + + <h2><a name="container_traits" id="container_traits">Data-Structure Tags and + Traits</a></h2> + + <p>Tags and traits are very useful for manipulating generic + types. For example, if <tt>It</tt> is an iterator class, then + <tt><b>typename</b> It::iterator_category</tt> or + <tt><b>typename</b> + std::iterator_traits<It>::iterator_category</tt> will + yield its category, and <tt><b>typename</b> + std::iterator_traits<It>::value_type</tt> will yield its + value type.</p> + + <p><tt>pb_ds</tt> contains a tag hierarchy corresponding to the + hierarchy in Figure <a href="#cd">Class hierarchy</a>. The tag + hierarchy is shown in Figure <a href= + "#tag_cd">Data-structure tag class hierarchy</a>.</p> + + <h6 class="c1"><a name="tag_cd" id="tag_cd"><img src= + "assoc_container_tag_cd.png" alt="no image" /></a></h6> + + <h6 class="c1">Data-structure tag class hierarchy.</h6> + + <p><a href= + "container_base.html"><tt>container_base</tt></a> + publicly defines <tt>container_category</tt> as one of the classes in + Figure <a href="#tag_cd">Data-structure tag class + hierarchy</a>. Given any container <tt>Cntnr</tt>, the tag of + the underlying data structure can be found via + <tt><b>typename</b> Cntnr::container_category</tt>.</p> + + <p>Additionally, a traits mechanism can be used to query a + container type for its attributes. Given any container + <tt>Cntnr</tt>, then <tt><a href= + "assoc_container_traits.html">__gnu_pbds::container_traits</a><Cntnr></tt> + is a traits class identifying the properties of the + container.</p> + + <p>To find if a container can throw when a key is erased (which + is true for vector-based trees, for example), one can + use</p><a href= + "assoc_container_traits.html"><tt>container_traits</tt></a><tt><Cntnr>::erase_can_throw</tt>, + for example. + + <p>Some of the definitions in <a href= + "assoc_container_traits.html"><tt>container_traits</tt></a> are + dependent on other definitions. <i>E.g.</i>, if <a href= + "assoc_container_traits.html"><tt>container_traits</tt></a><tt><Cntnr>::order_preserving</tt> + is <tt><b>true</b></tt> (which is the case for containers based + on trees and tries), then the container can be split or joined; + in this case, <a href= + "assoc_container_traits.html"><tt>container_traits</tt></a><tt><Cntnr>::split_join_can_throw</tt> + indicates whether splits or joins can throw exceptions (which + is true for vector-based trees); otherwise <a href= + "assoc_container_traits.html"><tt>container_traits</tt></a><tt><Cntnr>::split_join_can_throw</tt> + will yield a compilation error. (This is somewhat similar to a + compile-time version of the COM model [<a href= + "references.html#mscom">mscom</a>]).</p> + + <h2><a name="find_range" id="find_range">Point-Type and + Range-Type Methods and Iterators</a></h2> + + <h3><a name="it_unordered" id="it_unordered">Iterators in + Unordered Container Types</a></h3> + + <p><tt>pb_ds</tt> differentiates between two types of methods + and iterators: point-type methods and iterators, and range-type + methods and iterators (see <a href= + "motivation.html#assoc_diff_it">Motivation::Associative + Containers::Differentiating between Iterator Types</a> and + <a href="tutorial.html#assoc_find_range">Tutorial::Associative + Containers::Point-Type and Range-Type Methods and + Iterators</a>). Each associative container's interface includes + the methods:</p> + <pre> +const_point_iterator +find(const_key_reference r_key) const; + +point_iterator +find(const_key_reference r_key); + +std::pair<point_iterator,<b>bool</b>> +insert(const_reference r_val); +</pre> + + <p>The relationship between these iterator types varies between + container types. Figure <a href= + "#point_iterators_cd">Point-type and range-type iterators</a>-A + shows the most general invariant between point-type and + range-type iterators: <tt>iterator</tt>, <i>e.g.</i>, can + always be converted to <tt>point_iterator</tt>. Figure <a href= + "#point_iterators_cd">Point-type and range-type iterators</a>-B + shows invariants for order-preserving containers: point-type + iterators are synonymous with range-type iterators. + Orthogonally, Figure <a href="#point_iterators_cd">Point-type + and range-type iterators</a>-C shows invariants for "set" + containers: iterators are synonymous with const iterators.</p> + + <h6 class="c1"><a name="point_iterators_cd" id= + "point_iterators_cd"><img src="point_iterators_cd.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Point-type and range-type iterators.</h6> + + <p>Note that point-type iterators in self-organizing containers + (<i>e.g.</i>, hash-based associative containers) lack movement + operators, such as <tt><b>operator++</b></tt> - in fact, this + is the reason why <tt>pb_ds</tt> differentiates from the STL's + design on this point.</p> + + <p>Typically, one can determine an iterator's movement + capabilities in the STL using + <tt>std::iterator_traits<It>iterator_category</tt>, which + is a <tt><b>struct</b></tt> indicating the iterator's movement + capabilities. Unfortunately, none of the STL's predefined + categories reflect a pointer's <u>not</u> having any movement + capabilities whatsoever. Consequently, <tt>pb_ds</tt> adds a + type <a href= + "trivial_iterator_tag.html"><tt>trivial_iterator_tag</tt></a> + (whose name is taken from a concept in [<a href= + "references.html#sgi_stl">sgi_stl</a>]), which is the category + of iterators with no movement capabilities. All other STL tags, + such as <tt>forward_iterator_tag</tt> retain their common + use.</p> + + <h3><a name="inv_guar" id="inv_guar">Invalidation + Guarantees</a></h3> + + <p><a href= + "motivation.html#assoc_inv_guar">Motivation::Associative + Containers::Differentiating between Iterator + Types::Invalidation Guarantees</a> posed a problem. Given three + different types of associative containers, a modifying + operation (in that example, <tt>erase</tt>) invalidated + iterators in three different ways: the iterator of one + container remained completely valid - it could be de-referenced + and incremented; the iterator of a different container could + not even be de-referenced; the iterator of the third container + could be de-referenced, but its "next" iterator changed + unpredictably.</p> + + <p>Distinguishing between find and range types allows + fine-grained invalidation guarantees, because these questions + correspond exactly to the question of whether point-type + iterators and range-type iterators are valid. <a href= + "#invalidation_guarantee_cd">Invalidation guarantees class + hierarchy</a> shows tags corresponding to different types of + invalidation guarantees.</p> + + <h6 class="c1"><a name="invalidation_guarantee_cd" id= + "invalidation_guarantee_cd"><img src= + "invalidation_guarantee_cd.png" alt="no image" /></a></h6> + + <h6 class="c1">Invalidation guarantees class hierarchy.</h6> + + <ol> + <li><a href= + "basic_invalidation_guarantee.html"><tt>basic_invalidation_guarantee</tt></a> + corresponds to a basic guarantee that a point-type iterator, + a found pointer, or a found reference, remains valid as long + as the container object is not modified.</li> + + <li><a href= + "point_invalidation_guarantee.html"><tt>point_invalidation_guarantee</tt></a> + corresponds to a guarantee that a point-type iterator, a + found pointer, or a found reference, remains valid even if + the container object is modified.</li> + + <li><a href= + "range_invalidation_guarantee.html"><tt>range_invalidation_guarantee</tt></a> + corresponds to a guarantee that a range-type iterator remains + valid even if the container object is modified.</li> + </ol> + + <p>As shown in <a href= + "tutorial.html#assoc_find_range">Tutorial::Associative + Containers::Point-Type and Range-Type Methods and + Iterators</a>, to find the invalidation guarantee of a + container, one can use</p> + <pre> +<b>typename</b> <a href= +"assoc_container_traits.html">container_traits</a><Cntnr>::invalidation_guarantee +</pre> + + <p>which is one of the classes in Figure <a href= + "#invalidation_guarantee_cd">Invalidation guarantees class + hierarchy</a>.</p> + + <p>Note that this hierarchy corresponds to the logic it + represents: if a container has range-invalidation guarantees, + then it must also have find invalidation guarantees; + correspondingly, its invalidation guarantee (in this case + <a href= + "range_invalidation_guarantee.html"><tt>range_invalidation_guarantee</tt></a>) + can be cast to its base class (in this case <a href= + "point_invalidation_guarantee.html"><tt>point_invalidation_guarantee</tt></a>). + This means that this this hierarchy can be used easily using + standard metaprogramming techniques, by specializing on the + type of <tt>invalidation_guarantee</tt>.</p> + + <p>(These types of problems were addressed, in a more general + setting, in [<a href= + "references.html#meyers96more">meyers96more</a>] - Item 2. In + our opinion, an invalidation-guarantee hierarchy would solve + these problems in all container types - not just associative + containers.)</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_1.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_1.png Binary files differnew file mode 100644 index 000000000..9470a65b5 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_1.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_2.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_2.png Binary files differnew file mode 100644 index 000000000..d2ac91c1a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_2.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_3.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_3.png Binary files differnew file mode 100644 index 000000000..08ecb0ffe --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_3.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/examples.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/examples.html new file mode 100644 index 000000000..03c7a3910 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/examples.html @@ -0,0 +1,24 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Examples</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Examples</h1> + + <p><a href="assoc_examples.html">Associative-Container + Examples</a> shows examples for associative containers; + <a href="pq_examples.html">Priority-Queue Examples</a> shows + examples for priority queues.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/exceptions.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/exceptions.html new file mode 100644 index 000000000..a51e8ebe0 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/exceptions.html @@ -0,0 +1,46 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + +<title>container_error Interface</title> +<meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> +</head> + +<body> +<div id="page"> +<h1><tt>container_error</tt> Interface</h1> + +<p>Base class for associative-container exceptions.</p> + +<p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/exception.hpp"><tt>exception.hpp</tt></a></p> + +<h2><a name="link1" id="link1">Base Classes</a></h2> + +<table class="c1" width="100%" border="1" summary="Bases"> +<tr> +<td width="80%" align="left"><b>Class</b></td> + +<td width="20%" align="left"><b>Derivation Type</b></td> +</tr> + +<tr> +<td> +<pre> +std::logic_error +</pre> +</td> + +<td> +<p>public</p> +</td> +</tr> +</table> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..d86299b7e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_local.png Binary files differnew file mode 100644 index 000000000..1b31b7f27 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..b7082f286 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_gcc.png Binary files differnew file mode 100644 index 000000000..b9fbe00de --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_local.png Binary files differnew file mode 100644 index 000000000..c693ed386 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_msvc.png Binary files differnew file mode 100644 index 000000000..248ff6b88 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_gcc.png Binary files differnew file mode 100644 index 000000000..ac4f838fe --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_local.png Binary files differnew file mode 100644 index 000000000..9fa08a0c2 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_msvc.png Binary files differnew file mode 100644 index 000000000..5f1d740b8 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_table.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_table.html new file mode 100644 index 000000000..dd9d725d3 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_table.html @@ -0,0 +1,891 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>gp_hash_table Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>gp_hash_table</tt> Interface</h1> + + <p>A concrete general-probing hash-based associative + container.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Key2501" id="Key2501"><b>typename</b> Key</a> +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a> +</pre> + </td> + + <td> + <p>Mapped type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Hash_Fn1515835" id= +"Hash_Fn1515835"><b>class</b> Hash_Fn </a> +</pre> + </td> + + <td> + <p>Hash functor.</p> + </td> + + <td> + <pre> +__gnu_cxx::hash<<a href="#Key2501"><tt>Key</tt></a>> +</pre>if using gcc; + <pre> +stdext::hash_value<<a href="#Key2501"><tt>Key</tt></a>> +</pre>if using Visual C++ .net + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Eq_Fn60085" id="Eq_Fn60085"><b>class</b> Eq_Fn </a> +</pre> + </td> + + <td> + <p>Equivalence functor.</p> + </td> + + <td> + <pre> +std::equal_to<<a href="#Key2501"><tt>Key</tt></a>> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Comb_Probe_Fn1603930855" id= +"Comb_Probe_Fn1603930855"><b>class</b> Comb_Probe_Fn </a> +</pre> + </td> + + <td> + <p>Combining probe functor.</p> + + <p>If <a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a> is + <a href="null_hash_fn.html"><span class= + "c2"><tt>null_hash_fn</tt></span></a>, and <a href= + "#Probe_Fn8454835"><tt>Probe_Fn</tt></a> is <a href= + "null_probe_fn.html"><span class= + "c2"><tt>null_probe_fn</tt></span></a>, then this is the + ranged-probe functor; otherwise, this is the + range-hashing functor.</p> + + <p>(See <a href= + "hash_based_containers.html#hash_policies">Design::Hash-Based + Containers::Hash Policies</a>.)</p> + </td> + + <td><a href="direct_mask_range_hashing.html"><span class= + "c2"><tt>direct_mask_range_hashing</tt></span></a></td> + </tr> + + <tr> + <td> + <pre> +<a name="Probe_Fn8454835" id= +"Probe_Fn8454835"><b>class</b> Probe_Fn </a> +</pre> + </td> + + <td> + <p>Probe functor.</p> + </td> + + <td> + If <tt><a href= + "#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a></tt> + is <a href="direct_mask_range_hashing.html"><span class= + "c2"><tt>direct_mask_range_hashing</tt></span></a>, then + <pre> +<a href="linear_probe_fn.html"><span class= +"c2"><tt>linear_probe_fn</tt></span></a>< + <b>typename</b> <a href= +"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type> +</pre>otherwise, + <pre> +<a href="quadratic_probe_fn.html"><span class= +"c2"><tt>quadratic_probe_fn</tt></span></a>< + <b>typename</b> <a href= +"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Resize_Policy566860465" id= +"Resize_Policy566860465"><b>class</b> Resize_Policy </a> +</pre> + </td> + + <td> + <p>Resize policy.</p> + </td> + + <td> + If <tt><a href= + "#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a></tt> + is <tt><a href= + "direct_mask_range_hashing.html"><span class= + "c2"><tt>direct_mask_range_hashing</tt></span></a></tt>, + then + <pre> +<a href="hash_standard_resize_policy.html"><span class= +"c2"><tt>hash_standard_resize_policy</tt></span></a>< + <a href="hash_exponential_size_policy.html"><span class= +"c2"><tt>hash_exponential_size_policy</tt></span></a>< + <b>typename</b> <a href= +"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type>, + <a href="hash_load_check_resize_trigger.html"><span class= +"c2"><tt>hash_load_check_resize_trigger</tt></span></a>< + <b>typename</b> <a href= +"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type>, + <b>false</b>, + <b>typename</b> <a href= +"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type> +</pre>otherwise, + <pre> +<a href="hash_standard_resize_policy.html"><span class= +"c2"><tt>hash_standard_resize_policy</tt></span></a>< + <a href="hash_exponential_size_policy.html"><span class= +"c2"><tt>hash_exponential_size_policy</tt></span></a>< + <b>typename</b> <a href= +"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type>, + <a href="hash_load_check_resize_trigger.html"><span class= +"c2"><tt>hash_load_check_resize_trigger</tt></span></a>< + <b>typename</b> <a href= +"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type>, + <b>false</b>, + <b>typename</b> <a href= +"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Store_Hash218262104" id= +"Store_Hash218262104"><b>bool</b> Store_Hash </a> +</pre> + </td> + + <td> + <p>Indicates whether the hash value will be stored along + with each key.</p> + + <p>If <tt><a href= + "#hash_fn2015995"><tt>hash_fn</tt></a></tt> is <a href= + "null_hash_fn.html"><span class= + "c2"><tt>null_hash_fn</tt></span></a>, then the container + will not compile if this value is + <tt><b>true</b></tt></p> + </td> + + <td> + <pre> +<tt><b>false</b></tt> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator </a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td> + <pre> +std::allocator<<b>char</b>> +</pre> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="basic_hash_table.html"><span class= +"c2"><tt>basic_hash_table</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Types and + Constants</a></h2> + + <h3><a name="link4" id="link4">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="hash_fn2015995" id="hash_fn2015995">hash_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a> +</pre> + </td> + + <td> + <p>Hash functor type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="eq_fn80245" id="eq_fn80245">eq_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Eq_Fn60085"><tt>Eq_Fn</tt></a> +</pre> + </td> + + <td> + <p>Equivalence functor type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="comb_probe_fn828996423" id= +"comb_probe_fn828996423">comb_probe_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a> +</pre> + </td> + + <td> + <p>Combining probe functor type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="probe_fn10954995" id="probe_fn10954995">probe_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Probe_Fn8454835"><tt>Probe_Fn</tt></a> +</pre> + </td> + + <td> + <p>Probe functor type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="resize_policy4084493169" id= +"resize_policy4084493169">resize_policy</a> +</pre> + </td> + + <td> + <pre> +<a href="#Resize_Policy566860465"><tt>Resize_Policy</tt></a> +</pre> + </td> + + <td> + <p>Resize policy type.</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Public Methods</a></h2> + + <h3><a name="link6" id="link6">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + gp_hash_table + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> + gp_hash_table + (<b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + gp_hash_table + (<b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, and <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + gp_hash_table + (<b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn, + <b>const</b> <a href= +"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &r_comb_probe_fn) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object, and <span class= + "c1"><tt>r_comb_probe_fn</tt></span> will be copied by + the <a href= + "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> + object of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + gp_hash_table + (<b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn, + <b>const</b> <a href= +"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &r_comb_probe_fn, + <b>const</b> <a href= +"#probe_fn10954995"><tt>probe_fn</tt></a> &r_probe_fn) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object, <span class= + "c1"><tt>r_comb_probe_fn</tt></span> will be copied by + the <a href= + "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> + object of the container object, and <span class= + "c1"><tt>r_probe_fn</tt></span> will be copied by the + <a href="#probe_fn10954995"><tt>probe_fn</tt></a> object + of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + gp_hash_table + (<b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn, + <b>const</b> <a href= +"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &r_comb_probe_fn, + <b>const</b> <a href= +"#probe_fn10954995"><tt>probe_fn</tt></a> &r_probe_fn, + <b>const</b> <a href= +"#resize_policy4084493169"><tt>resize_policy</tt></a> &r_resize_policy) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object, <span class= + "c1"><tt>r_comb_probe_fn</tt></span> will be copied by + the <a href= + "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> + object of the container object, <span class= + "c1"><tt>r_probe_fn</tt></span> will be copied by the + <a href="#probe_fn10954995"><tt>probe_fn</tt></a> object + of the container object, and <span class= + "c1"><tt>r_resize_policy</tt></span> will be copied by + the <a href= + "#Resize_Policy566860465"><tt>Resize_Policy</tt></a> + object of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + gp_hash_table + (It first_it, + It last_it) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of + value_types. The value_types between <span class= + "c1"><tt>first_it</tt></span> and <span class= + "c1"><tt>last_it</tt></span> will be inserted into the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + gp_hash_table + (It first_it, + It last_it, + <b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects. The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + gp_hash_table + (It first_it, + It last_it, + <b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects. The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, and <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + gp_hash_table + (It first_it, + It last_it, + <b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn, + <b>const</b> <a href= +"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &r_comb_probe_fn) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects. The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object, and <span class= + "c1"><tt>r_comb_probe_fn</tt></span> will be copied by + the <a href= + "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> + object of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + gp_hash_table + (It first_it, + It last_it, + <b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn, + <b>const</b> <a href= +"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &r_comb_probe_fn, + <b>const</b> <a href= +"#probe_fn10954995"><tt>probe_fn</tt></a> &r_probe_fn) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects. The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object, <span class= + "c1"><tt>r_comb_probe_fn</tt></span> will be copied by + the <a href= + "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> + object of the container object, and <span class= + "c1"><tt>r_probe_fn</tt></span> will be copied by the + <a href="#probe_fn10954995"><tt>probe_fn</tt></a> object + of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + gp_hash_table + (It first_it, + It last_it, + <b>const</b> <a href= +"#hash_fn2015995"><tt>hash_fn</tt></a> &r_hash_fn, + <b>const</b> <a href= +"#eq_fn80245"><tt>eq_fn</tt></a> &r_eq_fn, + <b>const</b> <a href= +"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &r_comb_probe_fn, + <b>const</b> <a href= +"#probe_fn10954995"><tt>probe_fn</tt></a> &r_probe_fn, + <b>const</b> <a href= +"#resize_policy4084493169"><tt>resize_policy</tt></a> &r_resize_policy) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects. The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object. <span class= + "c1"><tt>r_hash_fn</tt></span> will be copied by the + <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of + the container object, <span class= + "c1"><tt>r_eq_fn</tt></span> will be copied by the + <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the + container object, <span class= + "c1"><tt>r_comb_probe_fn</tt></span> will be copied by + the <a href= + "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> + object of the container object, <span class= + "c1"><tt>r_probe_fn</tt></span> will be copied by the + <a href="#probe_fn10954995"><tt>probe_fn</tt></a> object + of the container object, and <span class= + "c1"><tt>r_resize_policy</tt></span> will be copied by + the <a href= + "#resize_policy4084493169"><tt>resize_policy</tt></a> + object of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + gp_hash_table + (<b>const</b> <span class= +"c2"><tt>gp_hash_table</tt></span> &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~gp_hash_table + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<span class="c2"><tt>gp_hash_table</tt></span> & + <b>operator</b>= + (<b>const</b> <span class= +"c2"><tt>gp_hash_table</tt></span> &other) +</pre> + </td> + + <td> + <p>Assignment operator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class= +"c2"><tt>gp_hash_table</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Policy Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> & + get_comb_probe_fn + () +</pre> + </td> + + <td> + <p>Access to the <a href= + "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> + object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>const</b> <a href= +"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> & + get_comb_probe_fn + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access to the <a href= + "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> + object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#probe_fn10954995"><tt>probe_fn</tt></a> & + get_probe_fn + () +</pre> + </td> + + <td> + <p>Access to the <a href= + "#probe_fn10954995"><tt>probe_fn</tt></a> object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>const</b> <a href= +"#probe_fn10954995"><tt>probe_fn</tt></a> & + get_probe_fn + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access to the <a href= + "#probe_fn10954995"><tt>probe_fn</tt></a> object.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_tag.html new file mode 100644 index 000000000..4c5f06b57 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>gp_hash_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>gp_hash_tag</tt> Interface</h1> + + <p>General-probing hash data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="basic_hash_tag.html"><span class= +"c2"><tt>basic_hash_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_based_containers.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_based_containers.html new file mode 100644 index 000000000..21d092a76 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_based_containers.html @@ -0,0 +1,835 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Hash-Based Containers</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Hash Table Design</h1> + + <h2><a name="overview" id="overview">Overview</a></h2> + + <p>The collision-chaining hash-based container has the + following declaration.</p> + <pre> +<b>template</b>< + <b>typename</b> Key, + <b>typename</b> Mapped, + <b>typename</b> Hash_Fn = std::hash<Key>, + <b>typename</b> Eq_Fn = std::equal_to<Key>, + <b>typename</b> Comb_Hash_Fn = <a href= +"direct_mask_range_hashing.html">direct_mask_range_hashing</a><> + <b>typename</b> Resize_Policy = <i>default explained below.</i> + <b>bool</b> Store_Hash = <b>false</b>, + <b>typename</b> Allocator = std::allocator<<b>char</b>> > +<b>class</b> <a href= +"cc_hash_table.html">cc_hash_table</a>; +</pre> + + <p>The parameters have the following meaning:</p> + + <ol> + <li><tt>Key</tt> is the key type.</li> + + <li><tt>Mapped</tt> is the mapped-policy, and is explained in + <a href="tutorial.html#assoc_ms">Tutorial::Associative + Containers::Associative Containers Others than Maps</a>.</li> + + <li><tt>Hash_Fn</tt> is a key hashing functor.</li> + + <li><tt>Eq_Fn</tt> is a key equivalence functor.</li> + + <li><tt>Comb_Hash_Fn</tt> is a <i>range-hashing_functor</i>; + it describes how to translate hash values into positions + within the table. This is described in <a href= + "#hash_policies">Hash Policies</a>.</li> + + <li><tt>Resize_Policy</tt> describes how a container object + should change its internal size. This is described in + <a href="#resize_policies">Resize Policies</a>.</li> + + <li><tt>Store_Hash</tt> indicates whether the hash value + should be stored with each entry. This is described in + <a href="#policy_interaction">Policy Interaction</a>.</li> + + <li><tt>Allocator</tt> is an allocator + type.</li> + </ol> + + <p>The probing hash-based container has the following + declaration.</p> + <pre> +<b>template</b>< + <b>typename</b> Key, + <b>typename</b> Mapped, + <b>typename</b> Hash_Fn = std::hash<Key>, + <b>typename</b> Eq_Fn = std::equal_to<Key>, + <b>typename</b> Comb_Probe_Fn = <a href= +"direct_mask_range_hashing.html">direct_mask_range_hashing</a><> + <b>typename</b> Probe_Fn = <i>default explained below.</i> + <b>typename</b> Resize_Policy = <i>default explained below.</i> + <b>bool</b> Store_Hash = <b>false</b>, + <b>typename</b> Allocator = std::allocator<<b>char</b>> > +<b>class</b> <a href= +"gp_hash_table.html">gp_hash_table</a>; +</pre> + + <p>The parameters are identical to those of the + collision-chaining container, except for the following.</p> + + <ol> + <li><tt>Comb_Probe_Fn</tt> describes how to transform a probe + sequence into a sequence of positions within the table.</li> + + <li><tt>Probe_Fn</tt> describes a probe sequence policy.</li> + </ol> + + <p>Some of the default template values depend on the values of + other parameters, and are explained in <a href= + "#policy_interaction">Policy Interaction</a>.</p> + + <h2><a name="hash_policies" id="hash_policies">Hash + Policies</a></h2> + + <h3><a name="general_terms" id="general_terms">General + Terms</a></h3> + + <p>Following is an explanation of some functions which hashing + involves. Figure <a href= + "#hash_ranged_hash_range_hashing_fns">Hash functions, + ranged-hash functions, and range-hashing functions</a>) + illustrates the discussion.</p> + + <h6 class="c1"><a name="hash_ranged_hash_range_hashing_fns" id= + "hash_ranged_hash_range_hashing_fns"><img src= + "hash_ranged_hash_range_hashing_fns.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Hash functions, ranged-hash functions, and + range-hashing functions.</h6> + + <p>Let <i>U</i> be a domain (<i>e.g.</i>, the integers, or the + strings of 3 characters). A hash-table algorithm needs to map + elements of <i>U</i> "uniformly" into the range <i>[0,..., m - + 1]</i> (where <i>m</i> is a non-negative integral value, and + is, in general, time varying). <i>I.e.</i>, the algorithm needs + a <i>ranged-hash</i> function</p> + + <p><i>f : U × Z<sub>+</sub> → Z<sub>+</sub></i> + ,</p> + + <p>such that for any <i>u</i> in <i>U</i> ,</p> + + <p><i>0 ≤ f(u, m) ≤ m - 1</i> ,</p> + + <p>and which has "good uniformity" properties [<a href= + "references.html#knuth98sorting">knuth98sorting</a>]. One + common solution is to use the composition of the hash + function</p> + + <p><i>h : U → Z<sub>+</sub></i> ,</p> + + <p>which maps elements of <i>U</i> into the non-negative + integrals, and</p> + + <p class="c2">g : Z<sub>+</sub> × Z<sub>+</sub> → + Z<sub>+</sub>,</p> + + <p>which maps a non-negative hash value, and a non-negative + range upper-bound into a non-negative integral in the range + between 0 (inclusive) and the range upper bound (exclusive), + <i>i.e.</i>, for any <i>r</i> in <i>Z<sub>+</sub></i>,</p> + + <p><i>0 ≤ g(r, m) ≤ m - 1</i> .</p> + + <p>The resulting ranged-hash function, is</p> + + <p><i><a name="ranged_hash_composed_of_hash_and_range_hashing" + id="ranged_hash_composed_of_hash_and_range_hashing">f(u , m) = + g(h(u), m)</a></i> (1) .</p> + + <p>From the above, it is obvious that given <i>g</i> and + <i>h</i>, <i>f</i> can always be composed (however the converse + is not true). The STL's hash-based containers allow specifying + a hash function, and use a hard-wired range-hashing function; + the ranged-hash function is implicitly composed.</p> + + <p>The above describes the case where a key is to be mapped + into a <i>single position</i> within a hash table, <i>e.g.</i>, + in a collision-chaining table. In other cases, a key is to be + mapped into a <i>sequence of positions</i> within a table, + <i>e.g.</i>, in a probing table. Similar terms apply in this + case: the table requires a <i>ranged probe</i> function, + mapping a key into a sequence of positions withing the table. + This is typically achieved by composing a <i>hash function</i> + mapping the key into a non-negative integral type, a + <i>probe</i> function transforming the hash value into a + sequence of hash values, and a <i>range-hashing</i> function + transforming the sequence of hash values into a sequence of + positions.</p> + + <h3><a name="range_hashing_fns" id= + "range_hashing_fns">Range-Hashing Functions</a></h3> + + <p>Some common choices for range-hashing functions are the + division, multiplication, and middle-square methods [<a href= + "references.html#knuth98sorting">knuth98sorting</a>], defined + as</p> + + <p><i><a name="division_method" id="division_method">g(r, m) = + r mod m</a></i> (2) ,</p> + + <p><i>g(r, m) = ⌈ u/v ( a r mod v ) ⌉</i> ,</p> + + <p>and</p> + + <p><i>g(r, m) = ⌈ u/v ( r<sup>2</sup> mod v ) ⌉</i> + ,</p> + + <p>respectively, for some positive integrals <i>u</i> and + <i>v</i> (typically powers of 2), and some <i>a</i>. Each of + these range-hashing functions works best for some different + setting.</p> + + <p>The division method <a href="#division_method">(2)</a> is a + very common choice. However, even this single method can be + implemented in two very different ways. It is possible to + implement <a href="#division_method">(2)</a> using the low + level <i>%</i> (modulo) operation (for any <i>m</i>), or the + low level <i>&</i> (bit-mask) operation (for the case where + <i>m</i> is a power of 2), <i>i.e.</i>,</p> + + <p><i><a name="division_method_prime_mod" id= + "division_method_prime_mod">g(r, m) = r % m</a></i> (3) ,</p> + + <p>and</p> + + <p><i><a name="division_method_bit_mask" id= + "division_method_bit_mask">g(r, m) = r & m - 1, (m = + 2<sup>k</sup>)</a></i> for some <i>k)</i> (4),</p> + + <p>respectively.</p> + + <p>The <i>%</i> (modulo) implementation <a href= + "#division_method_prime_mod">(3)</a> has the advantage that for + <i>m</i> a prime far from a power of 2, <i>g(r, m)</i> is + affected by all the bits of <i>r</i> (minimizing the chance of + collision). It has the disadvantage of using the costly modulo + operation. This method is hard-wired into SGI's implementation + [<a href="references.html#sgi_stl">sgi_stl</a>].</p> + + <p>The <i>&</i> (bit-mask) implementation <a href= + "#division_method_bit_mask">(4)</a> has the advantage of + relying on the fast bit-wise and operation. It has the + disadvantage that for <i>g(r, m)</i> is affected only by the + low order bits of <i>r</i>. This method is hard-wired into + Dinkumware's implementation [<a href= + "references.html#dinkumware_stl">dinkumware_stl</a>].</p> + + <h3><a name="hash_policies_ranged_hash_policies" id= + "hash_policies_ranged_hash_policies">Ranged-Hash + Functions</a></h3> + + <p>In cases it is beneficial to allow the + client to directly specify a ranged-hash hash function. It is + true, that the writer of the ranged-hash function cannot rely + on the values of <i>m</i> having specific numerical properties + suitable for hashing (in the sense used in [<a href= + "references.html#knuth98sorting">knuth98sorting</a>]), since + the values of <i>m</i> are determined by a resize policy with + possibly orthogonal considerations.</p> + + <p>There are two cases where a ranged-hash function can be + superior. The firs is when using perfect hashing [<a href= + "references.html#knuth98sorting">knuth98sorting</a>]; the + second is when the values of <i>m</i> can be used to estimate + the "general" number of distinct values required. This is + described in the following.</p> + + <p>Let</p> + + <p class="c2">s = [ s<sub>0</sub>,..., s<sub>t - 1</sub>]</p> + + <p>be a string of <i>t</i> characters, each of which is from + domain <i>S</i>. Consider the following ranged-hash + function:</p> + + <p><a name="total_string_dna_hash" id= + "total_string_dna_hash"><i>f<sub>1</sub>(s, m) = ∑ <sub>i = + 0</sub><sup>t - 1</sup> s<sub>i</sub> a<sup>i</sup></i> mod + <i>m</i></a> (5) ,</p> + + <p>where <i>a</i> is some non-negative integral value. This is + the standard string-hashing function used in SGI's + implementation (with <i>a = 5</i>) [<a href= + "references.html#sgi_stl">sgi_stl</a>]. Its advantage is that + it takes into account all of the characters of the string.</p> + + <p>Now assume that <i>s</i> is the string representation of a + of a long DNA sequence (and so <i>S = {'A', 'C', 'G', + 'T'}</i>). In this case, scanning the entire string might be + prohibitively expensive. A possible alternative might be to use + only the first <i>k</i> characters of the string, where</p> + + <p>|S|<sup>k</sup> ≥ m ,</p> + + <p><i>i.e.</i>, using the hash function</p> + + <p><a name="only_k_string_dna_hash" id= + "only_k_string_dna_hash"><i>f<sub>2</sub>(s, m) = ∑ <sub>i + = 0</sub><sup>k - 1</sup> s<sub>i</sub> a<sup>i</sup></i> mod + <i>m</i></a> , (6)</p> + + <p>requiring scanning over only</p> + + <p><i>k =</i> log<i><sub>4</sub>( m )</i></p> + + <p>characters.</p> + + <p>Other more elaborate hash-functions might scan <i>k</i> + characters starting at a random position (determined at each + resize), or scanning <i>k</i> random positions (determined at + each resize), <i>i.e.</i>, using</p> + + <p><i>f<sub>3</sub>(s, m) = ∑ <sub>i = + r</sub>0</i><sup>r<sub>0</sub> + k - 1</sup> s<sub>i</sub> + a<sup>i</sup> mod <i>m</i> ,</p> + + <p>or</p> + + <p><i>f<sub>4</sub>(s, m) = ∑ <sub>i = 0</sub><sup>k - + 1</sup> s<sub>r</sub>i</i> a<sup>r<sub>i</sub></sup> mod + <i>m</i> ,</p> + + <p>respectively, for <i>r<sub>0</sub>,..., r<sub>k-1</sub></i> + each in the (inclusive) range <i>[0,...,t-1]</i>.</p> + + <p>It should be noted that the above functions cannot be + decomposed as <a href= + "#ranged_hash_composed_of_hash_and_range_hashing">(1)</a> .</p> + + <h3><a name="pb_ds_imp" id="pb_ds_imp">Implementation</a></h3> + + <p>This sub-subsection describes the implementation of the + above in <tt>pb_ds</tt>. It first explains range-hashing + functions in collision-chaining tables, then ranged-hash + functions in collision-chaining tables, then probing-based + tables, and, finally, lists the relevant classes in + <tt>pb_ds</tt>.</p> + + <h4>Range-Hashing and Ranged-Hashes in Collision-Chaining + Tables</h4> + + <p><a href= + "cc_hash_table.html"><tt>cc_hash_table</tt></a> is + parametrized by <tt>Hash_Fn</tt> and <tt>Comb_Hash_Fn</tt>, a + hash functor and a combining hash functor, respectively.</p> + + <p>In general, <tt>Comb_Hash_Fn</tt> is considered a + range-hashing functor. <a href= + "cc_hash_table.html"><tt>cc_hash_table</tt></a> + synthesizes a ranged-hash function from <tt>Hash_Fn</tt> and + <tt>Comb_Hash_Fn</tt> (see <a href= + "#ranged_hash_composed_of_hash_and_range_hashing">(1)</a> + above). Figure <a href="#hash_range_hashing_seq_diagram">Insert + hash sequence diagram</a> shows an <tt>insert</tt> sequence + diagram for this case. The user inserts an element (point A), + the container transforms the key into a non-negative integral + using the hash functor (points B and C), and transforms the + result into a position using the combining functor (points D + and E).</p> + + <h6 class="c1"><a name="hash_range_hashing_seq_diagram" id= + "hash_range_hashing_seq_diagram"><img src= + "hash_range_hashing_seq_diagram.png" alt="no image" /></a></h6> + + <h6 class="c1">Insert hash sequence diagram.</h6> + + <p>If <a href= + "cc_hash_table.html"><tt>cc_hash_table</tt></a>'s + hash-functor, <tt>Hash_Fn</tt> is instantiated by <a href= + "null_hash_fn.html"><tt>null_hash_fn</tt></a> (see <a href= + "concepts.html#concepts_null_policies">Interface::Concepts::Null + Policy Classes</a>), then <tt>Comb_Hash_Fn</tt> is taken to be + a ranged-hash function. Figure <a href= + "#hash_range_hashing_seq_diagram2">Insert hash sequence diagram + with a null hash policy</a> shows an <tt>insert</tt> sequence + diagram. The user inserts an element (point A), the container + transforms the key into a position using the combining functor + (points B and C).</p> + + <h6 class="c1"><a name="hash_range_hashing_seq_diagram2" id= + "hash_range_hashing_seq_diagram2"><img src= + "hash_range_hashing_seq_diagram2.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Insert hash sequence diagram with a null hash + policy.</h6> + + <h4>Probing Tables</h4> + + <p><a href= + "gp_hash_table.html"></a><tt>gp_hash_table</tt> is + parametrized by <tt>Hash_Fn</tt>, <tt>Probe_Fn</tt>, and + <tt>Comb_Probe_Fn</tt>. As before, if <tt>Hash_Fn</tt> and + <tt>Probe_Fn</tt> are, respectively, <a href= + "null_hash_fn.html"><tt>null_hash_fn</tt></a> and <a href= + "null_probe_fn.html"><tt>null_probe_fn</tt></a>, then + <tt>Comb_Probe_Fn</tt> is a ranged-probe functor. Otherwise, + <tt>Hash_Fn</tt> is a hash functor, <tt>Probe_Fn</tt> is a + functor for offsets from a hash value, and + <tt>Comb_Probe_Fn</tt> transforms a probe sequence into a + sequence of positions within the table.</p> + + <h4>Pre-Defined Policies</h4> + + <p><tt>pb_ds</tt> contains some pre-defined classes + implementing range-hashing and probing functions:</p> + + <ol> + <li><a href= + "direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> + and <a href= + "direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> + are range-hashing functions based on a bit-mask and a modulo + operation, respectively.</li> + + <li><a href= + "linear_probe_fn.html"><tt>linear_probe_fn</tt></a>, and + <a href= + "quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> are + a linear probe and a quadratic probe function, + respectively.</li> + </ol>Figure <a href="#hash_policy_cd">Hash policy class + diagram</a> shows a class diagram. + + <h6 class="c1"><a name="hash_policy_cd" id= + "hash_policy_cd"><img src="hash_policy_cd.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Hash policy class diagram.</h6> + + <h2><a name="resize_policies" id="resize_policies">Resize + Policies</a></h2> + + <h3><a name="general" id="general">General Terms</a></h3> + + <p>Hash-tables, as opposed to trees, do not naturally grow or + shrink. It is necessary to specify policies to determine how + and when a hash table should change its size. Usually, resize + policies can be decomposed into orthogonal policies:</p> + + <ol> + <li>A <i>size policy</i> indicating <i>how</i> a hash table + should grow (<i>e.g.,</i> it should multiply by powers of + 2).</li> + + <li>A <i>trigger policy</i> indicating <i>when</i> a hash + table should grow (<i>e.g.,</i> a load factor is + exceeded).</li> + </ol> + + <h3><a name="size_policies" id="size_policies">Size + Policies</a></h3> + + <p>Size policies determine how a hash table changes size. These + policies are simple, and there are relatively few sensible + options. An exponential-size policy (with the initial size and + growth factors both powers of 2) works well with a mask-based + range-hashing function (see <a href= + "#hash_policies">Range-Hashing Policies</a>), and is the + hard-wired policy used by Dinkumware [<a href= + "references.html#dinkumware_stl">dinkumware_stl</a>]. A + prime-list based policy works well with a modulo-prime range + hashing function (see <a href="#hash_policies">Range-Hashing + Policies</a>), and is the hard-wired policy used by SGI's + implementation [<a href= + "references.html#sgi_stl">sgi_stl</a>].</p> + + <h3><a name="trigger_policies" id="trigger_policies">Trigger + Policies</a></h3> + + <p>Trigger policies determine when a hash table changes size. + Following is a description of two policies: <i>load-check</i> + policies, and collision-check policies.</p> + + <p>Load-check policies are straightforward. The user specifies + two factors, <i>α<sub>min</sub></i> and + <i>α<sub>max</sub></i>, and the hash table maintains the + invariant that</p> + + <p><i><a name="load_factor_min_max" id= + "load_factor_min_max">α<sub>min</sub> ≤ (number of + stored elements) / (hash-table size) ≤ + α<sub>max</sub></a></i> (1) .</p> + + <p>Collision-check policies work in the opposite direction of + load-check policies. They focus on keeping the number of + collisions moderate and hoping that the size of the table will + not grow very large, instead of keeping a moderate load-factor + and hoping that the number of collisions will be small. A + maximal collision-check policy resizes when the longest + probe-sequence grows too large.</p> + + <p>Consider Figure <a href="#balls_and_bins">Balls and + bins</a>. Let the size of the hash table be denoted by + <i>m</i>, the length of a probe sequence be denoted by + <i>k</i>, and some load factor be denoted by α. We would + like to calculate the minimal length of <i>k</i>, such that if + there were <i>α m</i> elements in the hash table, a probe + sequence of length <i>k</i> would be found with probability at + most <i>1/m</i>.</p> + + <h6 class="c1"><a name="balls_and_bins" id= + "balls_and_bins"><img src="balls_and_bins.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Balls and bins.</h6> + + <p>Denote the probability that a probe sequence of length + <i>k</i> appears in bin <i>i</i> by <i>p<sub>i</sub></i>, the + length of the probe sequence of bin <i>i</i> by + <i>l<sub>i</sub></i>, and assume uniform distribution. Then</p> + + <p><a name="prob_of_p1" id= + "prob_of_p1"><i>p<sub>1</sub></i></a> = (3)</p> + + <p class="c2"><b>P</b>(l<sub>1</sub> ≥ k) =</p> + + <p><i><b>P</b>(l<sub>1</sub> ≥ α ( 1 + k / α - 1 + ) ≤</i> (a)</p> + + <p><i>e ^ ( - ( α ( k / α - 1 )<sup>2</sup> ) /2 + )</i> ,</p> + + <p>where (a) follows from the Chernoff bound [<a href= + "references.html#motwani95random">motwani95random</a>]. To + calculate the probability that <i>some</i> bin contains a probe + sequence greater than <i>k</i>, we note that the + <i>l<sub>i</sub></i> are negatively-dependent [<a href= + "references.html#dubhashi98neg">dubhashi98neg</a>]. Let + <i><b>I</b>(.)</i> denote the indicator function. Then</p> + + <p><a name="at_least_k_i_n_some_bin" id= + "at_least_k_i_n_some_bin"><i><b>P</b>( exists<sub>i</sub> + l<sub>i</sub> ≥ k ) =</i> (3)</a></p> + + <p class="c2"><b>P</b> ( ∑ <sub>i = 1</sub><sup>m</sup> + <b>I</b>(l<sub>i</sub> ≥ k) ≥ 1 ) =</p> + + <p><i><b>P</b> ( ∑ <sub>i = 1</sub><sup>m</sup> <b>I</b> ( + l<sub>i</sub> ≥ k ) ≥ m p<sub>1</sub> ( 1 + 1 / (m + p<sub>1</sub>) - 1 ) ) ≤</i> (a)</p> + + <p class="c2">e ^ ( ( - m p<sub>1</sub> ( 1 / (m p<sub>1</sub>) + - 1 ) <sup>2</sup> ) / 2 ) ,</p> + + <p>where (a) follows from the fact that the Chernoff bound can + be applied to negatively-dependent variables [<a href= + "references.html#dubhashi98neg">dubhashi98neg</a>]. Inserting + <a href="#prob_of_p1">(2)</a> into <a href= + "#at_least_k_i_n_some_bin">(3)</a>, and equating with + <i>1/m</i>, we obtain</p> + + <p><i>k ~ √ ( 2 α</i> ln <i>2 m</i> ln<i>(m) ) + )</i> .</p> + + <h3><a name="imp_pb_ds" id="imp_pb_ds">Implementation</a></h3> + + <p>This sub-subsection describes the implementation of the + above in <tt>pb_ds</tt>. It first describes resize policies and + their decomposition into trigger and size policies, then + describes pre-defined classes, and finally discusses controlled + access the policies' internals.</p> + + <h4>Resize Policies and Their Decomposition</h4> + + <p>Each hash-based container is parametrized by a + <tt>Resize_Policy</tt> parameter; the container derives + <tt><b>public</b></tt>ly from <tt>Resize_Policy</tt>. For + example:</p> + <pre> +<a href="cc_hash_table.html">cc_hash_table</a>< + <b>typename</b> Key, + <b>typename</b> Mapped, + ... + <b>typename</b> Resize_Policy + ...> : + <b>public</b> Resize_Policy +</pre> + + <p>As a container object is modified, it continuously notifies + its <tt>Resize_Policy</tt> base of internal changes + (<i>e.g.</i>, collisions encountered and elements being + inserted). It queries its <tt>Resize_Policy</tt> base whether + it needs to be resized, and if so, to what size.</p> + + <p>Figure <a href="#insert_resize_sequence_diagram1">Insert + resize sequence diagram</a> shows a (possible) sequence diagram + of an insert operation. The user inserts an element; the hash + table notifies its resize policy that a search has started + (point A); in this case, a single collision is encountered - + the table notifies its resize policy of this (point B); the + container finally notifies its resize policy that the search + has ended (point C); it then queries its resize policy whether + a resize is needed, and if so, what is the new size (points D + to G); following the resize, it notifies the policy that a + resize has completed (point H); finally, the element is + inserted, and the policy notified (point I).</p> + + <h6 class="c1"><a name="insert_resize_sequence_diagram1" id= + "insert_resize_sequence_diagram1"><img src= + "insert_resize_sequence_diagram1.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Insert resize sequence diagram.</h6> + + <p>In practice, a resize policy can be usually orthogonally + decomposed to a size policy and a trigger policy. Consequently, + the library contains a single class for instantiating a resize + policy: <a href= + "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + is parametrized by <tt>Size_Policy</tt> and + <tt>Trigger_Policy</tt>, derives <tt><b>public</b></tt>ly from + both, and acts as a standard delegate [<a href= + "references.html#gamma95designpatterns">gamma95designpatterns</a>] + to these policies.</p> + + <p>Figures <a href="#insert_resize_sequence_diagram2">Standard + resize policy trigger sequence diagram</a> and <a href= + "#insert_resize_sequence_diagram3">Standard resize policy size + sequence diagram</a> show sequence diagrams illustrating the + interaction between the standard resize policy and its trigger + and size policies, respectively.</p> + + <h6 class="c1"><a name="insert_resize_sequence_diagram2" id= + "insert_resize_sequence_diagram2"><img src= + "insert_resize_sequence_diagram2.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Standard resize policy trigger sequence + diagram.</h6> + + <h6 class="c1"><a name="insert_resize_sequence_diagram3" id= + "insert_resize_sequence_diagram3"><img src= + "insert_resize_sequence_diagram3.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Standard resize policy size sequence + diagram.</h6> + + <h4>Pre-Defined Policies</h4> + + <p>The library includes the following + instantiations of size and trigger policies:</p> + + <ol> + <li><a href= + "hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + implements a load check trigger policy.</li> + + <li><a href= + "cc_hash_max_collision_check_resize_trigger.html"><tt>cc_hash_max_collision_check_resize_trigger</tt></a> + implements a collision check trigger policy.</li> + + <li><a href= + "hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> + implements an exponential-size policy (which should be used + with mask range hashing).</li> + + <li><a href= + "hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> + implementing a size policy based on a sequence of primes + [<a href="references.html#sgi_stl">sgi_stl</a>] (which should + be used with mod range hashing</li> + </ol> + + <p>Figure <a href="#resize_policy_cd">Resize policy class + diagram</a> gives an overall picture of the resize-related + classes. <a href= + "basic_hash_table.html"><tt>basic_hash_table</tt></a> + is parametrized by <tt>Resize_Policy</tt>, which it subclasses + publicly. This class is currently instantiated only by <a href= + "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>. + <a href= + "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + itself is parametrized by <tt>Trigger_Policy</tt> and + <tt>Size_Policy</tt>. Currently, <tt>Trigger_Policy</tt> is + instantiated by <a href= + "hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>, + or <a href= + "cc_hash_max_collision_check_resize_trigger.html"><tt>cc_hash_max_collision_check_resize_trigger</tt></a>; + <tt>Size_Policy</tt> is instantiated by <a href= + "hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>, + or <a href= + "hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>.</p> + + <h6 class="c1"><a name="resize_policy_cd" id= + "resize_policy_cd"><img src="resize_policy_cd.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Resize policy class diagram.</h6> + + <h4>Controlled Access to Policies' Internals</h4> + + <p>There are cases where (controlled) access to resize + policies' internals is beneficial. <i>E.g.</i>, it is sometimes + useful to query a hash-table for the table's actual size (as + opposed to its <tt>size()</tt> - the number of values it + currently holds); it is sometimes useful to set a table's + initial size, externally resize it, or change load factors.</p> + + <p>Clearly, supporting such methods both decreases the + encapsulation of hash-based containers, and increases the + diversity between different associative-containers' interfaces. + Conversely, omitting such methods can decrease containers' + flexibility.</p> + + <p>In order to avoid, to the extent possible, the above + conflict, the hash-based containers themselves do not address + any of these questions; this is deferred to the resize policies, + which are easier to change or replace. Thus, for example, + neither <a href= + "cc_hash_table.html"><tt>cc_hash_table</tt></a> nor + <a href= + "gp_hash_table.html"><tt>gp_hash_table</tt></a> + contain methods for querying the actual size of the table; this + is deferred to <a href= + "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>.</p> + + <p>Furthermore, the policies themselves are parametrized by + template arguments that determine the methods they support + ([<a href= + "references.html#alexandrescu01modern">alexandrescu01modern</a>] + shows techniques for doing so). <a href= + "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + is parametrized by <tt>External_Size_Access</tt> that + determines whether it supports methods for querying the actual + size of the table or resizing it. <a href= + "hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + is parametrized by <tt>External_Load_Access</tt> that + determines whether it supports methods for querying or + modifying the loads. <a href= + "cc_hash_max_collision_check_resize_trigger.html"><tt>cc_hash_max_collision_check_resize_trigger</tt></a> + is parametrized by <tt>External_Load_Access</tt> that + determines whether it supports methods for querying the + load.</p> + + <p>Some operations, for example, resizing a container at + run time, or changing the load factors of a load-check trigger + policy, require the container itself to resize. As mentioned + above, the hash-based containers themselves do not contain + these types of methods, only their resize policies. + Consequently, there must be some mechanism for a resize policy + to manipulate the hash-based container. As the hash-based + container is a subclass of the resize policy, this is done + through virtual methods. Each hash-based container has a + <tt><b>private</b></tt> <tt><b>virtual</b></tt> method:</p> + <pre> +<b>virtual void</b> + do_resize + (size_type new_size); +</pre> + + <p>which resizes the container. Implementations of + <tt>Resize_Policy</tt> can export public methods for resizing + the container externally; these methods internally call + <tt>do_resize</tt> to resize the table.</p> + + <h2><a name="policy_interaction" id="policy_interaction">Policy + Interaction</a></h2> + + <p>Hash-tables are unfortunately especially susceptible to + choice of policies. One of the more complicated aspects of this + is that poor combinations of good policies can form a poor + container. Following are some considerations.</p> + + <h3><a name="policy_interaction_probe_size_trigger" id= + "policy_interaction_probe_size_trigger">Probe Policies, Size + Policies, and Trigger Policies</a></h3> + + <p>Some combinations do not work well for probing containers. + For example, combining a quadratic probe policy with an + exponential size policy can yield a poor container: when an + element is inserted, a trigger policy might decide that there + is no need to resize, as the table still contains unused + entries; the probe sequence, however, might never reach any of + the unused entries.</p> + + <p>Unfortunately, <tt>pb_ds</tt> cannot detect such problems at + compilation (they are halting reducible). It therefore defines + an exception class <a href= + "insert_error.html"><tt>insert_error</tt></a> to throw an + exception in this case.</p> + + <h3><a name="policy_interaction_hash_trigger" id= + "policy_interaction_hash_trigger">Hash Policies and Trigger + Policies</a></h3> + + <p>Some trigger policies are especially susceptible to poor + hash functions. Suppose, as an extreme case, that the hash + function transforms each key to the same hash value. After some + inserts, a collision detecting policy will always indicate that + the container needs to grow.</p> + + <p>The library, therefore, by design, limits each operation to + one resize. For each <tt>insert</tt>, for example, it queries + only once whether a resize is needed.</p> + + <h3><a name="policy_interaction_eq_sth_hash" id= + "policy_interaction_eq_sth_hash">Equivalence Functors, Storing + Hash Values, and Hash Functions</a></h3> + + <p><a href= + "cc_hash_table.html"><tt>cc_hash_table</tt></a> and + <a href= + "gp_hash_table.html"><tt>gp_hash_table</tt></a> are + parametrized by an equivalence functor and by a + <tt>Store_Hash</tt> parameter. If the latter parameter is + <tt><b>true</b></tt>, then the container stores with each entry + a hash value, and uses this value in case of collisions to + determine whether to apply a hash value. This can lower the + cost of collision for some types, but increase the cost of + collisions for other types.</p> + + <p>If a ranged-hash function or ranged probe function is + directly supplied, however, then it makes no sense to store the + hash value with each entry. <tt>pb_ds</tt>'s container will + fail at compilation, by design, if this is attempted.</p> + + <h3><a name="policy_interaction_size_load_check" id= + "policy_interaction_size_load_check">Size Policies and + Load-Check Trigger Policies</a></h3> + + <p>Assume a size policy issues an increasing sequence of sizes + <i>a, a q, a q<sup>1</sup>, a q<sup>2</sup>, ...</i> For + example, an exponential size policy might issue the sequence of + sizes <i>8, 16, 32, 64, ...</i></p> + + <p>If a load-check trigger policy is used, with loads + <i>α<sub>min</sub></i> and <i>α<sub>max</sub></i>, + respectively, then it is a good idea to have:</p> + + <ol> + <li><i>α<sub>max</sub> ~ 1 / q</i></li> + + <li><i>α<sub>min</sub> < 1 / (2 q)</i></li> + </ol> + + <p>This will ensure that the amortized hash cost of each + modifying operation is at most approximately 3.</p> + + <p><i>α<sub>min</sub> ~ α<sub>max</sub></i> is, in + any case, a bad choice, and <i>α<sub>min</sub> > + α<sub>max</sub></i> is horrendous.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_exponential_size_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_exponential_size_policy.html new file mode 100644 index 000000000..1089b1544 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_exponential_size_policy.html @@ -0,0 +1,183 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>hash_exponential_size_policy Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>hash_exponential_size_policy</tt> Interface</h1> + + <p>A size policy whose sequence of sizes form an exponential + sequence (typically powers of 2)</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Size_Type42920436" id= +"Size_Type42920436"><b>typename</b> Size_Type </a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + + <td>size_t</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#Size_Type42920436"><tt>Size_Type</tt></a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link4" id="link4">Public Methods</a></h2> + + <h3><a name="link5" id="link5">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + hash_exponential_size_policy + (<a href= +"#size_type55424436"><tt>size_type</tt></a> start_size = 8, + <a href= +"#size_type55424436"><tt>size_type</tt></a> grow_factor = 2) +</pre> + </td> + + <td> + <p>Default constructor, or constructor taking a + <span class="c1"><tt>start_size</tt></span>, or + constructor taking a start size and <span class= + "c1"><tt>grow_factor</tt></span>. The policy will use the + sequence of sizes <span class= + "c1"><tt>start_size</tt></span>, <span class= + "c1"><tt>start_size</tt></span> * <span class= + "c1"><tt>grow_factor</tt></span>, <span class= + "c1"><tt>start_size</tt></span> * <span class= + "c1"><tt>grow_factor</tt></span>^2, ...</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class= +"c2"><tt>hash_exponential_size_policy</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h2><a name="link6" id="link6">Protected Methods</a></h2> + + <h3><a name="link7" id="link7">Size methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#size_type55424436"><tt>size_type</tt></a> + get_nearest_larger_size + (<a href= +"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b> +</pre> + </td> + + <td> + <p>Given a size <span class="c1"><tt>size</tt></span>, + returns a size that is larger.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#size_type55424436"><tt>size_type</tt></a> + get_nearest_smaller_size + (<a href= +"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b> +</pre> + </td> + + <td> + <p>Given a size <span class="c1"><tt>size</tt></span>, + returns a size that is smaller.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html new file mode 100644 index 000000000..b22b7b5cf --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html @@ -0,0 +1,583 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>hash_load_check_resize_trigger Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>hash_load_check_resize_trigger</tt> Interface</h1> + + <p>A resize trigger policy based on a load check. It keeps the + load factor between some load factors load_min and + load_max.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="External_Load_Access1313998607" id= +"External_Load_Access1313998607"><b>bool</b> External_Load_Access </a> +</pre> + </td> + + <td> + <p>Specifies whether the load factor can be accessed + externally. The two options have different trade-offs in + terms of flexibility, genericity, and encapsulation.</p> + </td> + + <td><tt><b>false</b></tt></td> + </tr> + + <tr> + <td> + <pre> +<a name="Size_Type42920436" id= +"Size_Type42920436"><b>typename</b> Size_Type </a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + + <td>size_t</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#Size_Type42920436"><tt>Size_Type</tt></a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="external_load_access3976598639" id= +"external_load_access3976598639">external_load_access</a> +</pre> + </td> + + <td> + <pre> +<a href= +"#External_Load_Access1313998607"><tt>External_Load_Access</tt></a> +</pre> + </td> + + <td> + <p>Indicates whether loads can be accessed externally</p> + </td> + </tr> + </table> + + <h2><a name="link4" id="link4">Public Methods</a></h2> + + <h3><a name="link5" id="link5">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + hash_load_check_resize_trigger + (float load_min = 0.125, + float load_max = 0.5) +</pre> + </td> + + <td> + <p>Default constructor, or constructor taking + <span class="c1"><tt>load_min</tt></span> and + <span class="c1"><tt>load_max</tt></span> load factors + between which this policy will keep the actual load.</p> + + <p>It is the responsibility of the user to ensure that + <span class="c1"><tt>load_min</tt></span> is smaller than + <span class="c1"><tt>load_max</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class= +"c2"><tt>hash_load_check_resize_trigger</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + + <tr> + <td> + <pre> + <b>virtual</b> + ~hash_load_check_resize_trigger + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + </table> + + <h3><a name="link6" id="link6">Load Access Methods</a></h3> + + <p>These methods are only available if the external access + parameter is set.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> std::pair<float, float> + get_loads + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a pair of the minimal and maximal loads, + respectively.</p> + + <p>Calling this method will not compile when <a href= + "#External_Load_Access1313998607"><tt>External_Load_Access</tt></a> + == <tt><b>false</b></tt>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + set_loads + (std::pair<float, float> load_pair) +</pre> + </td> + + <td> + <p>Sets the loads through a pair of the minimal and + maximal loads, respectively.</p> + + <p>Calling this method resizes the container, and might + throw an exception. It is the responsibility of the user + to pass appropriate loads to this function. Calling this + method will not compile when <a href= + "#External_Load_Access1313998607"><tt>External_Load_Access</tt></a> + == <tt><b>false</b></tt>.</p> + </td> + </tr> + </table> + + <h2><a name="link7" id="link7">Protected Methods</a></h2> + + <h3><a name="link8" id="link8">Insert Search + Notifications.</a></h3> + + <p>Notifications called during an insert operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link9" id="link9">Find Search + Notifications.</a></h3> + + <p>Notifications called during a find operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link10" id="link10">Erase Search + Notifications.</a></h3> + + <p>Notifications called during an insert operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link11" id="link11">Content Change + Notifications.</a></h3> + + <p>Notifications called when the content of the table changes + in a way that can affect the resize policy.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_inserted + (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries) +</pre> + </td> + + <td> + <p>Notifies an element was inserted. the total number of + entries in the table is <span class= + "c1"><tt>num_entries</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erased + (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries) +</pre> + </td> + + <td> + <p>Notifies an element was erased.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_cleared + () +</pre> + </td> + + <td> + <p>Notifies the table was cleared.</p> + </td> + </tr> + </table> + + <h3><a name="link12" id="link12">Size Change + Notifications.</a></h3> + + <p>Notifications called when the table changes size.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Notifies the table was resized as a result of this + object's signifying that a resize is needed.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_externally_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Notifies the table was resized externally.</p> + </td> + </tr> + </table> + + <h3><a name="link13" id="link13">Queries</a></h3> + + <p>Called to query whether/how to resize.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + is_resize_needed + () <b>const</b> +</pre> + </td> + + <td> + <p>Queries whether a resize is needed.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + is_grow_needed + (<a href="#size_type55424436"><tt>size_type</tt></a> size, + <a href= +"#size_type55424436"><tt>size_type</tt></a> num_entries) <b>const</b> +</pre> + </td> + + <td> + <p>Queries whether a grow is needed.</p> + + <p>This method is called only if this object indicated + resize is needed. The actual <span class= + "c1"><tt>size</tt></span> of the table is <span class= + "c1"><tt>size</tt></span>, and the number of entries in + it is <span class="c1"><tt>num_entries</tt></span>.</p> + </td> + </tr> + </table> + + <h2><a name="link14" id="link14">Private Methods</a></h2> + + <h3><a name="link15" id="link15">Overrides</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <b>void</b> + do_resize + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Resizes to <span class= + "c1"><tt>new_size</tt></span>.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_policy_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_policy_cd.png Binary files differnew file mode 100644 index 000000000..f3122a112 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_policy_cd.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_prime_size_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_prime_size_policy.html new file mode 100644 index 000000000..8976767b4 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_prime_size_policy.html @@ -0,0 +1,149 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>hash_prime_size_policy Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>hash_prime_size_policy</tt> Interface</h1> + + <p>A size policy whose sequence of sizes form a + nearly-exponential sequence of primes.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +size_t +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Methods</a></h2> + + <h3><a name="link4" id="link4">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + hash_prime_size_policy + (<a href= +"#size_type55424436"><tt>size_type</tt></a> start_size = 8) +</pre> + </td> + + <td> + <p>Default constructor, or constructor taking a + <span class="c1"><tt>start_size</tt></span> The policy + will use the sequence of sizes approximately <span class= + "c1"><tt>start_size</tt></span>, <span class= + "c1"><tt>start_size</tt></span> * 2, <span class= + "c1"><tt>start_size</tt></span> * 2^2, ...</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + swap + (<span class= +"c2"><tt>hash_prime_size_policy</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Protected Methods</a></h2> + + <h3><a name="link6" id="link6">Size methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#size_type55424436"><tt>size_type</tt></a> + get_nearest_larger_size + (<a href= +"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b> +</pre> + </td> + + <td> + <p>Given a size <span class="c1"><tt>size</tt></span>, + returns a size that is larger.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#size_type55424436"><tt>size_type</tt></a> + get_nearest_smaller_size + (<a href= +"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b> +</pre> + </td> + + <td> + <p>Given a size <span class="c1"><tt>size</tt></span>, + returns a size that is smaller.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html new file mode 100644 index 000000000..2867595b0 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html @@ -0,0 +1,173 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Tree Text Locality of Reference Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Hash-Based Erase Memory-Use Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of uniform i.i.d. integer keys + into a container, then erases all keys except one. It measures + the final size of the container.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/hash_random_int_erase_mem_usage.cc"><tt>hash_random_int_erase_mem_usage.cc</tt></a> + 2000 2000 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks how containers adjust internally as their + logical size decreases (see <a href="motivation.html#assoc_ers_methods">Motivation::Associative + Containers::Slightly Different Methods::Methods Related to + Erase</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NHG">NHG</a>, <a href="#NHM">NHM</a> and + <a href="#NHL">NHL</a> show the results for the native and + collision-chaining types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a> and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NHG_res_div"> +<div id="NHG_gcc"> +<div id="NHG_hash_random_int_erase_mem_usage_test"> +<div id="NHG_assoc"> +<div id="NHG_Native_456_collision-chaing_456_and_probing_456_hash_random_int_erase_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="hash_random_int_erase_mem_usage_test_gcc.png" alt="no image" /></a></h6>NHG: Native, collision-chaing, and probing, hash random int erase test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_set_ncah- +<tt>std::tr1::unordered_set</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_set- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHM_res_div"> +<div id="NHM_msvc"> +<div id="NHM_hash_random_int_erase_mem_usage_test"> +<div id="NHM_assoc"> +<div id="NHM_Native_456_collision-chaing_456_and_probing_456_hash_random_int_erase_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="hash_random_int_erase_mem_usage_test_msvc.png" alt="no image" /></a></h6>NHM: Native, collision-chaing, and probing, hash random int erase test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_set_ncah- +<tt>stdext::hash_set</tt></li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_set- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHM_res_div"> +<div id="NHM_msvc"> +<div id="NHM_hash_random_int_erase_mem_usage_test"> +<div id="NHM_assoc"> +<div id="NHM_Native_456_collision-chaing_456_and_probing_456_hash_random_int_erase_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="hash_random_int_erase_mem_usage_test_msvc.png" alt="no image" /></a></h6>NHM: Native, collision-chaing, and probing, hash random int erase test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_set_ncah- +<tt>stdext::hash_set</tt></li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_set- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHL_res_div"> +<div id="NHL_local"> +<div id="NHL_hash_random_int_erase_mem_usage_test"> +<div id="NHL_assoc"> +<div id="NHL_Native_456_collision-chaing_456_and_probing_456_hash_random_int_erase_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="hash_random_int_erase_mem_usage_test_local.png" alt="no image" /></a></h6>NHL: Native, collision-chaing, and probing, hash random int erase test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>STL hash-based containers act very differently than trees in + this respect. When erasing numerous keys from an STL + associative-container, the resulting memory user varies greatly + depending on whether the container is tree-based or hash-based. + As noted in <a href="motivation.html#assoc_methods">Motivation::Choice of + Methods</a> , this is a fundamental consequence of the STL's + associative containers' interface, it is not due to a specific + implementation.</p> +<p>(See <a href="priority_queue_text_pop_mem_usage_test.html">Priority Queue + Text <tt>pop</tt> Memory Use Test</a> for a similar phenomenon + regarding priority queues.)</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_gcc.png Binary files differnew file mode 100644 index 000000000..c552506a7 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_local.png Binary files differnew file mode 100644 index 000000000..dbd3ee9d3 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_msvc.png Binary files differnew file mode 100644 index 000000000..8c23d46da --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html new file mode 100644 index 000000000..b6066e7cf --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html @@ -0,0 +1,247 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Hash Random Int Find Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Hash-Based Random-Integer <tt>find</tt> Find Timing + Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with uniform i.i.d. + integer keys into a container, then performs a series of finds + using <tt>find</tt>. It measures the average time + for<tt>find</tt> as a function of the number of values + inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/random_int_find_timing.cc"><tt>random_int_find_timing_test</tt></a> + 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + hash-tables (see <a href="hash_based_containers.html">Design::Associative + Containers::Associative Containers::Hash-Based Containers</a>), + range-hashing functions, and trigger policies (see <a href="hash_based_containers.html#hash_policies">Design::Associative + Containers::Hash-Based Containers::Hash Policies</a> and + <a href="hash_based_containers.html#resize_policies">Design::Associative + Containers::Hash-Based Containers::Resize Policies</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NCCG">NCCG</a>, <a href="#NCCM">NCCM</a>, + and <a href="#NCCL">NCCL</a> show the results for the native + and collision-chaining types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NGPG">NGPG</a>, <a href="#NGPM">NGPM</a>, and <a href="#NGPL">NGPL</a> show the results + for the native and probing types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a> + respectively.</p> +<div id="NCCG_res_div"> +<div id="NCCG_gcc"> +<div id="NCCG_cc_hash_random_int_find_timing_test"> +<div id="NCCG_assoc"> +<div id="NCCG_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCG" id="NCCG"><img src="cc_hash_random_int_find_timing_test_gcc.png" alt="no image" /></a></h6>NCCG: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_map_ncah- +<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NCCM_res_div"> +<div id="NCCM_msvc"> +<div id="NCCM_cc_hash_random_int_find_timing_test"> +<div id="NCCM_assoc"> +<div id="NCCM_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCM" id="NCCM"><img src="cc_hash_random_int_find_timing_test_msvc.png" alt="no image" /></a></h6>NCCM: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_hash_map_ncah- +<tt>stdext::hash_map</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NCCL_res_div"> +<div id="NCCL_local"> +<div id="NCCL_cc_hash_random_int_find_timing_test"> +<div id="NCCL_assoc"> +<div id="NCCL_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCL" id= "NCCL"><img src="cc_hash_random_int_find_timing_test_local.png" alt="no image" /></a></h6>NCCL: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NGPG_res_div"> +<div id="NGPG_gcc"> +<div id="NGPG_gp_hash_random_int_find_timing_test"> +<div id="NGPG_assoc"> +<div id="NGPG_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPG" id="NGPG"><img src="gp_hash_random_int_find_timing_test_gcc.png" alt="no image" /></a></h6>NGPG: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> +</li> +<li> +n_hash_map_ncah- +<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NGPM_res_div"> +<div id="NGPM_msvc"> +<div id="NGPM_gp_hash_random_int_find_timing_test"> +<div id="NGPM_assoc"> +<div id="NGPM_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPM" id="NGPM"><img src="gp_hash_random_int_find_timing_test_msvc.png" alt="no image" /></a></h6>NGPM: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> +</li> +<li> +n_hash_map_ncah- +<tt>stdext::hash_map</tt></li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NGPL_res_div"> +<div id="NGPL_local"> +<div id="NGPL_gp_hash_random_int_find_timing_test"> +<div id="NGPL_assoc"> +<div id="NGPL_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPL" id= "NGPL"><img src="gp_hash_random_int_find_timing_test_local.png" alt="no image" /></a></h6>NGPL: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>In this setting, the choice of underlying hash-table (see + <a href="hash_based_containers.html">Design::Associative + Containers::Hash-Based Containers</a> ) affects performance + most, then the range-hashing scheme (See <a href="hash_based_containers.html#hash_policies">Design::Associative + Containers::Hash-Based Containers::Hash Policies</a> ), and, + only finally, other policies.</p> +<p>When comparing Figures <a href="#NCCG">NCCG</a> and <a href="#NCCM">NCCM</a> to <a href="#NGPG">NGPG</a> and <a href="#NGPM">NGPM</a> , respectively, it is apparent that the + probing containers are less efficient than the + collision-chaining containers (both + <tt>std::tr1::unordered_map</tt> and <tt>stdext::hash_map</tt> + use collision-chaining) in this case.</p> +<p>( <a href="hash_random_int_subscript_insert_timing_test.html">Hash-Based + Random-Integer Subscript Insert Timing Test</a> shows a + different case, where the situation is reversed; <a href="assoc_performance_tests.html#hash_based_types">Observations::Hash-Based + Container Types</a> discusses some further considerations.)</p> +<p>Within each type of hash-table, the range-hashing scheme + affects performance more than other policies; <a href="hash_text_find_find_timing_test.html#observations">Hash-Based + Text <tt>find</tt> Find Timing Test::Observations</a> discusses + this. In Figures <a href="#NCCG">NCCG</a> , <a href="#NCCM">NCCM</a> , <a href="#NGPG">NGPG</a> , and <a href="#NGPM">NGPM</a> , it should be noted that + <tt>std::tr1::unordered_map</tt> and <tt>stdext::hash_map</tt> + are hard-wired currently to mod-based and mask-based schemes, + respectively.</p> +<p><a href="assoc_performance_tests.html#hash_based_types">Observations::Hash-Based + Container Types</a> summarizes some observations on hash-based + containers; <a href="assoc_performance_tests.html#hash_based_policies">Observations::Hash-Based + Containers' Policies</a> summarizes some observations on + hash-based containers' policies.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html new file mode 100644 index 000000000..002516370 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html @@ -0,0 +1,220 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Hash Random Int Subscript Find Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Hash-Based Random-Integer <tt><b>operator</b>[]</tt> + FindTiming Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with uniform i.i.d. + integer keys into a container, then performs a series of finds + using <tt><b>operator</b>[]</tt>. It measures the average time + for <tt><b>operator</b>[]</tt> as a function of the number of + values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/random_int_subscript_find_timing.cc"><tt>hash_random_int_subscript_find_timing_test</tt></a> + 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + hash-tables (see <a href="hash_based_containers.html">Design::Hash-Based Containers</a> + ), range-hashing functions, and trigger policies (see <a href="hash_based_containers.html#hash_policies">Design::Hash-Based + Containers::Hash Policies</a> and <a href="hash_based_containers.html#resize_policies">Design::Hash-Based + Containers::Resize Policies</a> ).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NCCG">NCCG</a>, <a href="#NCCM">NCCM</a>, + and <a href="#NCCL">NCCL</a> show the results for the native + and collision-chaining types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NGPG">NGPG</a>, <a href="#NGPM">NGPM</a>, and <a href="#NGPL">NGPL</a> show the results + for the native and probing types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NCCG_res_div"> +<div id="NCCG_gcc"> +<div id="NCCG_cc_hash_random_int_subscript_timing_test_find"> +<div id="NCCG_assoc"> +<div id="NCCG_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCG" id="NCCG"><img src="cc_hash_random_int_subscript_timing_test_find_gcc.png" alt="no image" /></a></h6>NCCG: Native and collision-chaining hash random int find timing test using <tt><b>operator</b></tt>[] - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_map_ncah- +<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NCCM_res_div"> +<div id="NCCM_msvc"> +<div id="NCCM_cc_hash_random_int_subscript_timing_test_find"> +<div id="NCCM_assoc"> +<div id="NCCM_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCM" id="NCCM"><img src="cc_hash_random_int_subscript_timing_test_find_msvc.png" alt="no image" /></a></h6>NCCM: Native and collision-chaining hash random int find timing test using <tt><b>operator</b></tt>[] - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_hash_map_ncah- +<tt>stdext::hash_map</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NCCL_res_div"> +<div id="NCCL_local"> +<div id="NCCL_cc_hash_random_int_subscript_timing_test_find"> +<div id="NCCL_assoc"> +<div id="NCCL_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCL" id= "NCCL"><img src="cc_hash_random_int_subscript_timing_test_find_local.png" alt="no image" /></a></h6>NCCL: Native and collision-chaining hash random int find timing test using <tt><b>operator</b></tt>[] - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NGPG_res_div"> +<div id="NGPG_gcc"> +<div id="NGPG_gp_hash_random_int_subscript_timing_test_find"> +<div id="NGPG_assoc"> +<div id="NGPG_Native_and_probing_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPG" id="NGPG"><img src="gp_hash_random_int_subscript_timing_test_find_gcc.png" alt="no image" /></a></h6>NGPG: Native and probing hash random int find timing test using <tt><b>operator</b></tt>[] - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_map_ncah- +<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li> +<li> +gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> +</li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NGPM_res_div"> +<div id="NGPM_msvc"> +<div id="NGPM_gp_hash_random_int_subscript_timing_test_find"> +<div id="NGPM_assoc"> +<div id="NGPM_Native_and_probing_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPM" id="NGPM"><img src="gp_hash_random_int_subscript_timing_test_find_msvc.png" alt="no image" /></a></h6>NGPM: Native and probing hash random int find timing test using <tt><b>operator</b></tt>[] - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> +</li> +<li> +n_hash_map_ncah- +<tt>stdext::hash_map</tt></li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NGPL_res_div"> +<div id="NGPL_local"> +<div id="NGPL_gp_hash_random_int_subscript_timing_test_find"> +<div id="NGPL_assoc"> +<div id="NGPL_Native_and_probing_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPL" id= "NGPL"><img src="gp_hash_random_int_subscript_timing_test_find_local.png" alt="no image" /></a></h6>NGPL: Native and probing hash random int find timing test using <tt><b>operator</b></tt>[] - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>This test shows similar results to <a href="hash_random_int_find_find_timing_test.html">Hash-Based + Random-Integer <tt>find</tt> Find Timing Test</a> .</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html new file mode 100644 index 000000000..a15d03ba4 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html @@ -0,0 +1,365 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Hash Random Int Subscript Insert Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Hash-Based Random-Integer <tt><b>operator</b>[]</tt> Insert + Timing Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with uniform i.i.d. + integer keys into a container, using + <tt><b>operator</b>[]</tt>. It measures the average time for + <tt><b>operator</b>[]</tt> as a function of the number of + values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/random_int_subscript_insert_timing.cc"><tt>hash_random_int_subscript_insert_timing_test</tt></a> + 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test primarily checks the effect of different underlying + hash-tables (see <a href="hash_based_containers.html">Design::Associative + Containers::Associative Containers::Hash-Based + Containers</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NCCG">NCCG</a>, <a href="#NCCM">NCCM</a>, + and <a href="#NCCL">NCCL</a> show the results for the native + and collision-chaining types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NGPG">NGPG</a>, <a href="#NGPM">NGPM</a>, and <a href="#NGPL">NGPL</a> show the results + for the native and probing types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a> + respectively; Figures <a href="#CCGPG">CCGPG</a>, <a href="#CCGPM">CCGPM</a>, and <a href="#CCGPL">CCGPL</a> compare the + results for the collision-chaining and probing types of + <tt>pb_ds</tt> only, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a> + respectively.</p> +<div id="NCCG_res_div"> +<div id="NCCG_gcc"> +<div id="NCCG_cc_hash_random_int_subscript_timing_test_insert"> +<div id="NCCG_assoc"> +<div id="NCCG_Native_and_collision-chaining_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCG" id="NCCG"><img src="cc_hash_random_int_subscript_timing_test_insert_gcc.png" alt="no image" /></a></h6>NCCG: Native and collision-chaining hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_hash_map_ncah- +<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NCCM_res_div"> +<div id="NCCM_msvc"> +<div id="NCCM_cc_hash_random_int_subscript_timing_test_insert"> +<div id="NCCM_assoc"> +<div id="NCCM_Native_and_collision-chaining_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCM" id="NCCM"><img src="cc_hash_random_int_subscript_timing_test_insert_msvc.png" alt="no image" /></a></h6>NCCM: Native and collision-chaining hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_map_ncah- +<tt>stdext::hash_map</tt></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NCCL_res_div"> +<div id="NCCL_local"> +<div id="NCCL_cc_hash_random_int_subscript_timing_test_insert"> +<div id="NCCL_assoc"> +<div id="NCCL_Native_and_collision-chaining_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCL" id= "NCCL"><img src="cc_hash_random_int_subscript_timing_test_insert_local.png" alt="no image" /></a></h6>NCCL: Native and collision-chaining hash random int insert timing test using <tt><b>operator</b></tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NGPG_res_div"> +<div id="NGPG_gcc"> +<div id="NGPG_gp_hash_random_int_subscript_timing_test_insert"> +<div id="NGPG_assoc"> +<div id="NGPG_Native_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPG" id="NGPG"><img src="gp_hash_random_int_subscript_timing_test_insert_gcc.png" alt="no image" /></a></h6>NGPG: Native and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> +</li> +<li> +n_hash_map_ncah- +<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NGPM_res_div"> +<div id="NGPM_msvc"> +<div id="NGPM_gp_hash_random_int_subscript_timing_test_insert"> +<div id="NGPM_assoc"> +<div id="NGPM_Native_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPM" id="NGPM"><img src="gp_hash_random_int_subscript_timing_test_insert_msvc.png" alt="no image" /></a></h6>NGPM: Native and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_map_ncah- +<tt>stdext::hash_map</tt></li> +<li> +gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> +</li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NGPL_res_div"> +<div id="NGPL_local"> +<div id="NGPL_gp_hash_random_int_subscript_timing_test_insert"> +<div id="NGPL_assoc"> +<div id="NGPL_Native_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPL" id= "NGPL"><img src="gp_hash_random_int_subscript_timing_test_insert_local.png" alt="no image" /></a></h6>NGPL: Native and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="CCGPG_res_div"> +<div id="CCGPG_gcc"> +<div id="CCGPG_ccgp_hash_random_int_subscript_timing_test_insert"> +<div id="CCGPG_assoc"> +<div id="CCGPG_Collision-chaining_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="CCGPG" id="CCGPG"><img src="ccgp_hash_random_int_subscript_timing_test_insert_gcc.png" alt="no image" /></a></h6>CCGPG: Collision-chaining and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> +</li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="CCGPM_res_div"> +<div id="CCGPM_msvc"> +<div id="CCGPM_ccgp_hash_random_int_subscript_timing_test_insert"> +<div id="CCGPM_assoc"> +<div id="CCGPM_Collision-chaining_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="CCGPM" id="CCGPM"><img src="ccgp_hash_random_int_subscript_timing_test_insert_msvc.png" alt="no image" /></a></h6>CCGPM: Collision-chaining and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> +</li> +<li> +gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="CCGPL_res_div"> +<div id="CCGPL_local"> +<div id="CCGPL_ccgp_hash_random_int_subscript_timing_test_insert"> +<div id="CCGPL_assoc"> +<div id="CCGPL_Collision-chaining_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="CCGPL" id= "CCGPL"><img src="ccgp_hash_random_int_subscript_timing_test_insert_local.png" alt="no image" /></a></h6>CCGPL: Collision-chaining and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>In this setting, as in <a href="hash_text_find_find_timing_test.html">Hash-Based Text + <tt>find</tt> Find Timing Test</a> and <a href="hash_random_int_find_find_timing_test.html">Hash-Based + Random-Integer <tt>find</tt> Find Timing Test</a> , the choice + of underlying hash-table underlying hash-table (see <a href="hash_based_containers.html">Design::Associative + Containers::Hash-Based Containers</a> ) affects performance + most, then the range-hashing scheme (See <a href="hash_based_containers.html#hash_policies">Design::Associative + Containers::Hash-Based Containers::Hash Policies</a> ), and, + only finally, other policies.</p> +<p>There are some differences, however:</p> +<ol> +<li>In this setting, probing tables function sometimes more + efficiently than collision-chaining tables (see Figures + <a href="#CCGPG">CCGPG</a> and <a href="#CCGPM">CCGPM</a> ). + This is explained shortly.</li> +<li>The performance graphs have a "saw-tooth" shape. The + average insert time rises and falls. As values are inserted + into the container, the load factor grows larger. Eventually, + a resize occurs. The reallocations and rehashing are + relatively expensive. After this, the load factor is smaller + than before.</li> +</ol> +<p>Collision-chaining containers use indirection for greater + flexibility; probing containers store values contiguously, in + an array (see Figure <a href="motivation.html#different_underlying_data_structures">Motivation::Different + underlying data structures</a> A and B, respectively). It + follows that for simple data types, probing containers access + their allocator less frequently than collision-chaining + containers, (although they still have less efficient probing + sequences). This explains why some probing containers fare + better than collision-chaining containers in this case.</p> +<p>Within each type of hash-table, the range-hashing scheme + affects performance more than other policies. This is similar + to the situation in <a href="hash_text_find_find_timing_test.html">Hash-Based Text + <tt>find</tt> Find Timing Test</a> and <a href="hash_random_int_find_find_timing_test.html">Hash-Based + Random-Integer <tt>find</tt> Find Timing Test</a>. + Unsurprisingly, however, containers with <u>lower</u> +<i>alpha<sub>max</sub></i> perform <u>worse</u> in this case, + since more re-hashes are performed.</p> +<p><a href="assoc_performance_tests.html#hash_based_types">Observations::Hash-Based + Container Types</a> summarizes some observations on hash-based + containers; <a href="assoc_performance_tests.html#hash_based_policies">Observations::Hash-Based + Containers' Policies</a> summarizes some observations on + hash-based containers' policies.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram.png Binary files differnew file mode 100644 index 000000000..5c37407dd --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram2.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram2.png Binary files differnew file mode 100644 index 000000000..87763caac --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram2.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_ranged_hash_range_hashing_fns.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_ranged_hash_range_hashing_fns.png Binary files differnew file mode 100644 index 000000000..5e0d7f403 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_ranged_hash_range_hashing_fns.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_standard_resize_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_standard_resize_policy.html new file mode 100644 index 000000000..8dbc57ce2 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_standard_resize_policy.html @@ -0,0 +1,795 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>hash_standard_resize_policy Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>hash_standard_resize_policy</tt> Interface</h1> + + <p>A resize policy which delegates operations to size and + trigger policies.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Size_Policy1072992366" id= +"Size_Policy1072992366"><b>class</b> Size_Policy </a> +</pre> + </td> + + <td> + <p>Size policy type.</p> + </td> + + <td><a href= + "hash_exponential_size_policy.html"><span class="c2"><tt>hash_exponential_size_policy</tt></span></a></td> + </tr> + + <tr> + <td> + <pre> +<a name="Trigger_Policy3611271815" id= +"Trigger_Policy3611271815"><b>class</b> Trigger_Policy </a> +</pre> + </td> + + <td> + <p>Trigger policy type.</p> + </td> + + <td><a href= + "hash_load_check_resize_trigger.html"><span class= + "c2"><tt>hash_load_check_resize_trigger</tt></span></a></td> + </tr> + + <tr> + <td> + <pre> +<a name="External_Size_Access1380482982" id= +"External_Size_Access1380482982"><b>bool</b> External_Size_Access </a> +</pre> + </td> + + <td> + <p>Indicates whether physical sizes can be accessed + externally.</p> + </td> + + <td><tt><b>false</b></tt></td> + </tr> + + <tr> + <td> + <pre> +<a name="Size_Type42920436" id= +"Size_Type42920436"><b>typename</b> Size_Type </a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + + <td>size_t</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#Size_Policy1072992366"><tt>Size_Policy</tt></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Types and + Constants</a></h2> + + <h3><a name="link4" id="link4">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#Size_Type42920436"><tt>Size_Type</tt></a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="trigger_policy4019166151" id= +"trigger_policy4019166151">trigger_policy</a> +</pre> + </td> + + <td> + <pre> +<a href="#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> +</pre> + </td> + + <td> + <p>Trigger policy type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="size_policy1385592366" id= +"size_policy1385592366">size_policy</a> +</pre> + </td> + + <td> + <pre> +<a href="#Size_Policy1072992366"><tt>Size_Policy</tt></a> +</pre> + </td> + + <td> + <p>Size policy type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="external_size_access4043083014" id= +"external_size_access4043083014">external_size_access</a> +</pre> + </td> + + <td> + <pre> +<a href= +"#External_Size_Access1380482982"><tt>External_Size_Access</tt></a> +</pre> + </td> + + <td> + <p>Indicates whether sizes can be accessed + externally.</p> + </td> + </tr> + </table> + + <h2><a name="link6" id="link6">Public Methods</a></h2> + + <h3><a name="link7" id="link7">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + hash_standard_resize_policy + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> + hash_standard_resize_policy + (<b>const</b> <a href= +"#Size_Policy1072992366"><tt>Size_Policy</tt></a> &r_size_policy) +</pre> + </td> + + <td> + <p>constructor taking some policies <span class= + "c1"><tt>r_size_policy</tt></span> will be copied by the + <a href="#Size_Policy1072992366"><tt>Size_Policy</tt></a> + object of this object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + hash_standard_resize_policy + (<b>const</b> <a href= +"#Size_Policy1072992366"><tt>Size_Policy</tt></a> &r_size_policy, + <b>const</b> <a href= +"#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> &r_trigger_policy) +</pre> + </td> + + <td> + <p>constructor taking some policies. <span class= + "c1"><tt>r_size_policy</tt></span> will be copied by the + <a href="#Size_Policy1072992366"><tt>Size_Policy</tt></a> + object of this object. <span class= + "c1"><tt>r_trigger_policy</tt></span> will be copied by + the <a href= + "#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> + object of this object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~hash_standard_resize_policy + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + swap + (<span class= +"c2"><tt>hash_standard_resize_policy</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h3><a name="link8" id="link8">Policy Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#Size_Policy1072992366"><tt>Size_Policy</tt></a> & + get_size_policy + () +</pre> + </td> + + <td> + <p>Access to the <a href= + "#Size_Policy1072992366"><tt>Size_Policy</tt></a> object + used.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>const</b> <a href= +"#Size_Policy1072992366"><tt>Size_Policy</tt></a> & + get_size_policy + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access to the <a href= + "#Size_Policy1072992366"><tt>Size_Policy</tt></a> object + used.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href= +"#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> & + get_trigger_policy + () +</pre> + </td> + + <td> + <p>Access to the <a href= + "#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> + object used.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>const</b> <a href= +"#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> & + get_trigger_policy + () <b>const</b> +</pre> + </td> + + <td> + <p>Access to the <a href= + "#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> + object used.</p> + </td> + </tr> + </table> + + <h3><a name="link9" id="link9">Size Access Methods</a></h3> + + <p>These methods are available only if the external size + parameter indicates that external size access is allowed.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + get_actual_size + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns the actual size of the container.</p> + + <p>This method returns the number of entries (used and + unused) in the container. It is different from the + container's size method, which returns the number of used + entries. Calling this method will not compile when + <a href= + "#External_Size_Access1380482982"><tt>External_Size_Access</tt></a> + == <tt><b>false</b></tt>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + resize + (<a href= +"#size_type55424436"><tt>size_type</tt></a> suggested_new_size) +</pre> + </td> + + <td> + <p>Resizes the container to <span class= + "c1"><tt>suggested_new_size</tt></span>, a suggested size + (the actual size will be determined by the <a href= + "#Size_Policy1072992366"><tt>Size_Policy</tt></a> + object).</p> + + <p>Calling this method will not compile when <a href= + "#External_Size_Access1380482982"><tt>External_Size_Access</tt></a> + == <tt><b>false</b></tt>.</p> + </td> + </tr> + </table> + + <h2><a name="link10" id="link10">Protected Methods</a></h2> + + <h3><a name="link11" id="link11">Insert Search + Notifications.</a></h3> + + <p>Notifications called during an insert operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link12" id="link12">Find Search + Notifications.</a></h3> + + <p>Notifications called during a find operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link13" id="link13">Erase Search + Notifications.</a></h3> + + <p>Notifications called during an insert operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link14" id="link14">Content Change + Notifications</a></h3> + + <p>Notifications called when the content of the table changes + in a way that can affect the resize policy.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_inserted + (<a href="#size_type55424436"><tt>size_type</tt></a> num_e) +</pre> + </td> + + <td> + <p>Notifies an element was inserted.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erased + (<a href="#size_type55424436"><tt>size_type</tt></a> num_e) +</pre> + </td> + + <td> + <p>Notifies an element was erased.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_cleared + () +</pre> + </td> + + <td> + <p>Notifies the table was cleared.</p> + </td> + </tr> + </table> + + <h3><a name="link15" id="link15">Size Change + Notifications</a></h3> + + <p>Notifications called when the table changes size.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Notifies the table was resized to <span class= + "c1"><tt>new_size</tt></span>.</p> + </td> + </tr> + </table> + + <h3><a name="link16" id="link16">Queries</a></h3> + + <p>Called to query whether/how to resize.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + is_resize_needed + () <b>const</b> +</pre> + </td> + + <td> + <p>Queries whether a resize is needed.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#size_type55424436"><tt>size_type</tt></a> + get_new_size + (<a href="#size_type55424436"><tt>size_type</tt></a> size, + <a href= +"#size_type55424436"><tt>size_type</tt></a> num_used_e) <b>const</b> +</pre> + </td> + + <td> + <p>Queries what the new <span class= + "c1"><tt>size</tt></span> should be, when the container + is resized naturally. The current size of the container + is <span class="c1"><tt>size</tt></span>, and the number + of used entries within the container is <span class= + "c1"><tt>num_used_e</tt></span>.</p> + </td> + </tr> + </table> + + <h2><a name="link17" id="link17">Private Methods</a></h2> + + <h3><a name="link18" id="link18">Overrides</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <b>void</b> + do_resize + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Resizes to <span class= + "c1"><tt>new_size</tt></span>.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html new file mode 100644 index 000000000..60c30fd34 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html @@ -0,0 +1,164 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Hash Text Find Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Hash-Based Text <tt>find</tt> Find Timing Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into + a container, then performs a series of finds using + <tt>find</tt> . It measures the average time for <tt>find</tt> + as a function of the number of values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/text_find_timing.cc"><tt>text_find_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different range-hashing + functions, trigger policies, and cache-hashing policies (see + <a href="hash_based_containers.html#hash_policies">Design::Associative + Containers::Associative Containers::Hash-Based Containers::Hash + Policies</a> and <a href="hash_based_containers.html#resize_policies">Design::Associative + Containers::Hash-Based Containers::Resize Policies</a> ).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NCCG">NCCG</a>, <a href="#NCCM">NCCM</a> + and <a href="#NCCL">NCCL</a> show the results for the native + and collision-chaining types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respetively.</p> +<div id="NCCG_res_div"> +<div id="NCCG_gcc"> +<div id="NCCG_text_find_timing_test_hash"> +<div id="NCCG_assoc"> +<div id="NCCG_Native_and_collision-chaining_hash_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCG" id="NCCG"><img src="text_find_timing_test_hash_gcc.png" alt="no image" /></a></h6>NCCG: Native and collision-chaining hash text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_map_ncah- +<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_sth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NCCM_res_div"> +<div id="NCCM_msvc"> +<div id="NCCM_text_find_timing_test_hash"> +<div id="NCCM_assoc"> +<div id="NCCM_Native_and_collision-chaining_hash_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCM" id="NCCM"><img src="text_find_timing_test_hash_msvc.png" alt="no image" /></a></h6>NCCM: Native and collision-chaining hash text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_map_ncah- +<tt>stdext::hash_map</tt></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_sth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NCCL_res_div"> +<div id="NCCL_local"> +<div id="NCCL_text_find_timing_test_hash"> +<div id="NCCL_assoc"> +<div id="NCCL_Native_and_collision-chaining_hash_text_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCL" id= "NCCL"><img src="text_find_timing_test_hash_local.png" alt="no image" /></a></h6>NCCL: Native and collision-chaining hash text find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>In this setting, the range-hashing scheme (See <a href="hash_based_containers.html#hash_policies">Design::Associative + Containers::Hash-Based Containers::Hash Policies</a> ) affects + performance more than other policies. As Figure <a href="#NCCG">NCCG</a> shows, containers using mod-based + range-hashing (including the native hash-based container, which + is currently hard-wired to this scheme) have lower performance + than those using mask-based range-hashing. A modulo-based + range-hashing scheme's main benefit is that it takes into + account all hash-value bits. Standard string hash-functions are + designed to create hash values that are nearly-uniform as is [ + <a href="references.html#knuth98sorting">knuth98sorting</a> + ].</p> +<p>Trigger policies (see <a href="hash_based_containers.html#resize_policies">Design::Associative + Containers::Hash-Based Containers::Resize Policies</a> ), + <i>i.e.</i> the load-checks constants, affect performance to a + lesser extent.</p> +<p>Perhaps surprisingly, storing the hash value alongside each + entry affects performance only marginally, at least in + <tt>pb_ds</tt> 's implementation. (Unfortunately, it was not + possible to run the tests with <tt>std::tr1::unordered_map</tt> + 's <tt>cache_hash_code = <b>true</b></tt> , as it appeared to + malfuntion.)</p> +<p><a href="assoc_performance_tests.html#hash_based_policies">Observations::Hash-Based + Containers' Policies</a> summarizes some observations on + hash-based containers' policies.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html new file mode 100644 index 000000000..bfbb3b086 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html @@ -0,0 +1,163 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Hash Skewed Distribution Memory Use Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Hash-Based Skewed-Distribution Random-Integer <tt>find</tt> + Find Timing Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with a markedly + non-uniform i.i.d. integer keys into a container, then performs + a series of finds using <tt>find</tt> . It measures the average + time for <tt>find</tt> as a function of the number of values in + the containers. The keys are generated as follows. First, a + uniform integer is created; it is then shifted left 8 bits.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/hash_zlob_random_int_find_timing.cc"><tt>hash_zlob_random_int_find_timing_test</tt></a> + 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different range-hashing + functions and trigger policies (see <a href="hash_based_containers.html#hash_policies">Design::Associative + Containers::Hash-Based Containers::Hash Policies</a> and + <a href="hash_based_containers.html#resize_policies">Design::Associative + Containers::Hash-Based Containers::Resize Policies</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NHG">NHG</a>, <a href="#NHM">NHM</a>, and + <a href="#NHL">NHL</a> show the results for various hash-based + associative-containers in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NHG_res_div"> +<div id="NHG_gcc"> +<div id="NHG_hash_zlob_random_int_find_timing_test"> +<div id="NHG_assoc"> +<div id="NHG_Skewed-distribution_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="hash_zlob_random_int_find_timing_test_gcc.png" alt="no image" /></a></h6>NHG: Skewed-distribution random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> +</li> +<li> +n_hash_map_ncah- +<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHM_res_div"> +<div id="NHM_msvc"> +<div id="NHM_hash_zlob_random_int_find_timing_test"> +<div id="NHM_assoc"> +<div id="NHM_Skewed-distribution_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="hash_zlob_random_int_find_timing_test_msvc.png" alt="no image" /></a></h6>NHM: Skewed-distribution random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_map_ncah- +<tt>stdext::hash_map</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +<li> +gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map- +<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a> + with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> +</li> +<li> +cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/1</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHL_res_div"> +<div id="NHL_local"> +<div id="NHL_hash_zlob_random_int_find_timing_test"> +<div id="NHL_assoc"> +<div id="NHL_Skewed-distribution_random_int_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="hash_zlob_random_int_find_timing_test_local.png" alt="no image" /></a></h6>NHL: Skewed-distribution random int find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>In this setting, the keys' distribution is so skewed that + the unerlying hash-table type affects performance marginally. + (This is in contrast with <a href="hash_text_find_find_timing_test.html">Hash-Based Text + <tt>find</tt> Find Timing Test</a> , <a href="hash_random_int_find_find_timing_test.html">Hash-Based + Random-Integer <tt>find</tt> Find Timing Test</a> , <a href="hash_random_int_subscript_find_timing_test.html">Hash-Based + Random-Integer Subscript Find Timing Test</a> and <a href="hash_random_int_subscript_insert_timing_test.html">Hash-Based + Random-Integer Subscript Insert Timing Test</a> .)</p> +<p>The range-hashing scheme affects performance dramatically. A + mask-based range-hashing scheme effectively maps all values + into the same bucket. Access degenerates into a search within + an unordered linked-list. In Figures <a href="#NHG">NHG</a> and + <a href="#NHM">NHM</a> , it should be noted that + <tt>std::tr1::unordered_map</tt> and <tt>stdext::hash_map</tt> + are hard-wired currently to mod-based and mask-based schemes, + respectively.</p> +<p>When observing the settings of this test, it is apparent + that the keys' distribution is far from natural. One might ask + if the test is not contrived to show that, in some cases, + mod-based range hashing does better than mask-based range + hashing. This is, in fact just the case. We did not encounter a + more natural case in which mod-based range hashing is better. + In our opnion, real-life key distributions are handled better + with an appropriate hash function and a mask-based + range-hashing function. (<a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_shift_mask.cc"><tt>shift_mask.cc</tt></a> + shows an example of handling this a-priori known skewed + distribution with a mask-based range-hashing function). If hash + performance is bad, a <i>Χ<sup>2</sup></i> test can be used + to check how to transform it into a more uniform + distribution.</p> +<p>For this reason, <tt>pb_ds</tt>'s default range-hashing + function is mask-based.</p> +<p><a href="assoc_performance_tests.html#hash_based_types">Observations::Hash-Based + Container Types</a> summarizes some observations on hash-based + containers; <a href="assoc_performance_tests.html#hash_based_policies">Observations::Hash-Based + Containers' Policies</a> summarizes some observations on + hash-based containers' policies.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..8d170db1a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_local.png Binary files differnew file mode 100644 index 000000000..0be2f00fa --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..874e7a780 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/index.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/index.html new file mode 100644 index 000000000..4c73c2e91 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/index.html @@ -0,0 +1,146 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Policy-Based Data Structures</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Policy-Based Data Structures</h1> + + <h5>Ami Tavory and Vladimir Dreizin, IBM Haifa Research + Laboratories, and Benjamin Kosnik, Red Hat</h5> + + <h5><a href="mailto:pbassoc@gmail.com">pbassoc@gmail.com</a></h5> + + <p>This is a library of policy-based elementary + data structures: associative containers and priority queues. It + is designed for high-performance, flexibility, semantic safety, + and conformance to the corresponding containers in <tt>std</tt> + and std::tr1 (except for some points where it differs by + design).</p> + + <p>The documentation is organized as follows:</p> + + <ol> + <li> + <a href="introduction.html">Introductory</a> + + <ol> + <li><a href="introduction.html">Introduction</a></li> + + <li><a href="motivation.html">Motivation</a></li> + + <li><a href="prerequisites.html">Usage + Prerequisites</a></li> + </ol> + </li> + + <li> + <a href="interface.html">Interface</a> + + <ol> + <li><a href="tutorial.html">Short Tutorial</a></li> + + <li><a href="concepts.html">Concepts</a></li> + + <li><a href="interface.html">Specifics</a></li> + </ol> + </li> + + <li> + <a href="design.html">Design</a> + + <ol> + <li> + <a href="assoc_design.html">Associative Containers</a> + + <ol> + <li><a href="ds_gen.html">Data-Structure + Genericity and Interface</a> </li> + + <li><a href="tree_based_containers.html">Tree-Based + Containers</a></li> + + <li><a href="trie_based_containers.html">Trie-Based + Containers</a></li> + + <li><a href="hash_based_containers.html">Hash-Based + Containers</a></li> + + <li><a href="lu_based_containers.html">List-Based + Containers</a> </li> + </ol> + </li> + + <li><a href="pq_design.html">Priority Queues</a></li> + </ol> + </li> + + <li> + <a href="examples.html">Examples</a> + + <ol> + <li><a href="assoc_examples.html">Associative + Containers</a></li> + + <li><a href="pq_examples.html">Priority Queues</a></li> + </ol> + </li> + + <li> + <a href="tests.html">Tests</a> + + <ol> + <li> + <a href="assoc_tests.html">Associative Containers</a> + + <ol> + <li><a href="assoc_regression_tests.html">Regression + Tests</a></li> + + <li><a href= + "assoc_performance_tests.html">Performance + Tests</a></li> + </ol> + </li> + + <li> + <a href="pq_tests.html">Priority Queues</a> + + <ol> + <li><a href="pq_regression_tests.html">Regression + Tests</a></li> + + <li><a href="pq_performance_tests.html">Performance + Tests</a></li> + </ol> + </li> + </ol> + </li> + + <li> + <a href="misc.html">Misc.</a> + + <ol> + <li><a href="acks.html">Acknowledgments</a></li> + + <li><a href="contact.html">Contact</a></li> + + <li><a href="disclaimer.html">Disclaimer and + Copyright</a></li> + + <li><a href="references.html">References</a></li> + </ol> + </li> + </ol> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_error.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_error.html new file mode 100644 index 000000000..37a89aaf9 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_error.html @@ -0,0 +1,53 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + +<title>insert_error Interface</title> +<meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> +</head> + +<body> +<div id="page"> +<h1><tt>insert_error</tt> Interface</h1> + +<p>An entry cannot be inserted into a container object for logical +reasons (not, e.g., if memory is unavailable, in which case the +allocator's exception will be thrown).</p> + + <p>This exception may be thrown, e.g., when a probe sequence in + a probing hash table does not encounter any free positions, + even though free positions are available.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/exception.hpp"><tt>exception.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="exceptions.html"><span class= +"c2"><tt>insert_error</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram1.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram1.png Binary files differnew file mode 100644 index 000000000..f64764ec9 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram1.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram2.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram2.png Binary files differnew file mode 100644 index 000000000..e4645973e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram2.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram3.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram3.png Binary files differnew file mode 100644 index 000000000..5535c5fe6 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram3.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/interface.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/interface.html new file mode 100644 index 000000000..a48a8bbad --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/interface.html @@ -0,0 +1,446 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + +<title>Interface</title> +<meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> +</head> + +<body> +<div id="page"> +<h1>Interface Specifics</h1> + +<p>Following are the library's interface specifics. <a href= + "tutorial.html">Short Tutorial</a> is a short tutorial, and + <a href="concepts.html">Concepts</a> describes some + concepts.</p> + <hr /> + + <h2><a name="namespaces" id="namespaces">Namespace</a></h2> + + <p>All code is enclosed in namespace <tt>pb_ds</tt>. Nested within + this is namespace <tt>detail</tt>, which contains the parts of this + library that are considered implementation details.</p> + <hr /> + + <h2><a name="containers" id="containers">Containers</a></h2> + + <h3><a name="containers_assoc" id= + "containers_assoc">Associative Containers</a></h3> + + <ol> + <li><a href= + "container_base.html"><tt>container_base</tt></a> - + abstract base class for associative containers.</li> + + <li>Hash-based: + + <ol> + <li><a href= + "basic_hash_table.html"><tt>basic_hash_table</tt></a> + - abstract base class for hash-based + containers</li> + + <li><a href= + "cc_hash_table.html"><tt>cc_hash_table</tt></a> + - concrete collision-chaining hash-based + containers</li> + + <li><a href= + "gp_hash_table.html"><tt>gp_hash_table</tt></a> + - concrete (general) probing hash-based + containers</li> + </ol> + </li> + + <li>Tree-based: + + <ol> + <li><a href= + "basic_tree.html"><tt>basic_tree</tt></a> + - abstract base class for tree and trie based + containers</li> + + <li><a href= + "tree.html"><tt>tree</tt></a> + - concrete base class for tree-based + containers</li> + + <li><a href= + "trie.html"><tt>trie</tt></a> + - concrete base class for trie-based + containers</li> + </ol> + </li> + + <li>List-based: + + <ol> + <li><a href= + "list_update.html"><tt>list_update</tt></a> - + singly-linked list with update-policy container</li> + </ol> + </li> + </ol> + + <h3><a name="containers_pq" id="containers_pq">Priority + Queues</a></h3> + + <ol> + <li><a href="priority_queue.html"><tt>priority_queue</tt></a> + - priority queue</li> + </ol> + <hr /> + + <h2><a name="tag" id="tag">Container Tags and + Traits</a></h2> + + <h3><a name="ds_ts" id="ds_ts">Container Tags</a></h3> + + <h4><a name="ds_ts_common" id="ds_ts_common">Common</a></h4> + + <ol> + <li><a href="container_tag.html"><tt>container_tag</tt></a> - + base class for data structure tags</li> + </ol> + + <h4><a name="ds_ts_assoc" id= + "ds_ts_assoc">Associative-Containers</a></h4> + + <ol> + <li><a href= + "associative_container_tag.html"><tt>associative_container_tag</tt></a> - + base class for associative-container data structure tags</li> + + <li><a href= + "basic_hash_tag.html"><tt>basic_hash_tag</tt></a> - + base class for hash-based structure tags</li> + + <li><a href="cc_hash_tag.html"><tt>cc_hash_tag</tt></a> + - collision-chaining hash structure tag</li> + + <li><a href="gp_hash_tag.html"><tt>gp_hash_tag</tt></a> + - (general) probing hash structure tag</li> + + <li><a href= + "basic_tree_tag.html"><tt>basic_tree_tag</tt></a> + - base class for tree-like structure tags</li> + + <li><a href= + "tree_tag.html"><tt>tree_tag</tt></a> - + base class for tree structure tags</li> + + <li><a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> + - red-black tree structure tag/li></li> + + <li><a href= + "splay_tree_tag.html"><tt>splay_tree_tag</tt></a> - + splay tree structure tag</li> + + <li><a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> + - ordered-vector tree structure tag</li> + + <li><a href= + "trie_tag.html"><tt>trie_tag</tt></a> - + trie structure tag</li> + + <li><a href= + "pat_trie_tag.html"><tt>pat_trie_tag</tt></a> - + PATRICIA trie structure tag</li> + + <li><a href="list_update_tag.html"><tt>list_update_tag</tt></a> - list + (with updates) structure tag</li> + </ol> + + <h4><a name="ds_ts_pq" id="ds_ts_pq">Priority-Queues</a></h4> + + <ol> + <li><a href= + "priority_queue_tag.html"><tt>priority_queue_tag</tt></a> - base + class for priority-queue data structure tags</li> + + <li><a href= + "pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> - + pairing-heap structure tag.</li> + + <li><a href= + "binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> + - binomial-heap structure tag</li> + + <li><a href= + "rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> + - redundant-counter binomial-heap (<i>i.e.</i>, a heap where + binomial trees form a sequence that is similar to a + de-amortized bit-addition algorithm) structure tag</li> + + <li><a href= + "binary_heap_tag.html"><tt>binary_heap_tag</tt></a> - + binary heap (based on an array or an array of nodes) + structure tag</li> + + <li><a href= + "thin_heap_tag.html"><tt>thin_heap_tag</tt></a> - thin + heap (an alternative [<a href= + "references.html#kt99fat_heaps">kt99fat_heaps</a>] to + Fibonacci heap) data structure tag.</li> + </ol> + + <h3><a name="ds_inv_tag" id="ds_inv_tag">Invalidation-Guarantee + Tags</a></h3> + + <ol> + <li><a href= + "basic_invalidation_guarantee.html"><tt>basic_invalidation_guarantee</tt></a> + - weakest invalidation guarantee</li> + + <li><a href= + "point_invalidation_guarantee.html"><tt>point_invalidation_guarantee</tt></a> + - stronger invalidation guarantee</li> + + <li><a href= + "range_invalidation_guarantee.html"><tt>range_invalidation_guarantee</tt></a> + - strongest invalidation guarantee</li> + </ol> + + <h3><a name="container_traits" id="container_traits">Container + Traits</a></h3> + + <ol> + <li><a href="pq_container_traits.html"><tt>container_traits</tt></a> - + traits for determining underlying data structure + properties</li> + </ol> + <hr /> + + <h2><a name="ds_policy_classes" id= + "ds_policy_classes">Container Policy Classes</a></h2> + + <h3><a name="hash_related_policies" id= + "hash_related_policies">Hash Policies</a></h3> + + <h4>Hash and Probe Policies</h4> + + <ol> + <li>Hash Functions: + + <ol> + <li><a href="null_hash_fn.html"><tt>null_hash_fn</tt></a> + - type indicating one-step range-hashing</li> + </ol> + </li> + + <li>Range-Hashing Functions: + + <ol> + <li><a href="sample_range_hashing.html">Sample + range-hashing function</a> - interface required of a + range-hashing functor</li> + + <li><a href= + "direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> + - (bit) mask-based range hashing functor</li> + + <li><a href= + "direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a> + - modulo-based range hashing functor</li> + </ol> + </li> + + <li>Probe Functions: + + <ol> + <li><a href="sample_probe_fn.html">Sample probe + function</a> - interface required of a probe functor</li> + + <li><a href= + "null_probe_fn.html"><tt>null_probe_fn</tt></a> - type + indicating one-step ranged-probe</li> + + <li><a href= + "linear_probe_fn.html"><tt>linear_probe_fn</tt></a> - + linear-probe functor</li> + + <li><a href= + "quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>- + quadratic-probe functor</li> + </ol> + </li> + + <li>Ranged-Hash Functions: + + <ol> + <li><a href="sample_ranged_hash_fn.html">Sample + ranged-hash function</a> - interface required of a + ranged-hash functor</li> + </ol> + </li> + + <li>Ranged-Probe Functions: + + <ol> + <li><a href="sample_ranged_probe_fn.html">Sample + ranged-probe function</a> - interface required of a + ranged-probe functor</li> + </ol> + </li> + </ol> + + <h4>Resize Policies</h4> + <ol> + <li>Resize Policies: + + <ol> + <li><a href="sample_resize_policy.html">Sample resize + policy</a> - interface required of a resize policy</li> + + <li><a href= + "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + - standard resize policy</li> + </ol> + </li> + + <li>Size Policies: + + <ol> + <li><a href="sample_size_policy.html">Sample size + policy</a> - interface required of a size policy</li> + + <li><a href= + "hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> + - exponential size policy (typically used with (bit) mask + range-hashing)</li> + + <li><a href= + "hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a> + - prime size policy (typically used with modulo + range-hashing)</li> + </ol> + </li> + + <li>Trigger Policies: + + <ol> + <li><a href="sample_resize_trigger.html">Sample trigger + policy</a> - interface required of a trigger policy</li> + + <li><a href= + "hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + - trigger policy based on load checks</li> + + <li><a href= + "cc_hash_max_collision_check_resize_trigger.html"><tt>cc_hash_max_collision_check_resize_trigger</tt></a> + - trigger policy based on collision checks</li> + </ol> + </li> + </ol> + + <h3><a name="tree_related_policies" id= + "tree_related_policies">Tree Policies</a></h3> + + <h4>Tree Node-Update Policies</h4> + + +<ol> +<li><a href="sample_tree_node_update.html">Sample node +updater policy</a> - interface required of a tree +node-updating functor</li> + +<li><a href= + "null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +- null policy indicating no updates are required</li> + +<li><a href= + "tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a> +- updater enabling order statistics queries</li> +</ol> + +<h3><a name="trie_related_policies" id= + "trie_related_policies">Trie Policies</a></h3> + + +<h4>Trie Element-Access Traits</h4> + + <ol> + <li><a href="sample_trie_e_access_traits.html">Sample + element-access traits</a> - interface required of + element-access traits</li> + + <li><a href= + "string_trie_e_access_traits.html"><tt>string_trie_e_access_traits</tt></a> + - String element-access traits</li> + </ol> + + <h4>Trie Node-Update Policies</h4> + + +<ol> +<li><a href="sample_trie_node_update.html">Sample node +updater policy</a> - interface required of a trie node +updater</li> + +<li><a href= + "null_trie_node_update.html"><tt>null_trie_node_update</tt></a> +- null policy indicating no updates are required</li> + +<li><a href= + "trie_prefix_search_node_update.html"><tt>trie_prefix_search_node_update</tt></a> +- updater enabling prefix searches</li> + +<li><a href= + "trie_order_statistics_node_update.html"><tt>trie_order_statistics_node_update</tt></a> +- updater enabling order statistics queries</li> +</ol> + +<h3><a name="list_related_policies" id= + "list_related_policies">List Policies</a></h3> + +<h4>List Update Policies</h4> + + + <ol> + <li><a href="sample_update_policy.html">Sample list update + policy</a> - interface required of a list update policy</li> + + <li><a href= + "move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> + - move-to-front update algorithm</li> + + <li><a href= + "counter_lu_policy.html"><tt>counter_lu_policy</tt></a> - + counter update algorithm</li> + </ol> + + <h3><a name="ds_pol" id="ds_pol">Mapped-Type Policies</a></h3> + + + <ol> + <li><a href= + "null_mapped_type.html"><tt>null_mapped_type</tt></a> - data + policy indicating that a container is a "set"</li> + </ol> + <hr /> + + <h2><a name="exceptions" id="exceptions">Exceptions</a></h2> + + + <ol> + <li><a href="exceptions.html"><tt>container_error</tt></a> + - base class for all policy-based data structure errors</li> + + <li><a href= + "insert_error.html"><tt>insert_error</tt></a></li> + + <li><a href="join_error.html"><tt>join_error</tt></a></li> + + <li><a href= + "resize_error.html"><tt>resize_error</tt></a></li> + </ol> + + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/introduction.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/introduction.html new file mode 100644 index 000000000..b3ccbd76a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/introduction.html @@ -0,0 +1,120 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Introduction</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Introduction</h1> + + <p>This section describes what problems the library attempts to + solve. <a href="motivation.html">Motivation</a> describes the + reasons we think it solves these problems better than similar + libraries.</p> + + <h2><a name="assoc" id="assoc">Associative Containers</a></h2> + + <ol> + <li>Associative containers depend on their policies to a very + large extent. Implicitly hard-wiring policies can hamper their + performance and limit their functionality. An efficient + hash-based container, for example, requires policies for + testing key equivalence, hashing keys, translating hash + values into positions within the hash table, and determining + when and how to resize the table internally. A tree-based + container can efficiently support order statistics, + <i>i.e.</i>, the ability to query what is the order of each + key within the sequence of keys in the container, but only if + the container is supplied with a policy to internally update + meta-data. There are many other such examples.<p></p></li> + + <li>Ideally, all associative containers would share the same + interface. Unfortunately, underlying data structures and + mapping semantics differentiate between different containers. + For example, suppose one writes a generic function + manipulating an associative container <tt>Cntnr</tt>: + <pre> +template<typename Cntnr> + void + some_op_sequence(Cntnr& r_cnt) + { + ... + } +</pre> + +then what can one assume about <tt>Cntnr</tt>? The answer +varies according to its underlying data structure. If the +underlying data structure of <tt>Cntnr</tt> is based on a tree or +trie, then the order of elements is well defined; otherwise, it is +not, in general. If the underlying data structure of <tt>Cntnr</tt> +is based on a collision-chaining hash table, then modifying +r_<tt>Cntnr</tt> will not invalidate its iterators' order; if the +underlying data structure is a probing hash table, then this is not +the case. If the underlying data structure is based on a tree or +trie, then <tt>r_cnt</tt> can efficiently be split; otherwise, it +cannot, in general. If the underlying data structure is a red-black +tree, then splitting <tt>r_cnt</tt> is exception-free; if it is an +ordered-vector tree, exceptions can be thrown. + <p></p></li> + </ol> + + <h2><a name="pq" id="pq">Priority Queues</a></h2> + + <p>Priority queues are useful when one needs to efficiently + access a minimum (or maximum) value as the set of values + changes.</p> + + <ol> + <li>Most useful data structures for priority queues have a + relatively simple structure, as they are geared toward + relatively simple requirements. Unfortunately, these structures + do not support access to an arbitrary value, which turns out to + be necessary in many algorithms. Say, decreasing an arbitrary + value in a graph algorithm. Therefore, some extra mechanism is + necessary and must be invented for accessing arbitrary + values. There are at least two alternatives: embedding an + associative container in a priority queue, or allowing + cross-referencing through iterators. The first solution adds + significant overhead; the second solution requires a precise + definition of iterator invalidation. Which is the next + point...<p></p></li> + + <li>Priority queues, like hash-based containers, store values in + an order that is meaningless and undefined externally. For + example, a <tt>push</tt> operation can internally reorganize the + values. Because of this characteristic, describing a priority + queues' iterator is difficult: on one hand, the values to which + iterators point can remain valid, but on the other, the logical + order of iterators can change unpredictably.<p></p></li> + + <li>Roughly speaking, any element that is both inserted to a + priority queue (<i>e.g.</i>, through <tt>push</tt>) and removed + from it (<i>e.g.</i>, through <tt>pop</tt>), incurs a + logarithmic overhead (in the amortized sense). Different + underlying data structures place the actual cost differently: + some are optimized for amortized complexity, whereas others + guarantee that specific operations only have a constant + cost. One underlying data structure might be chosen if modifying + a value is frequent (Dijkstra's shortest-path algorithm), + whereas a different one might be chosen + otherwise. Unfortunately, an array-based binary heap - an + underlying data structure that optimizes (in the amortized + sense) <tt>push</tt> and <tt>pop</tt> operations, differs from + the others in terms of its invalidation guarantees. Other design + decisions also impact the cost and placement of the overhead, at + the expense of more difference in the the kinds of operations + that the underlying data structure can support. These + differences pose a challenge when creating a uniform interface + for priority queues.<p></p></li> + </ol> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_cd.png Binary files differnew file mode 100644 index 000000000..1f9d1243c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_cd.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_erase.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_erase.png Binary files differnew file mode 100644 index 000000000..940a27f71 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_erase.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/join_error.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/join_error.html new file mode 100644 index 000000000..f3e3eaf97 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/join_error.html @@ -0,0 +1,48 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + +<title>join_error Interface</title> +<meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> +</head> + +<body> +<div id="page"> +<h1><tt>join_error</tt> Interface</h1> + +<p>A join cannot be performed logical reasons (i.e., the ranges of the + two container objects + being joined + overlaps.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/exception.hpp"><tt>exception.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> +<pre><a href="exceptions.html"><span class="c2"><tt>join_error</tt></span></a> +</pre> + </td> + +<td> +<p>public</p> +</td> +</tr> + </table> + </div> + </body> + </html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/linear_probe_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/linear_probe_fn.html new file mode 100644 index 000000000..6387d3a33 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/linear_probe_fn.html @@ -0,0 +1,140 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>linear_probe_fn Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>linear_probe_fn</tt> Interface</h1> + + <p>A probe sequence policy using fixed increments.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Size_Type42920436" id= +"Size_Type42920436"><b>typename</b> Size_Type </a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + + <td>size_t</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#Size_Type42920436"><tt>Size_Type</tt></a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link4" id="link4">Public Methods</a></h2> + + <h3><a name="link5" id="link5">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class="c2"><tt>linear_probe_fn</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h2><a name="link6" id="link6">Protected Methods</a></h2> + + <h3><a name="link7" id="link7">Offset Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + <b>operator</b>() + (<a href= +"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b> +</pre> + </td> + + <td> + <p>Returns the <span class="c1"><tt>i</tt></span>-th + offset from the hash value.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update.html new file mode 100644 index 000000000..434e82f42 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update.html @@ -0,0 +1,316 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>list_update Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>list_update</tt> Interface</h1> + + <p>A list-update based associative container.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Key2501" id="Key2501"><b>typename</b> Key</a> +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a> +</pre> + </td> + + <td> + <p>Mapped type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Eq_Fn60085" id="Eq_Fn60085"><b>class</b> Eq_Fn </a> +</pre> + </td> + + <td> + <p>Equivalence functor.</p> + </td> + + <td> + <pre> +std::equal_to<<a href="#Key2501"><tt>Key</tt></a>> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Update_Policy1671938590" id= +"Update_Policy1671938590"><b>class</b> Update_Policy </a> +</pre> + </td> + + <td> + <p>Update policy (determines when an element will be + moved to the front of the list.</p> + </td> + + <td><a href="move_to_front_lu_policy.html"><span class= + "c2"><tt>move_to_front_lu_policy</tt></span></a></td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator </a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td> + <pre> +std::allocator<<b>char</b>> +</pre> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="container_base.html"><span class= +"c2"><tt>container_base</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Types and + Constants</a></h2> + + <h3><a name="link4" id="link4">Policy definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="eq_fn80245" id="eq_fn80245">eq_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Eq_Fn60085"><tt>Eq_Fn</tt></a> +</pre> + </td> + + <td> + <p>Equivalence functor type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="update_policy894603998" id= +"update_policy894603998">update_policy</a> +</pre> + </td> + + <td> + <pre> +<a href="#Update_Policy1671938590"><tt>Update_Policy</tt></a> +</pre> + </td> + + <td> + <p>List update policy type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="allocator48440069" id="allocator48440069">allocator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Allocator35940069"><tt>Allocator</tt></a> +</pre> + </td> + + <td> + <p><a href="#Allocator35940069"><tt>Allocator</tt></a> + type.</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Public Methods</a></h2> + + <h3><a name="link6" id="link6">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + list_update + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + list_update + (It first_it, + It last_it) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of + value_types. The value_types between <span class= + "c1"><tt>first_it</tt></span> and <span class= + "c1"><tt>last_it</tt></span> will be inserted into the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + list_update + (<b>const</b> <span class= +"c2"><tt>list_update</tt></span> &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~list_update + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<span class="c2"><tt>list_update</tt></span> & + <b>operator</b>= + (<b>const</b> <span class= +"c2"><tt>list_update</tt></span> &other) +</pre> + </td> + + <td> + <p>Assignment operator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class="c2"><tt>list_update</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update_tag.html new file mode 100644 index 000000000..f04aaeacb --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>list_update_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>list_update_tag</tt> Interface</h1> + + <p>List-update data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="associative_container_tag.html"><span class= +"c2"><tt>associative_container_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu.png Binary files differnew file mode 100644 index 000000000..7c96dcaf6 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu_based_containers.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu_based_containers.html new file mode 100644 index 000000000..c8693437d --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu_based_containers.html @@ -0,0 +1,229 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>List-Based Containers</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>List-Update Design</h1> + + <h2><a name="overview" id="overview">Overview</a></h2> + + <p>The list-based container has the following declaration:</p> + <pre> +<b>template</b>< + <b>typename</b> Key, + <b>typename</b> Mapped, + <b>typename</b> Eq_Fn = std::equal_to<Key>, + <b>typename</b> Update_Policy = <a href= +"move_to_front_lu_policy.html">move_to_front_lu_policy<></a>, + <b>typename</b> Allocator = std::allocator<<b>char</b>> > +<b>class</b> <a href="list_update.html">list_update</a>; +</pre> + + <p>The parameters have the following meaning:</p> + + <ol> + <li><tt>Key</tt> is the key type.</li> + + <li><tt>Mapped</tt> is the mapped-policy, and is explained in + <a href="tutorial.html#assoc_ms">Tutorial::Associative + Containers::Associative Containers Others than Maps</a>.</li> + + <li><tt>Eq_Fn</tt> is a key equivalence functor.</li> + + <li><tt>Update_Policy</tt> is a policy updating positions in + the list based on access patterns. It is described in the + following subsection.</li> + + <li><tt>Allocator</tt> is an allocator + type.</li> + </ol> + + <p>A list-based associative container is a container that + stores elements in a linked-list. It does not order the + elements by any particular order related to the keys. + List-based containers are primarily useful for creating + "multimaps" (see <a href= + "motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Avoiding Multiple Keys</a> and <a href= + "tutorial.html#assoc_ms">Tutorial::Associative + Containers::Associative Containers Others than Maps</a>). In + fact, list-based containers are designed in <tt>pb_ds</tt> + expressly for this purpose. This is explained further in + <a href="#mmaps">Use for "Multimaps"</a>.</p> + + <p>List-based containers might also be useful for some rare + cases, where a key is encapsulated to the extent that only + key-equivalence can be tested. Hash-based containers need to + know how to transform a key into a size type, and tree-based + containers need to know if some key is larger than another. + List-based associative containers, conversely, only need to + know if two keys are equivalent.</p> + + <p>Since a list-based associative container does not order + elements by keys, is it possible to order the list in some + useful manner? Remarkably, many on-line competitive [<a href= + "references.html#motwani95random">motwani95random</a>] + algorithms exist for reordering lists to reflect access + prediction [<a href= + "references.html#andrew04mtf">andrew04mtf</a>].</p> + + <h2><a name="list_updates" id="list_updates">List + Updates</a></h2> + + <h3><a name="general" id="general">General Terms</a></h3> + + <p>Figure <a href="#simple_list">A simple list</a> shows a + simple list of integer keys. If we search for the integer 6, we + are paying an overhead: the link with key 6 is only the fifth + link; if it were the first link, it could be accessed + faster.</p> + + <h6 class="c1"><a name="simple_list" id="simple_list"><img src= + "simple_list.png" alt="no image" /></a></h6> + + <h6 class="c1">A simple list.</h6> + + <p>List-update algorithms reorder lists as elements are + accessed. They try to determine, by the access history, which + keys to move to the front of the list. Some of these algorithms + require adding some metadata alongside each entry.</p> + + <p>For example, Figure <a href="#lu">The counter algorithm</a> + -A shows the counter algorithm. Each node contains both a key + and a count metadata (shown in bold). When an element is + accessed (<i>e.g.</i> 6) its count is incremented, as shown in + Figure <a href="#lu">The counter algorithm</a> -B. If the count + reaches some predetermined value, say 10, as shown in Figure + <a href="#lu">The counter algorithm</a> -C, the count is set to + 0 and the node is moved to the front of the list, as in Figure + <a href="#lu">The counter algorithm</a> -D.</p> + + <h6 class="c1"><a name="lu" id="lu"><img src="lu.png" alt= + "no image" /></a></h6> + + <h6 class="c1">The counter algorithm.</h6> + + <h3><a name="imp_pb_ds" id="imp_pb_ds">Implementation</a></h3> + + <p><tt>pb_ds</tt> allows instantiating lists with policies + implementing any algorithm moving nodes to the front of the + list (policies implementing algorithms interchanging nodes are + unsupported).</p> + + <p>Associative containers based on lists are parametrized by a + <tt>Update_Policy</tt> parameter. This parameter defines the + type of metadata each node contains, how to create the + metadata, and how to decide, using this metadata, whether to + move a node to the front of the list. A list-based associative + container object derives (publicly) from its update policy. + Figure <a href="#update_policy_cd">A list and its update + policy</a> shows the scheme, as well as some predefined + policies (which are explained below).</p> + + <h6 class="c1"><a name="update_policy_cd" id= + "update_policy_cd"><img src="update_policy_cd.png" alt= + "no image" /></a></h6> + + <h6 class="c1">A list and its update policy.</h6> + + <p>An instantiation of <tt>Update_Policy</tt> must define + internally <tt>update_metadata</tt> as the metadata it + requires. Internally, each node of the list contains, besides + the usual key and data, an instance of <tt><b>typename</b> + Update_Policy::update_metadata</tt>.</p> + + <p>An instantiation of <tt>Update_Policy</tt> must define + internally two operators:</p> + <pre> +update_metadata +<b>operator</b>()(); + +<b>bool</b> +<b>operator</b>()(update_metadata &); +</pre> + + <p>The first is called by the container object, when creating a + new node, to create the node's metadata. The second is called + by the container object, when a node is accessed (<i>e.g.</i>, + when a find operation's key is equivalent to the key of the + node), to determine whether to move the node to the front of + the list.</p> + + <p>The library contains two predefined implementations of + list-update policies [<a href= + "references.html#andrew04mtf">andrew04mtf</a>]. The first is + <a href= + "counter_lu_policy.html"><tt>counter_lu_policy</tt></a>, which + implements the counter algorithm described above. The second is + <a href= + "move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>, + which unconditionally move an accessed element to the front of + the list. The latter type is very useful in <tt>pb_ds</tt>, + since there is no need to associate metadata with each element + (this is explained further in <a href="#mmaps">Use for + "Multimaps"</a>).</p> + + <h2><a name="mmaps" id="mmaps">Use for "Multimaps"</a></h2> + + <p>In <tt>pb_ds</tt>, there are no equivalents for the STL's + multimaps and multisets; instead one uses an associative + container mapping primary keys to secondary keys (see <a href= + "motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Alternative to Multiple Equivalent Keys</a> and + <a href="tutorial.html#assoc_ms">Tutorial::Associative + Containers::Associative Containers Others than Maps</a>).</p> + + <p>List-based containers are especially useful as associative + containers for secondary keys. In fact, they are implemented + here expressly for this purpose.</p> + + <p>To begin with, these containers use very little per-entry + structure memory overhead, since they can be implemented as + singly-linked lists. (Arrays use even lower per-entry memory + overhead, but they are less flexible in moving around entries, + and have weaker invalidation guarantees).</p> + + <p>More importantly, though, list-based containers use very + little per-container memory overhead. The memory overhead of an + empty list-based container is practically that of a pointer. + This is important for when they are used as secondary + associative-containers in situations where the average ratio of + secondary keys to primary keys is low (or even 1).</p> + + <p>In order to reduce the per-container memory overhead as much + as possible, they are implemented as closely as possible to + singly-linked lists.</p> + + <ol> + <li>List-based containers do not store internally the number + of values that they hold. This means that their <tt>size</tt> + method has linear complexity (just like <tt>std::list</tt>). + Note that finding the number of equivalent-key values in an + STL multimap also has linear complexity (because it must be + done, <i>e.g.</i>, via <tt>std::distance</tt> of the + multimap's <tt>equal_range</tt> method), but usually with + higher constants.</li> + + <li>Most associative-container objects each hold a policy + object (<i>e.g.</i>, a hash-based container object holds a + hash functor). List-based containers, conversely, only have + class-wide policy objects.</li> + </ol> + + <p>See also <a href= + "assoc_performance_tests.html#msc">Associative-Container + Performance Tests::Observations::Mapping-Semantics + Considerations</a>.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/misc.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/misc.html new file mode 100644 index 000000000..01029e134 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/misc.html @@ -0,0 +1,26 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Misc.</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Misc.</h1> + + <p><a href="acks.html" title="Acknowledgements">Acks</a> + contains acknowledgments; <a href="contact.html">Contact</a> + contains contact information;<a href= + "disclaimer.html">Disclaimer and Copyright</a> is a standard + disclaimer, and <a href="references.html">References</a> + contains references.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/motivation.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/motivation.html new file mode 100644 index 000000000..627317217 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/motivation.html @@ -0,0 +1,993 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Motivation</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Motivation</h1> + + <p>Many fine associative-container libraries were already + written, most notably, the STL's associative containers. Why + then write another library? This section shows some possible + advantages of this library, when considering the challenges in + <a href="introduction.html">Introduction</a>. Many of these + points stem from the fact that the STL introduced + associative-containers in a two-step process (first + standardizing tree-based containers, only then adding + hash-based containers, which are fundamentally different), did + not standardize priority queues as containers, and (in our + opinion) overloads the iterator concept.</p> + + <h2><a name="assoc" id="assoc">Associative Containers</a></h2> + + <h3><a name="assoc_policies" id="assoc_policies">More + Configuration Choices</a></h3> + + <p>Associative containers require a relatively large number of + policies to function efficiently in various settings. In some + cases this is needed for making their common operations more + efficient, and in other cases this allows them to support a + larger set of operations</p> + + <ol> + <li>Hash-based containers, for example, support look-up and + insertion methods (<i>e.g.</i>, <tt>find</tt> and + <tt>insert</tt>). In order to locate elements quickly, they + are supplied a hash functor, which instruct how to transform + a key object into some size type; <i>e.g.</i>, a hash functor + might transform <tt>"hello"</tt> into <tt>1123002298</tt>. A + hash table, though, requires transforming each key object + into some size-type type in some specific domain; + <i>e.g.</i>, a hash table with a 128-long table might + transform <tt>"hello"</tt> into position 63. The policy by + which the hash value is transformed into a position within + the table can dramatically affect performance (see <a href= + "hash_based_containers.html#hash_policies">Design::Associative + Containers::Hash-Based Containers::Hash Policies</a>). + Hash-based containers also do not resize naturally (as + opposed to tree-based containers, for example). The + appropriate resize policy is unfortunately intertwined with + the policy that transforms hash value into a position within + the table (see <a href= + "hash_based_containers.html#resize_policies">Design::Associative + Containers::Hash-Based Containers::Resize Policies</a>). + + <p><a href= + "assoc_performance_tests.html#hash_based">Associative-Container + Performance Tests::Hash-Based Containers</a> quantifies + some of these points.</p> + </li> + + <li>Tree-based containers, for example, also support look-up + and insertion methods, and are primarily useful when + maintaining order between elements is important. In some + cases, though, one can utilize their balancing algorithms for + completely different purposes. + + <p>Figure <a href="#node_invariants">Metadata for + order-statistics and interval intersections</a>-A, for + example, shows a tree whose each node contains two entries: + a floating-point key, and some size-type <i>metadata</i> + (in bold beneath it) that is the number of nodes in the + sub-tree. (<i>E.g.</i>, the root has key 0.99, and has 5 + nodes (including itself) in its sub-tree.) A container based + on this data structure can obviously answer efficiently + whether 0.3 is in the container object, but it can also + answer what is the order of 0.3 among all those in the + container object [<a href= + "references.html#clrs2001">clrs2001</a>] (see <a href= + "assoc_examples.html#tree_like_based">Associative Container + Examples::Tree-Like-Based Containers (Trees and + Tries)</a>).</p> + + <p>As another example, Figure <a href= + "#node_invariants">Metadata for order-statistics and + interval intersections</a>-B shows a tree whose each node + contains two entries: a half-open geometric line interval, + and a number <i>metadata</i> (in bold beneath it) that is + the largest endpoint of all intervals in its sub-tree. + (<i>E.g.</i>, the root describes the interval <i>[20, + 36)</i>, and the largest endpoint in its sub-tree is 99.) A + container based on this data structure can obviously answer + efficiently whether <i>[3, 41)</i> is in the container + object, but it can also answer efficiently whether the + container object has intervals that intersect <i>[3, + 41)</i> (see <a href= + "assoc_examples.html#tree_like_based">Associative Container + Examples::Tree-Like-Based Containers (Trees and + Tries)</a>). These types of queries are very useful in + geometric algorithms and lease-management algorithms.</p> + + <p>It is important to note, however, that as the trees are + modified, their internal structure changes. To maintain + these invariants, one must supply some policy that is aware + of these changes (see <a href= + "tree_based_containers.html#invariants">Design::Associative + Containers::Tree-Based Containers::Node Invariants</a>); + without this, it would be better to use a linked list (in + itself very efficient for these purposes).</p> + + <p><a href= + "assoc_performance_tests.html#tree_like_based">Associative-Container + Performance Tests::Tree-Like-Based Containers</a> + quantifies some of these points.</p> + </li> + </ol> + + <h6 class="c1"><a name="node_invariants" id= + "node_invariants"><img src="node_invariants.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Metadata for order-statistics and interval + intersections.</h6> + + <h3><a name="assoc_ds_genericity" id="assoc_ds_genericity">More + Data Structures and Traits</a></h3> + + <p>The STL contains associative containers based on red-black + trees and collision-chaining hash tables. These are obviously + very useful, but they are not ideal for all types of + settings.</p> + + <p>Figure <a href= + "#different_underlying_data_structures">Different underlying + data structures</a> shows different underlying data structures + (the ones currently supported in <tt>pb_ds</tt>). A shows a + collision-chaining hash-table, B shows a probing hash-table, C + shows a red-black tree, D shows a splay tree, E shows a tree + based on an ordered vector(implicit in the order of the + elements), F shows a PATRICIA trie, and G shows a list-based + container with update policies.</p> + + <p>Each of these data structures has some performance benefits, + in terms of speed, size or both (see <a href= + "assoc_performance_tests.html">Associative-Container + Performance Tests</a> and <a href= + "assoc_performance_tests.html#dss_family_choice">Associative-Container + Performance Tests::Observations::Underlying Data-Structure + Families</a>). For now, though, note that <i>e.g.</i>, + vector-based trees and probing hash tables manipulate memory + more efficiently than red-black trees and collision-chaining + hash tables, and that list-based associative containers are + very useful for constructing "multimaps" (see <a href= + "#assoc_mapping_semantics">Alternative to Multiple Equivalent + Keys</a>, <a href= + "assoc_performance_tests.html#multimaps">Associative Container + Performance Tests::Multimaps</a>, and <a href= + "assoc_performance_tests.html#msc">Associative Container + Performance Tests::Observations::Mapping-Semantics + Considerations</a>).</p> + + <h6 class="c1"><a name="different_underlying_data_structures" + id="different_underlying_data_structures"><img src= + "different_underlying_dss.png" alt="no image" /></a></h6> + + <h6 class="c1">Different underlying data structures.</h6> + + <p>Now consider a function manipulating a generic associative + container, <i>e.g.</i>,</p> + <pre> +<b>template</b>< + <b>class</b> Cntnr> +<b>int</b> + some_op_sequence + (Cntnr &r_cnt) +{ + ... +} +</pre> + + <p>Ideally, the underlying data structure of <tt>Cntnr</tt> + would not affect what can be done with <tt>r_cnt</tt>. + Unfortunately, this is not the case.</p> + + <p>For example, if <tt>Cntnr</tt> is <tt>std::map</tt>, then + the function can use <tt>std::for_each(r_cnt.find(foo), + r_cnt.find(bar), foobar)</tt> in order to apply <tt>foobar</tt> + to all elements between <tt>foo</tt> and <tt>bar</tt>. If + <tt>Cntnr</tt> is a hash-based container, then this call's + results are undefined.</p> + + <p>Also, if <tt>Cntnr</tt> is tree-based, the type and object + of the comparison functor can be accessed. If <tt>Cntnr</tt> is + hash based, these queries are nonsensical.</p> + + <p>There are various other differences based on the container's + underlying data structure. For one, they can be constructed by, + and queried for, different policies. Furthermore:</p> + + <ol> + <li>Containers based on C, D, E and F store elements in a + meaningful order; the others store elements in a meaningless + (and probably time-varying) order. By implication, only + containers based on C, D, E and F can support erase + operations taking an iterator and returning an iterator to + the following element without performance loss (see <a href= + "#assoc_ers_methods">Slightly Different Methods::Methods + Related to Erase</a>).</li> + + <li>Containers based on C, D, E, and F can be split and + joined efficiently, while the others cannot. Containers based + on C and D, furthermore, can guarantee that this is + exception-free; containers based on E cannot guarantee + this.</li> + + <li>Containers based on all but E can guarantee that erasing + an element is exception free; containers based on E cannot + guarantee this. Containers based on all but B and E can + guarantee that modifying an object of their type does not + invalidate iterators or references to their elements, while + containers based on B and E cannot. Containers based on C, D, + and E can furthermore make a stronger guarantee, namely that + modifying an object of their type does not affect the order + of iterators.</li> + </ol> + + <p>A unified tag and traits system (as used for the STL's + iterators, for example) can ease generic manipulation of + associative containers based on different underlying + data structures (see <a href= + "tutorial.html#assoc_ds_gen">Tutorial::Associative + Containers::Determining Containers' Attributes</a> and <a href= + "ds_gen.html#container_traits">Design::Associative + Containers::Data-Structure Genericity::Data-Structure Tags and + Traits</a>).</p> + + <h3><a name="assoc_diff_it" id="assoc_diff_it">Differentiating + between Iterator Types</a></h3> + + <p>Iterators are centric to the STL's design, because of the + container/algorithm/iterator decomposition that allows an + algorithm to operate on a range through iterators of some + sequence (<i>e.g.</i>, one originating from a container). + Iterators, then, are useful because they allow going over a + <u>sequence</u>. The STL also uses iterators for accessing a + <u>specific</u> element - <i>e.g.</i>, when an associative + container returns one through <tt>find</tt>. The STL, however, + consistently uses the same types of iterators for both + purposes: going over a range, and accessing a specific found + element. Before the introduction of hash-based containers to + the STL, this made sense (with the exception of priority + queues, which are discussed in <a href="#pq">Priority + Queues</a>).</p> + + <p>Using the STL's associative containers together with + non-order-preserving associative containers (and also because + of priority-queues container), there is a possible need for + different types of iterators for self-organizing containers - + the iterator concept seems overloaded to mean two different + things (in some cases). The following subsections explain this; + <a href="tutorial.html#assoc_find_range">Tutorial::Associative + Containers::Point-Type and Range-Type Methods</a> explains an + alternative design which does not complicate the use of + order-preserving containers, but is better for unordered + containers; <a href= + "ds_gen.html#find_range">Design::Associative + Containers::Data-Structure Genericity::Point-Type and + Range-Type Methods</a> explains the design further.</p> + + <h4><a name="assoc_find_it_range_it" id= + "assoc_find_it_range_it">Using Point-Type Iterators for + Range-Type Operations</a></h4> + + <p>Suppose <tt>cntnr</tt> is some associative container, and + say <tt>c</tt> is an object of type <tt>cntnr</tt>. Then what + will be the outcome of</p> + <pre> +std::for_each(c.find(1), c.find(5), foo); +</pre> + + <p>If <tt>cntnr</tt> is a tree-based container object, then an + in-order walk will apply <tt>foo</tt> to the relevant elements, + <i>e.g.</i>, as in Figure <a href="#range_it_in_hts">Range + iteration in different data structures</a> -A. If <tt>c</tt> is + a hash-based container, then the order of elements between any + two elements is undefined (and probably time-varying); there is + no guarantee that the elements traversed will coincide with the + <i>logical</i> elements between 1 and 5, <i>e.g.</i>, as in + Figure <a href="#range_it_in_hts">Range iteration in different + data structures</a>-B.</p> + + <h6 class="c1"><a name="range_it_in_hts" id= + "range_it_in_hts"><img src="point_iterators_range_ops_1.png" + alt="no image" /></a></h6> + + <h6 class="c1">Range iteration in different + data structures.</h6> + + <p>In our opinion, this problem is not caused just because + red-black trees are order preserving while collision-chaining + hash tables are (generally) not - it is more fundamental. Most + of the STL's containers order sequences in a well-defined + manner that is determined by their <u>interface</u>: calling + <tt>insert</tt> on a tree-based container modifies its sequence + in a predictable way, as does calling <tt>push_back</tt> on a + list or a vector. Conversely, collision-chaining hash tables, + probing hash tables, priority queues, and list-based containers + (which are very useful for "multimaps") are self-organizing + data structures; the effect of each operation modifies their + sequences in a manner that is (practically) determined by their + <u>implementation</u>.</p> + + <p>Consequently, applying an algorithm to a sequence obtained + from most containers <u>may or may not</u> make sense, but + applying it to a sub-sequence of a self-organizing container + <u>does not</u>.</p> + + <h4><a name="assoc_range_it_for_find_it" id= + "assoc_range_it_for_find_it">The Cost of Enabling Range + Capabilities to Point-Type Iterators</a></h4> + + <p>Suppose <tt>c</tt> is some collision-chaining hash-based + container object, and one calls <tt>c.find(3)</tt>. Then what + composes the returned iterator?</p> + + <p>Figure <a href="#find_its_in_hash_tables">Point-type + iterators in hash tables</a>-A shows the simplest (and most + efficient) implementation of a collision-chaining hash table. + The little box marked <tt>point_iterator</tt> shows an object + that contains a pointer to the element's node. Note that this + "iterator" has no way to move to the next element (<i>i.e.</i>, + it cannot support <tt><b>operator</b>++</tt>). Conversely, the + little box marked <tt>iterator</tt> stores both a pointer to + the element, as well as some other information (<i>e.g.</i>, + the bucket number of the element). the second iterator, then, + is "heavier" than the first one- it requires more time and + space. If we were to use a different container to + cross-reference into this hash-table using these iterators - it + would take much more space. As noted in <a href= + "#assoc_find_it_range_it">Using Point-Type Iterators for + Range-Type Operations</a>, nothing much can be done by + incrementing these iterators, so why is this extra information + needed?</p> + + <p>Alternatively, one might create a collision-chaining + hash-table where the lists might be linked, forming a + monolithic total-element list, as in Figure <a href= + "#find_its_in_hash_tables">Point-type iterators in hash + tables</a>-B (this seems similar to the Dinkumware design + [<a href="references.html#dinkumware_stl">dinkumware_stl</a>]). + Here the iterators are as light as can be, but the hash-table's + operations are more complicated.</p> + + <h6 class="c1"><a name="find_its_in_hash_tables" id= + "find_its_in_hash_tables"><img src= + "point_iterators_range_ops_2.png" alt="no image" /></a></h6> + + <h6 class="c1">Point-type iterators in hash tables.</h6> + + <p>It should be noted that containers based on + collision-chaining hash-tables are not the only ones with this + type of behavior; many other self-organizing data structures + display it as well.</p> + + <h4><a name="assoc_inv_guar" id="assoc_inv_guar">Invalidation + Guarantees</a></h4> + + <p>Consider the following snippet:</p> + <pre> +it = c.find(3); + +c.erase(5); +</pre> + + <p>Following the call to <tt>erase</tt>, what is the validity + of <tt>it</tt>: can it be de-referenced? can it be + incremented?</p> + + <p>The answer depends on the underlying data structure of the + container. Figure <a href= + "#invalidation_guarantee_erase">Effect of erase in different + underlying data structures</a> shows three cases: A1 and A2 + show a red-black tree; B1 and B2 show a probing hash-table; C1 + and C2 show a collision-chaining hash table.</p> + + <h6 class="c1"><a name="invalidation_guarantee_erase" id= + "invalidation_guarantee_erase"><img src= + "invalidation_guarantee_erase.png" alt="no image" /></a></h6> + + <h6 class="c1">Effect of erase in different underlying + data structures.</h6> + + <ol> + <li>Erasing 5 from A1 yields A2. Clearly, an iterator to 3 + can be de-referenced and incremented. The sequence of + iterators changed, but in a way that is well-defined by the + <u>interface</u>.</li> + + <li>Erasing 5 from B1 yields B2. Clearly, an iterator to 3 is + not valid at all - it cannot be de-referenced or incremented; + the order of iterators changed in a way that is (practically) + determined by the <u>implementation</u> and not by the + <u>interface</u>.</li> + + <li>Erasing 5 from C1 yields C2. Here the situation is more + complicated. On the one hand, there is no problem in + de-referencing <tt>it</tt>. On the other hand, the order of + iterators changed in a way that is (practically) determined + by the <u>implementation</u> and not by the + <u>interface</u>.</li> + </ol> + + <p>So in classic STL, it is not always possible to express + whether <tt>it</tt> is valid or not. This is true also for + <tt>insert</tt>, <i>e.g.</i>. Again, the iterator concept seems + overloaded.</p> + + <h3><a name="assoc_methods" id="assoc_methods">Slightly + Different Methods</a></h3> + + <p>[<a href="references.html#meyers02both">meyers02both</a>] + points out that a class's methods should comprise only + operations which depend on the class's internal structure; + other operations are best designed as external functions. + Possibly, therefore, the STL's associative containers lack some + useful methods, and provide some other methods which would be + better left out (<i>e.g.</i>, [<a href= + "references.html#sgi_stl">sgi_stl</a>] ).</p> + + <h4><a name="assoc_ers_methods" id="assoc_ers_methods">Methods + Related to Erase</a></h4> + + <ol> + <li>Order-preserving STL associative containers provide the + method + <pre> +iterator + erase + (iterator it) +</pre>which takes an iterator, erases the corresponding element, +and returns an iterator to the following element. Also hash-based +STL associative containers provide this method. This <u>seemingly +increases</u> genericity between associative containers, since, <i> + e.g.</i>, it is possible to use + <pre> +<b>typename</b> C::iterator it = c.begin(); +<b>typename</b> C::iterator e_it = c.end(); + +<b>while</b>(it != e_it) + it = pred(*it)? c.erase(it) : ++it; +</pre>in order to erase from a container object <tt> + c</tt> all element which match a predicate <tt>pred</tt>. + However, in a different sense this actually + <u>decreases</u> genericity: an integral implication of + this method is that tree-based associative containers' + memory use is linear in the total number of elements they + store, while hash-based containers' memory use is unbounded + in the total number of elements they store. Assume a + hash-based container is allowed to decrease its size when + an element is erased. Then the elements might be rehashed, + which means that there is no "next" element - it is simply + undefined. Consequently, it is possible to infer from the + fact that STL hash-based containers provide this method + that they cannot downsize when elements are erased + (<a href="assoc_performance_tests.html#hash_based">Performance + Tests::Hash-Based Container Tests</a> quantifies this.) As + a consequence, different code is needed to manipulate + different containers, assuming that memory should be + conserved. <tt>pb_ds</tt>'s non-order preserving + associative containers omit this method. + </li> + + <li>All of <tt>pb_ds</tt>'s associative containers include a + conditional-erase method + <pre> +<b>template</b>< + <b>class</b> Pred> +size_type + erase_if + (Pred pred) +</pre>which erases all elements matching a predicate. This is +probably the only way to ensure linear-time multiple-item erase +which can actually downsize a container. + </li> + + <li>STL associative containers provide methods for + multiple-item erase of the form + <pre> +size_type + erase + (It b, + It e) +</pre>erasing a range of elements given by a pair of iterators. For +tree-based or trie-based containers, this can implemented more +efficiently as a (small) sequence of split and join operations. For +other, unordered, containers, this method isn't much better than an +external loop. Moreover, if <tt>c</tt> is a hash-based container, +then, <i>e.g.</i>, <tt>c.erase(c.find(2), c.find(5))</tt> is almost +certain to do something different than erasing all elements whose +keys are between 2 and 5, and is likely to produce other undefined +behavior. + </li> + </ol> + + <h4><a name="assoc_split_join_methods" id= + "assoc_split_join_methods">Methods Related to Split and + Join</a></h4> + + <p>It is well-known that tree-based and trie-based container + objects can be efficiently split or joined [<a href= + "references.html#clrs2001">clrs2001</a>]. Externally splitting + or joining trees is super-linear, and, furthermore, can throw + exceptions. Split and join methods, consequently, seem good + choices for tree-based container methods, especially, since as + noted just before, they are efficient replacements for erasing + sub-sequences. <a href= + "assoc_performance_tests.html#tree_like_based">Performance + Tests::Tree-Like-Based Container Tests</a> quantifies this.</p> + + <h4><a name="assoc_insert_methods" id= + "assoc_insert_methods">Methods Related to Insert</a></h4> + + <p>STL associative containers provide methods of the form</p> + <pre> +<b>template</b>< + <b>class</b> It> +size_type + insert + (It b, + It e); +</pre>for inserting a range of elements given by a pair of +iterators. At best, this can be implemented as an external loop, +or, even more efficiently, as a join operation (for the case of +tree-based or trie-based containers). Moreover, these methods seem +similar to constructors taking a range given by a pair of +iterators; the constructors, however, are transactional, whereas +the insert methods are not; this is possibly confusing. + + <h4><a name="assoc_equiv_comp_methods" id= + "assoc_equiv_comp_methods">Functions Related to + Comparison</a></h4> + + <p>Associative containers are parametrized by policies + allowing to test key equivalence; <i>e.g.</i> a hash-based + container can do this through its equivalence functor, and a + tree-based container can do this through its comparison + functor. In addition, some STL associative containers have + global function operators, <i>e.g.</i>, + <tt><b>operator</b>==</tt> and <tt><b>operator</b><=</tt>, + that allow comparing entire associative containers.</p> + + <p>In our opinion, these functions are better left out. To + begin with, they do not significantly improve over an external + loop. More importantly, however, they are possibly misleading - + <tt><b>operator</b>==</tt>, for example, usually checks for + equivalence, or interchangeability, but the associative + container cannot check for values' equivalence, only keys' + equivalence; also, are two containers considered equivalent if + they store the same values in different order? this is an + arbitrary decision.</p> + + <h3><a name="assoc_mapping_semantics" id= + "assoc_mapping_semantics">Alternative to Multiple Equivalent + Keys</a></h3> + + <p>Maps (or sets) allow mapping (or storing) unique-key values. + The STL, however, also supplies associative containers which + map (or store) multiple values with equivalent keys: + <tt>std::multimap</tt>, <tt>std::multiset</tt>, + <tt>std::tr1::unordered_multimap</tt>, and + <tt>unordered_multiset</tt>. We first discuss how these might + be used, then why we think it is best to avoid them.</p> + + <p>Suppose one builds a simple bank-account application that + records for each client (identified by an <tt>std::string</tt>) + and account-id (marked by an <tt><b>unsigned long</b></tt>) - + the balance in the account (described by a + <tt><b>float</b></tt>). Suppose further that ordering this + information is not useful, so a hash-based container is + preferable to a tree based container. Then one can use</p> + <pre> +std::tr1::unordered_map<std::pair<std::string, <b>unsigned long</b>>, <b>float</b>, ...> +</pre>which <u>hashes every combination of client and +account-id</u>. This might work well, except for the fact that it +is now impossible to efficiently list all of the accounts of a +specific client (this would practically require iterating over all +entries). Instead, one can use + <pre> +std::tr1::unordered_multimap<std::pair<std::string, <tt><b>unsigned long</b></tt>>, <b>float</b>, ...> +</pre>which <u>hashes every client</u>, and <u>decides equivalence +based on client</u> only. This will ensure that all accounts +belonging to a specific user are stored consecutively. + + <p>Also, suppose one wants an integers' priority queue + (<i>i.e.,</i> a container that supports <tt>push</tt>, + <tt>pop</tt>, and <tt>top</tt> operations, the last of which + returns the largest <tt><b>int</b></tt>) that also supports + operations such as <tt>find</tt> and <tt>lower_bound</tt>. A + reasonable solution is to build an adapter over + <tt>std::set<<b>int</b>></tt>. In this adapter, + <i>e.g.</i>, <tt>push</tt> will just call the tree-based + associative container's <tt>insert</tt> method; <tt>pop</tt> + will call its <tt>end</tt> method, and use it to return the + preceding element (which must be the largest). Then this might + work well, except that the container object cannot hold + multiple instances of the same integer (<tt>push(4)</tt>, + <i>e.g.</i>, will be a no-op if <tt>4</tt> is already in the + container object). If multiple keys are necessary, then one + might build the adapter over an + <tt>std::multiset<<b>int</b>></tt>.</p> + + <p class="c1">STL non-unique-mapping containers, then, are + useful when (1) a key can be decomposed in to a primary key and + a secondary key, (2) a key is needed multiple times, or (3) any + combination of (1) and (2).</p> + + <p>Figure <a href="#embedded_lists_1">Non-unique mapping + containers in the STL's design</a> shows how the STL's design + works internally; in this figure nodes shaded equally represent + equivalent-key values. Equivalent keys are stored consecutively + using the properties of the underlying data structure: binary + search trees (Figure <a href="#embedded_lists_1">Non-unique + mapping containers in the STL's design</a>-A) store + equivalent-key values consecutively (in the sense of an + in-order walk) naturally; collision-chaining hash tables + (Figure <a href="#embedded_lists_1">Non-unique mapping + containers in the STL's design</a>-B) store equivalent-key + values in the same bucket, the bucket can be arranged so that + equivalent-key values are consecutive.</p> + + <h6 class="c1"><a name="embedded_lists_1" id= + "embedded_lists_1"><img src="embedded_lists_1.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Non-unique mapping containers in the STL's + design.</h6> + + <p>Put differently, STL non-unique mapping + associative-containers are associative containers that map + primary keys to linked lists that are embedded into the + container. Figure <a href="#embedded_lists_2">Effect of + embedded lists in STL multimaps</a> shows again the two + containers from Figure <a href="#embedded_lists_1">Non-unique + mapping containers in the STL's design</a>, this time with the + embedded linked lists of the grayed nodes marked + explicitly.</p> + + <h6 class="c1"><a name="embedded_lists_2" id= + "embedded_lists_2"><img src="embedded_lists_2.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Effect of embedded lists in STL multimaps.</h6> + + <p>These embedded linked lists have several disadvantages.</p> + + <ol> + <li>The underlying data structure embeds the linked lists + according to its own consideration, which means that the + search path for a value might include several different + equivalent-key values. For example, the search path for the + the black node in either of Figures <a href= + "#embedded_lists_1">Non-unique mapping containers in the + STL's design</a> A or B, includes more than a single gray + node.</li> + + <li>The links of the linked lists are the underlying + data structures' nodes, which typically are quite structured. + <i>E.g.</i>, in the case of tree-based containers (Figure + <a href="#embedded_lists_2">Effect of embedded lists in STL + multimaps</a>-B), each "link" is actually a node with three + pointers (one to a parent and two to children), and a + relatively-complicated iteration algorithm. The linked lists, + therefore, can take up quite a lot of memory, and iterating + over all values equal to a given key (<i>e.g.</i>, through + the return value of the STL's <tt>equal_range</tt>) can be + expensive.</li> + + <li>The primary key is stored multiply; this uses more + memory.</li> + + <li>Finally, the interface of this design excludes several + useful underlying data structures. <i>E.g.</i>, of all the + unordered self-organizing data structures, practically only + collision-chaining hash tables can (efficiently) guarantee + that equivalent-key values are stored consecutively.</li> + </ol> + + <p>The above reasons hold even when the ratio of secondary keys + to primary keys (or average number of identical keys) is small, + but when it is large, there are more severe problems:</p> + + <ol> + <li>The underlying data structures order the links inside + each embedded linked-lists according to their internal + considerations, which effectively means that each of the + links is unordered. Irrespective of the underlying + data structure, searching for a specific value can degrade to + linear complexity.</li> + + <li>Similarly to the above point, it is impossible to apply + to the secondary keys considerations that apply to primary + keys. For example, it is not possible to maintain secondary + keys by sorted order.</li> + + <li>While the interface "understands" that all equivalent-key + values constitute a distinct list (<i>e.g.</i>, through + <tt>equal_range</tt>), the underlying data structure + typically does not. This means, <i>e.g.</i>, that operations + such as erasing from a tree-based container all values whose + keys are equivalent to a a given key can be super-linear in + the size of the tree; this is also true also for several + other operations that target a specific list.</li> + </ol> + + <p>In <tt>pb_ds</tt>, therefore, all associative containers map + (or store) unique-key values. One can (1) map primary keys to + secondary associative-containers (<i>i.e.</i>, containers of + secondary keys) or non-associative containers (2) map identical + keys to a size-type representing the number of times they + occur, or (3) any combination of (1) and (2). Instead of + allowing multiple equivalent-key values, <tt>pb_ds</tt> + supplies associative containers based on underlying + data structures that are suitable as secondary + associative-containers (see <a href= + "assoc_performance_tests.html#msc">Associative-Container + Performance Tests::Observations::Mapping-Semantics + Considerations</a>).</p> + + <p>Figures <a href="#embedded_lists_3">Non-unique mapping + containers in <tt>pb_ds</tt></a> A and B show the equivalent + structures in <tt>pb_ds</tt>'s design, to those in Figures + <a href="#embedded_lists_1">Non-unique mapping containers in + the STL's design</a> A and B, respectively. Each shaded box + represents some size-type or secondary + associative-container.</p> + + <h6 class="c1"><a name="embedded_lists_3" id= + "embedded_lists_3"><img src="embedded_lists_3.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Non-unique mapping containers in the + <tt>pb_ds</tt>.</h6> + + <p>In the first example above, then, one would use an + associative container mapping each user to an associative + container which maps each application id to a start time (see + <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_multimap.cc"><tt>basic_multimap.cc</tt></a>); + in the second example, one would use an associative container + mapping each <tt><b>int</b></tt> to some size-type indicating + the number of times it logically occurs (see <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_multiset.cc"><tt>basic_multiset.cc</tt></a>).</p> + + <p><a href= + "assoc_performance_tests.html#multimaps">Associative-Container + Performance Tests::Multimaps</a> quantifies some of these + points, and <a href= + "assoc_performance_tests.html#msc">Associative-Container + Performance Tests::Observations::Mapping-Semantics + Considerations</a> shows some simple calculations.</p> + + <p><a href="assoc_examples.html#mmaps">Associative-Container + Examples::Multimaps</a> shows some simple examples of using + "multimaps".</p> + + <p><a href="lu_based_containers.html">Design::Associative + Containers::List-Based Containers</a> discusses types of + containers especially suited as secondary + associative-containers.</p> + + <h2><a name="pq" id="pq">Priority Queues</a></h2> + + <h3><a name="pq_more_ops" id="pq_more_ops">Slightly Different + Methods</a></h3> + + <p>Priority queues are containers that allow efficiently + inserting values and accessing the maximal value (in the sense + of the container's comparison functor); <i>i.e.</i>, their + interface supports <tt>push</tt> and <tt>pop</tt>. The STL's + priority queues indeed support these methods, but they support + little else. For algorithmic and software-engineering purposes, + other methods are needed:</p> + + <ol> + <li>Many graph algorithms [<a href= + "references.html#clrs2001">clrs2001</a>] require increasing a + value in a priority queue (again, in the sense of the + container's comparison functor), or joining two + priority-queue objects.</li> + + <li>It is sometimes necessary to erase an arbitrary value in + a priority queue. For example, consider the <tt>select</tt> + function for monitoring file descriptors: + <pre> +<b>int</b> + select + (<b>int</b> nfds, + fd_set *readfds, + fd_set *writefds, + fd_set *errorfds, + <b>struct</b> timeval *timeout); +</pre>then, as the <tt>select</tt> manual page [<a href= +"references.html#select_man">select_man</a>] states: + + <p><q>The nfds argument specifies the range of file + descriptors to be tested. The select() function tests file + descriptors in the range of 0 to nfds-1.</q></p> + + <p>It stands to reason, therefore, that we might wish to + maintain a minimal value for <tt>nfds</tt>, and priority + queues immediately come to mind. Note, though, that when a + socket is closed, the minimal file description might + change; in the absence of an efficient means to erase an + arbitrary value from a priority queue, we might as well + avoid its use altogether.</p> + + <p><a href="pq_examples.html#xref">Priority-Queue + Examples::Cross-Referencing</a> shows examples for these + types of operations.</p> + </li> + + <li>STL containers typically support iterators. It is + somewhat unusual for <tt>std::priority_queue</tt> to omit + them (see, <i>e.g.</i>, [<a href= + "references.html#meyers01stl">meyers01stl</a>]). One might + ask why do priority queues need to support iterators, since + they are self-organizing containers with a different purpose + than abstracting sequences. There are several reasons: + + <ol> + <li>Iterators (even in self-organizing containers) are + useful for many purposes, <i>e.g.</i>, cross-referencing + containers, serialization, and debugging code that uses + these containers.</li> + + <li>The STL's hash-based containers support iterators, + even though they too are self-organizing containers with + a different purpose than abstracting sequences.</li> + + <li>In STL-like containers, it is natural to specify the + interface of operations for modifying a value or erasing + a value (discussed previously) in terms of a iterators. + This is discussed further in <a href= + "pq_design.html#pq_it">Design::Priority + Queues::Iterators</a>. It should be noted that the STL's + containers also use iterators for accessing and + manipulating a specific value. <i>E.g.</i>, in hash-based + containers, one checks the existence of a key by + comparing the iterator returned by <tt>find</tt> to the + iterator returned by <tt>end</tt>, and not by comparing a + pointer returned by <tt>find</tt> to <tt>NULL</tt>.</li> + </ol> + </li> + </ol> + + <p><a href="pq_performance_tests.html">Performance + Tests::Priority Queues</a> quantifies some of these points.</p> + + <h3><a name="pq_ds_genericity" id="pq_ds_genericity">More Data + Structures and Traits</a></h3> + + <p>There are three main implementations of priority queues: the + first employs a binary heap, typically one which uses a + sequence; the second uses a tree (or forest of trees), which is + typically less structured than an associative container's tree; + the third simply uses an associative container. These are + shown, respectively, in Figures <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> A1 and A2, B, and C.</p> + + <h6 class="c1"><a name="pq_different_underlying_dss" id= + "pq_different_underlying_dss"><img src= + "pq_different_underlying_dss.png" alt="no image" /></a></h6> + + <h6 class="c1">Underlying Priority-Queue Data-Structures.</h6> + + <p>No single implementation can completely replace any of the + others. Some have better <tt>push</tt> and <tt>pop</tt> + amortized performance, some have better bounded (worst case) + response time than others, some optimize a single method at the + expense of others, <i>etc.</i>. In general the "best" + implementation is dictated by the problem (see <a href= + "pq_performance_tests.html#pq_observations">Performance + Tests::Priority Queues::Observations</a>).</p> + + <p>As with associative containers (see <a href= + "#assoc_ds_genericity">Associative Containers::Traits for + Underlying Data-Structures</a>), the more implementations + co-exist, the more necessary a traits mechanism is for handling + generic containers safely and efficiently. This is especially + important for priority queues, since the invalidation + guarantees of one of the most useful data structures - binary + heaps - is markedly different than those of most of the + others.</p> + + <p><a href="pq_design.html#pq_traits">Design::Priority + Queues::Traits</a> discusses this further.</p> + + <h3><a name="pq_binary_heap" id="pq_binary_heap">Binary Heap + Implementation</a></h3> + + <p>Binary heaps are one of the most useful underlying + data structures for priority queues. They are very efficient in + terms of memory (since they don't require per-value structure + metadata), and have the best amortized <tt>push</tt> and + <tt>pop</tt> performance for primitive types (<i>e.g.</i>, + <tt><b>int</b></tt>s).</p> + + <p>The STL's <tt>priority_queue</tt> implements this data + structure as an adapter over a sequence, typically + <tt>std::vector</tt> or <tt>std::deque</tt>, which correspond + to Figures <a href="#pq_different_underlying_dss">Underlying + Priority-Queue Data-Structures</a> A1 and A2, respectively.</p> + + <p>This is indeed an elegant example of the adapter concept and + the algorithm/container/iterator decomposition (see [<a href= + "references.html#nelson96stlpq">nelson96stlpql</a>]). There are + possibly reasons, however, why a binary-heap priority queue + would be better implemented as a container instead of a + sequence adapter:</p> + + <ol> + <li><tt>std::priority_queue</tt> cannot erase values from its + adapted sequence (irrespective of the sequence type). This + means that the memory use of an <tt>std::priority_queue</tt> + object is always proportional to the maximal number of values + it ever contained, and not to the number of values that it + currently contains (see <a href= + "priority_queue_text_pop_mem_usage_test.html">Priority Queue + Text <tt>pop</tt> Memory Use Test</a>); this implementation + of binary heaps acts very differently than other underlying + data structures (<i>e.g.</i>, pairing heaps).</li> + + <li>Some combinations of adapted sequences and value types + are very inefficient or just don't make sense. If one uses + <tt>std::priority_queue<std::vector<std::string> + > ></tt>, for example, then not only will each + operation perform a logarithmic number of + <tt>std::string</tt> assignments, but, furthermore, any + operation (including <tt>pop</tt>) can render the container + useless due to exceptions. Conversely, if one uses + <tt>std::priority_queue<std::deque<<b>int</b>> > + ></tt>, then each operation uses incurs a logarithmic + number of indirect accesses (through pointers) unnecessarily. + It might be better to let the container make a conservative + deduction whether to use the structure in Figures <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> A1 or A2.</li> + + <li>There does not seem to be a systematic way to determine + what exactly can be done with the priority queue. + + <ol> + <li>If <tt>p</tt> is a priority queue adapting an + <tt>std::vector</tt>, then it is possible to iterate over + all values by using <tt>&p.top()</tt> and + <tt>&p.top() + p.size()</tt>, but this will not work + if <tt>p</tt> is adapting an <tt>std::deque</tt>; in any + case, one cannot use <tt>p.begin()</tt> and + <tt>p.end()</tt>. If a different sequence is adapted, it + is even more difficult to determine what can be + done.</li> + + <li>If <tt>p</tt> is a priority queue adapting an + <tt>std::deque</tt>, then the reference return by + <tt>p.top()</tt> will remain valid until it is popped, + but if <tt>p</tt> adapts an <tt>std::vector</tt>, the + next <tt>push</tt> will invalidate it. If a different + sequence is adapted, it is even more difficult to + determine what can be done.</li> + </ol> + </li> + + <li>Sequence-based binary heaps can still implement + linear-time <tt>erase</tt> and <tt>modify</tt> operations. + This means that if one needs, <i>e.g.</i>, to erase a small + (say logarithmic) number of values, then one might still + choose this underlying data structure. Using + <tt>std::priority_queue</tt>, however, this will generally + change the order of growth of the entire sequence of + operations.</li> + </ol> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/move_to_front_lu_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/move_to_front_lu_policy.html new file mode 100644 index 000000000..4ed4d40bd --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/move_to_front_lu_policy.html @@ -0,0 +1,194 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>move_to_front_lu_policy Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>move_to_front_lu_policy</tt> Interface</h1> + + <p>A list-update policy that unconditionally moves elements to + the front of the list.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/list_update_policy.hpp"><tt>list_update_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator </a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + + <p>This is used only for definitions, e.g., the size + type.</p> + </td> + + <td> + <pre> +std::allocator<<b>char</b>> +</pre> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="allocator48440069" id="allocator48440069">allocator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Allocator35940069"><tt>Allocator</tt></a> +</pre> + </td> + + <td> + <p><a href="#Allocator35940069"><tt>Allocator</tt></a> + type.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">Metadata-Type + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_type2849297114" id= +"metadata_type2849297114">metadata_type</a> +</pre> + </td> + + <td> + <pre> +<a href="null_lu_metadata.html"><span class= +"c2"><tt>null_lu_metadata</tt></span></a> +</pre> + </td> + + <td> + <p>Metadata on which this functor operates.</p> + + <p>In this case, none.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_reference583863863" id= +"metadata_reference583863863">metadata_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind< + <a href= +"#metadata_type2849297114"><tt>metadata_type</tt></a>>::other::reference +</pre> + </td> + + <td> + <p>Reference to metadata on which this functor + operates.</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Public Methods</a></h2> + + <h3><a name="link6" id="link6">Metadata Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#metadata_type2849297114"><tt>metadata_type</tt></a> + <b>operator</b>() + () <b>const</b> +</pre> + </td> + + <td> + <p>Creates a metadata object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + <b>operator</b>() + (<a href= +"#metadata_reference583863863"><tt>metadata_reference</tt></a> r_metadata) <b>const</b> +</pre> + </td> + + <td> + <p>Decides whether a metadata object should be moved to + the front of the list.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large.html new file mode 100644 index 000000000..74d33a326 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large.html @@ -0,0 +1,215 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>"Multimap" Text Find Timing Test with Large Average + Secondary-Key to Primary-Key Ratio</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>"Multimap" Text Find Timing Test with Large Average + Secondary-Key to Primary-Key Ratio</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of pairs into a container. The + first item of each pair is a string from an arbitrary text + [<a href="references.html#wickland96thirty">wickland96thirty</a>], and + the second is a uniform i.i.d.integer. The container is a + "multimap" - it considers the first member of each pair as a + primary key, and the second member of each pair as a secondary + key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Alternative to Multiple Equivalent Keys</a>). There + are 100 distinct primary keys, and the ratio of secondary keys + to primary keys ranges to about 20.</p> +<p>The test measures the average find-time as a function of the + number of values inserted. For <tt>pb_ds</tt>'s containers, it + finds the secondary key from a container obtained from finding + a primary key. For the native multimaps, it searches a range + obtained using <tt>std::equal_range</tt> on a primary key.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_find_timing_large.cc"><tt>multimap_text_find_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 100 3 4 4)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the find-time scalability of different + "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Mapping Semantics</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and + <a href="#NTL">NTL</a> show the results for "multimaps" which + use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for + "multimaps" which use a hash-based container for primary keys, + in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, + <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, + and <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTG_res_div"> +<div id="NTG_gcc"> +<div id="NTG_multimap_text_find_timing_test_large_s2p_tree"> +<div id="NTG_assoc"> +<div id="NTG_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_find_timing_test_large_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: Native and primary tree-based multimap types find timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTM_res_div"> +<div id="NTM_msvc"> +<div id="NTM_multimap_text_find_timing_test_large_s2p_tree"> +<div id="NTM_assoc"> +<div id="NTM_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_find_timing_test_large_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: Native and primary tree-based multimap types find timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTL_res_div"> +<div id="NTL_local"> +<div id="NTL_multimap_text_find_timing_test_large_s2p_tree"> +<div id="NTL_assoc"> +<div id="NTL_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_find_timing_test_large_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types find timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHG_res_div"> +<div id="NHG_gcc"> +<div id="NHG_multimap_text_find_timing_test_large_s2p_hash"> +<div id="NHG_assoc"> +<div id="NHG_Native_and_primary_hash-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_find_timing_test_large_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types find timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_mmap- +<tt>__gnucxx::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHM_res_div"> +<div id="NHM_msvc"> +<div id="NHM_multimap_text_find_timing_test_large_s2p_hash"> +<div id="NHM_assoc"> +<div id="NHM_Native_and_primary_hash-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_find_timing_test_large_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types find timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_mmap- +<tt>stdext::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHL_res_div"> +<div id="NHL_local"> +<div id="NHL_multimap_text_find_timing_test_large_s2p_hash"> +<div id="NHL_assoc"> +<div id="NHL__Native_and_primary_hash-based_multimap_types_find_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_find_timing_test_large_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types find timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics + Considerations</a>.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_gcc.png Binary files differnew file mode 100644 index 000000000..03a62f52b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_local.png Binary files differnew file mode 100644 index 000000000..32a61cac9 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_msvc.png Binary files differnew file mode 100644 index 000000000..4462d289a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_gcc.png Binary files differnew file mode 100644 index 000000000..89e464481 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_local.png Binary files differnew file mode 100644 index 000000000..10b3980ed --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_msvc.png Binary files differnew file mode 100644 index 000000000..20320953e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small.html new file mode 100644 index 000000000..1b379d821 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small.html @@ -0,0 +1,215 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>"Multimap" Text Find Timing Test with Small Average + Secondary-Key to Primary-Key Ratio</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>"Multimap" Text Find Timing Test with Small Average + Secondary-Key to Primary-Key Ratio</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of pairs into a container. The + first item of each pair is a string from an arbitrary text + [<a href="references.html#wickland96thirty">wickland96thirty</a>], and + the second is a uniform i.i.d.integer. The container is a + "multimap" - it considers the first member of each pair as a + primary key, and the second member of each pair as a secondary + key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Alternative to Multiple Equivalent Keys</a>). There + are 400 distinct primary keys, and the ratio of secondary keys + to primary keys ranges from 1 to 5.</p> +<p>The test measures the average find-time as a function of the + number of values inserted. For <tt>pb_ds</tt>'s containers, it + finds the secondary key from a container obtained from finding + a primary key. For the native multimaps, it searches a range + obtained using <tt>std::equal_range</tt> on a primary key.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_find_timing_small.cc"><tt>multimap_text_find_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 400 1 1 6)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the find-time scalability of different + "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Mapping Semantics</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and + <a href="#NTL">NTL</a> show the results for "multimaps" which + use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for + "multimaps" which use a hash-based container for primary keys, + in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, + <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, + and <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTG_res_div"> +<div id="NTG_gcc"> +<div id="NTG_multimap_text_find_timing_test_small_s2p_tree"> +<div id="NTG_assoc"> +<div id="NHG_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_find_timing_test_small_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: NHG Native and primary tree-based multimap types find timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTM_res_div"> +<div id="NTM_msvc"> +<div id="NTM_multimap_text_find_timing_test_small_s2p_tree"> +<div id="NTM_assoc"> +<div id="NHM_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_find_timing_test_small_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: NHM Native and primary tree-based multimap types find timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTL_res_div"> +<div id="NTL_local"> +<div id="NTL_multimap_text_find_timing_test_small_s2p_tree"> +<div id="NTL_assoc"> +<div id="NTL_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_find_timing_test_small_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types find timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHG_res_div"> +<div id="NHG_gcc"> +<div id="NHG_multimap_text_find_timing_test_small_s2p_hash"> +<div id="NHG_assoc"> +<div id="NHG_Native_and_primary_hash-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_find_timing_test_small_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types find timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_mmap- +<tt>__gnucxx::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHM_res_div"> +<div id="NHM_msvc"> +<div id="NHM_multimap_text_find_timing_test_small_s2p_hash"> +<div id="NHM_assoc"> +<div id="NHM_Native_and_primary_hash-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_find_timing_test_small_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types find timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_mmap- +<tt>stdext::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHL_res_div"> +<div id="NHL_local"> +<div id="NHL_multimap_text_find_timing_test_small_s2p_hash"> +<div id="NHL_assoc"> +<div id="NHL__Native_and_primary_hash-based_multimap_types_find_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_find_timing_test_small_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types find timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics + Considerations</a>.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.png Binary files differnew file mode 100644 index 000000000..60e850937 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.png Binary files differnew file mode 100644 index 000000000..a8fa26117 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.png Binary files differnew file mode 100644 index 000000000..11aa9e07b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.png Binary files differnew file mode 100644 index 000000000..f54369b15 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.png Binary files differnew file mode 100644 index 000000000..b3d10612f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.png Binary files differnew file mode 100644 index 000000000..035fd9389 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html new file mode 100644 index 000000000..4affbf440 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html @@ -0,0 +1,210 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Hash-List "Multimap" Text Memory Use Test with Large + Average Secondary-Key to Primary-Key Ratio</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>"Multimap" Text Memory Use Test with Large Average + Secondary-Key to Primary-Key Ratio</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of pairs into a container. The + first item of each pair is a string from an arbitrary text + [<a href="references.html#wickland96thirty">wickland96thirty</a>], and + the second is a uniform i.i.d.integer. The container is a + "multimap" - it considers the first member of each pair as a + primary key, and the second member of each pair as a secondary + key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Alternative to Multiple Equivalent Keys</a>). There + are 100 distinct primary keys. The test measures the memory use + as a function of the number of values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_insert_mem_usage_large.cc"><tt>multimap_text_insert_mem_usage_test</tt></a> + thirty_years_among_the_dead_preproc.txt 100 200 2100 100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the memory scalability of different + "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Mapping Semantics</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and + <a href="#NTL">NTL</a> show the results for "multimaps" which + use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for + "multimaps" which use a hash-based container for primary keys, + in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, + <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, + and <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTG_res_div"> +<div id="NTG_gcc"> +<div id="NTG_multimap_text_insert_mem_usage_test_large_s2p_tree"> +<div id="NTG_assoc"> +<div id="NHG_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: NHG Native and primary tree-based multimap types mem usage test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTM_res_div"> +<div id="NTM_msvc"> +<div id="NTM_multimap_text_insert_mem_usage_test_large_s2p_tree"> +<div id="NTM_assoc"> +<div id="NHM_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: NHM Native and primary tree-based multimap types mem usage test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTL_res_div"> +<div id="NTL_local"> +<div id="NTL_multimap_text_insert_mem_usage_test_large_s2p_tree"> +<div id="NTL_assoc"> +<div id="NTL_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_insert_mem_usage_test_large_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types mem usage test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHG_res_div"> +<div id="NHG_gcc"> +<div id="NHG_multimap_text_insert_mem_usage_test_large_s2p_hash"> +<div id="NHG_assoc"> +<div id="NHG_Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types mem usage test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_hash_mmap- +<tt>__gnucxx::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHM_res_div"> +<div id="NHM_msvc"> +<div id="NHM_multimap_text_insert_mem_usage_test_large_s2p_hash"> +<div id="NHM_assoc"> +<div id="NHM_Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types mem usage test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_mmap- +<tt>stdext::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHL_res_div"> +<div id="NHL_local"> +<div id="NHL_multimap_text_insert_mem_usage_test_large_s2p_hash"> +<div id="NHL_assoc"> +<div id="NHL__Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_insert_mem_usage_test_large_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types mem usage test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics + Considerations</a>.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png Binary files differnew file mode 100644 index 000000000..51a3f8d61 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.png Binary files differnew file mode 100644 index 000000000..8af7100c6 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png Binary files differnew file mode 100644 index 000000000..3a938c0bb --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png Binary files differnew file mode 100644 index 000000000..a992d8f7c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.png Binary files differnew file mode 100644 index 000000000..63c0c8db7 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png Binary files differnew file mode 100644 index 000000000..26841bd10 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html new file mode 100644 index 000000000..462fce4ca --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html @@ -0,0 +1,212 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Hash-List "Multimap" Text Memory Use Test with Small + Average Secondary-Key to Primary-Key Ratio</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>"Multimap" Text Memory Use Test with Small Average + Secondary-Key to Primary-Key Ratio</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of pairs into a container. The + first item of each pair is a string from an arbitrary text + [<a href="references.html#wickland96thirty">wickland96thirty</a>], and + the second is a uniform i.i.d.integer. The container is a + "multimap" - it considers the first member of each pair as a + primary key, and the second member of each pair as a secondary + key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Alternative to Multiple Equivalent Keys</a>). There + are 100 distinct primary keys, and the ratio of secondary keys + to primary keys ranges to about 20.</p> +<p>The test measures the memory use as a function of the number + of values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_insert_mem_usage_small.cc"><tt>multimap_text_insert_mem_usage_test</tt></a> + thirty_years_among_the_dead_preproc.txt 100 3 4 4)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the memory scalability of different + "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Mapping Semantics</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and + <a href="#NTL">NTL</a> show the results for "multimaps" which + use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for + "multimaps" which use a hash-based container for primary keys, + in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, + <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, + and <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTG_res_div"> +<div id="NTG_gcc"> +<div id="NTG_multimap_text_insert_mem_usage_test_small_s2p_tree"> +<div id="NTG_assoc"> +<div id="NTG_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_insert_mem_usage_test_small_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: Native and primary tree-based multimap types mem usage test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTM_res_div"> +<div id="NTM_msvc"> +<div id="NTM_multimap_text_insert_mem_usage_test_small_s2p_tree"> +<div id="NTM_assoc"> +<div id="NHM_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_insert_mem_usage_test_small_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: NHM Native and primary tree-based multimap types mem usage test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTL_res_div"> +<div id="NTL_local"> +<div id="NTL_multimap_text_insert_mem_usage_test_small_s2p_tree"> +<div id="NTL_assoc"> +<div id="NTL_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_insert_mem_usage_test_small_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types mem usage test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHG_res_div"> +<div id="NHG_gcc"> +<div id="NHG_multimap_text_insert_mem_usage_test_small_s2p_hash"> +<div id="NHG_assoc"> +<div id="NHG_Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_insert_mem_usage_test_small_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types mem usage test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_hash_mmap- +<tt>__gnucxx::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHM_res_div"> +<div id="NHM_msvc"> +<div id="NHM_multimap_text_insert_mem_usage_test_small_s2p_hash"> +<div id="NHM_assoc"> +<div id="NHM_Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_insert_mem_usage_test_small_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types mem usage test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_hash_mmap- +<tt>stdext::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHL_res_div"> +<div id="NHL_local"> +<div id="NHL_multimap_text_insert_mem_usage_test_small_s2p_hash"> +<div id="NHL_assoc"> +<div id="NHL__Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_insert_mem_usage_test_small_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types mem usage test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics + Considerations</a>.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_gcc.png Binary files differnew file mode 100644 index 000000000..d3eba9da4 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_local.png Binary files differnew file mode 100644 index 000000000..589dccdef --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_msvc.png Binary files differnew file mode 100644 index 000000000..1828896ee --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_gcc.png Binary files differnew file mode 100644 index 000000000..9334bc35b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_local.png Binary files differnew file mode 100644 index 000000000..d7322f287 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_msvc.png Binary files differnew file mode 100644 index 000000000..2f20e57e5 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large.html new file mode 100644 index 000000000..b9a2d9952 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large.html @@ -0,0 +1,212 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>"Multimap" Text Insert Timing Test with Large Average + Secondary-Key to Primary-Key Ratio</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>"Multimap" Text Insert Timing Test with Large Average + Secondary-Key to Primary-Key Ratio</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of pairs into a container. The + first item of each pair is a string from an arbitrary text + [<a href="references.html#wickland96thirty">wickland96thirty</a>], and + the second is a uniform i.i.d.integer. The container is a + "multimap" - it considers the first member of each pair as a + primary key, and the second member of each pair as a secondary + key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Alternative to Multiple Equivalent Keys</a>). There + are 100 distinct primary keys, and the ratio of secondary keys + to primary keys ranges to about 20.</p> +<p>The test measures the memory use as a function of the number + of values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_insert_mem_usage_large.cc"><tt>multimap_text_insert_mem_usage_test</tt></a> + thirty_years_among_the_dead_preproc.txt 400 1 6 6)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the insert-time scalability of different + "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Mapping Semantics</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and + <a href="#NTL">NTL</a> show the results for "multimaps" which + use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for + "multimaps" which use a hash-based container for primary keys, + in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, + <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, + and <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTG_res_div"> +<div id="NTG_gcc"> +<div id="NTG_multimap_text_insert_timing_test_large_s2p_tree"> +<div id="NTG_assoc"> +<div id="NTG_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_insert_timing_test_large_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: Native and primary tree-based multimap types insert timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTM_res_div"> +<div id="NTM_msvc"> +<div id="NTM_multimap_text_insert_timing_test_large_s2p_tree"> +<div id="NTM_assoc"> +<div id="NHM_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_insert_timing_test_large_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: NHM Native and primary tree-based multimap types insert timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTL_res_div"> +<div id="NTL_local"> +<div id="NTL_multimap_text_insert_timing_test_large_s2p_tree"> +<div id="NTL_assoc"> +<div id="NTL_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_insert_timing_test_large_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types insert timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHG_res_div"> +<div id="NHG_gcc"> +<div id="NHG_multimap_text_insert_timing_test_large_s2p_hash"> +<div id="NHG_assoc"> +<div id="NHG_Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_insert_timing_test_large_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types insert timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_mmap- +<tt>__gnucxx::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHM_res_div"> +<div id="NHM_msvc"> +<div id="NHM_multimap_text_insert_timing_test_large_s2p_hash"> +<div id="NHM_assoc"> +<div id="NHM_Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_insert_timing_test_large_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types insert timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_mmap- +<tt>stdext::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHL_res_div"> +<div id="NHL_local"> +<div id="NHL_multimap_text_insert_timing_test_large_s2p_hash"> +<div id="NHL_assoc"> +<div id="NHL__Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_insert_timing_test_large_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types insert timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics + Considerations</a>.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_gcc.png Binary files differnew file mode 100644 index 000000000..55b0bf467 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_local.png Binary files differnew file mode 100644 index 000000000..5f8946008 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_msvc.png Binary files differnew file mode 100644 index 000000000..02f5d0b20 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_gcc.png Binary files differnew file mode 100644 index 000000000..83366eb37 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_local.png Binary files differnew file mode 100644 index 000000000..2b496b48d --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_msvc.png Binary files differnew file mode 100644 index 000000000..47196bff7 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small.html new file mode 100644 index 000000000..cda3629b7 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small.html @@ -0,0 +1,217 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>"Multimap" Text Insert Timing Test with Small Average + Secondary-Key to Primary-Key Ratio</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>"Multimap" Text Insert Timing Test with Small Average + Secondary-Key to Primary-Key Ratio</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of pairs into a container. The + first item of each pair is a string from an arbitrary text + [<a href="references.html#wickland96thirty">wickland96thirty</a>], and + the second is a uniform i.i.d.integer. The container is a + "multimap" - it considers the first member of each pair as a + primary key, and the second member of each pair as a secondary + key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Alternative to Multiple Equivalent Keys</a>). There + are 400 distinct primary keys, and the ratio of secondary keys + to primary keys ranges from 1 to 5.</p> +<p>The test measures the average insert-time as a function of + the number of values inserted. For <tt>pb_ds</tt>'s containers, + it inserts a primary key into the primary associative + container, then a secondary key into the secondary associative + container. For the native multimaps, it obtains a range using + <tt>std::equal_range</tt>, and inserts a value only if it was + not contained already.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_insert_timing_small.cc"><tt>multimap_text_insert_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 400 1 1 6)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the insert-time scalability of different + "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Alternative to Multiple Equivalent Keys</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and + <a href="#NTL">NTL</a> show the results for "multimaps" which + use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for + "multimaps" which use a hash-based container for primary keys, + in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, + <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, + and <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTG_res_div"> +<div id="NTG_gcc"> +<div id="NTG_multimap_text_insert_timing_test_small_s2p_tree"> +<div id="NTG_assoc"> +<div id="NTG_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_insert_timing_test_small_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: Native and primary tree-based multimap types insert timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTM_res_div"> +<div id="NTM_msvc"> +<div id="NTM_multimap_text_insert_timing_test_small_s2p_tree"> +<div id="NTM_assoc"> +<div id="NHM_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_insert_timing_test_small_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: NHM Native and primary tree-based multimap types insert timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_mmap- +<tt>std::multimap</tt></li> +<li> +rb_tree_mmap_lu_mtf_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTL_res_div"> +<div id="NTL_local"> +<div id="NTL_multimap_text_insert_timing_test_small_s2p_tree"> +<div id="NTL_assoc"> +<div id="NTL_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_insert_timing_test_small_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types insert timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHG_res_div"> +<div id="NHG_gcc"> +<div id="NHG_multimap_text_insert_timing_test_small_s2p_hash"> +<div id="NHG_assoc"> +<div id="NHG_Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_insert_timing_test_small_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types insert timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_hash_mmap- +<tt>__gnucxx::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHM_res_div"> +<div id="NHM_msvc"> +<div id="NHM_multimap_text_insert_timing_test_small_s2p_hash"> +<div id="NHM_assoc"> +<div id="NHM_Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_insert_timing_test_small_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types insert timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i></li> +<li> +n_hash_mmap- +<tt>stdext::hash_multimap</tt></li> +<li> +cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set- +<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a> +with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a> +, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a> + with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a> +, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a> + with <i>α<sub>min</sub></i> = <i>1/8</i> and <i>α<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a> + with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NHL_res_div"> +<div id="NHL_local"> +<div id="NHL_multimap_text_insert_timing_test_small_s2p_hash"> +<div id="NHL_assoc"> +<div id="NHL_Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_insert_timing_test_small_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types insert timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics + Considerations</a>.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_gcc.png Binary files differnew file mode 100644 index 000000000..3c2d87ecf --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_local.png Binary files differnew file mode 100644 index 000000000..4af78faa5 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_msvc.png Binary files differnew file mode 100644 index 000000000..81d583904 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_gcc.png Binary files differnew file mode 100644 index 000000000..368f07350 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_local.png Binary files differnew file mode 100644 index 000000000..40b5b2c43 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_msvc.png Binary files differnew file mode 100644 index 000000000..99f2d690f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariant_invalidations.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariant_invalidations.png Binary files differnew file mode 100644 index 000000000..bbd91842b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariant_invalidations.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariants.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariants.png Binary files differnew file mode 100644 index 000000000..b375f5168 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariants.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_hash_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_hash_fn.html new file mode 100644 index 000000000..34f1ee06a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_hash_fn.html @@ -0,0 +1,32 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>null_hash_fn Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>null_hash_fn</tt> Interface</h1> + + <p>A "null" hash function, indicating that the combining hash + function is actually a ranged hash function.</p> + + <p><a href= + "concepts.html#concepts_null_policies">Interface::Concepts::Null + Policy Classes</a> explains the concept of a null policy. See + also <a href= + "hash_based_containers.html#hash_policies">Design::Hash-Based + Containers::Hash Policies</a>.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_lu_metadata.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_lu_metadata.html new file mode 100644 index 000000000..e8fb6a3c8 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_lu_metadata.html @@ -0,0 +1,25 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>null_lu_metadata Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>null_lu_metadata</tt> Interface</h1> + + <p>A null type that means that each link in a list-based + container does not actually need metadata.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/list_update_policy.hpp"><tt>list_update_policy.hpp</tt></a></p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_mapped_type.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_mapped_type.html new file mode 100644 index 000000000..d62fac5c9 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_mapped_type.html @@ -0,0 +1,25 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>null_mapped_type Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>null_mapped_type</tt> Interface</h1> + + <p>A mapped-policy indicating that an associative container is + a "set"</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_probe_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_probe_fn.html new file mode 100644 index 000000000..1c8811e96 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_probe_fn.html @@ -0,0 +1,29 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>null_probe_fn Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>null_probe_fn</tt> Interface</h1> + + <p>A "null" probe function, indicating that the combining probe + function is actually a ranged probe function.</p> + + <p><a href= + "concepts.html#concepts_null_policies">Interface::Concepts::Null + Policy Classes</a> explains the concept of a null policy.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_tree_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_tree_node_update.html new file mode 100644 index 000000000..cc1c90054 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_tree_node_update.html @@ -0,0 +1,101 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>null_tree_node_update Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>null_tree_node_update</tt> Interface</h1> + + <p>A "null" node updater, indicating that no node updates are + required.</p> + + <p><a href= + "concepts.html#concepts_null_policies">Interface::Concepts::Null + Policy Classes</a> explains the concept of a null policy.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tree_policy.hpp"><tt>tree_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Const_Node_Iterator1933878761" id= +"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a> +</pre> + </td> + + <td> + <p>Const node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Node_Iterator4206909839" id= +"Node_Iterator4206909839"><b>class</b> Node_Iterator</a> +</pre> + </td> + + <td> + <p>Node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Cmp_Fn294335" id="Cmp_Fn294335"><b>class</b> Cmp_Fn</a> +</pre> + </td> + + <td> + <p>Comparison functor.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator</a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td>-</td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_trie_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_trie_node_update.html new file mode 100644 index 000000000..18ea00739 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_trie_node_update.html @@ -0,0 +1,102 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>null_trie_node_update Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>null_trie_node_update</tt> Interface</h1> + + <p>A "null" node updater, indicating that no node updates are + required.</p> + + <p><a href= + "concepts.html#concepts_null_policies">Interface::Concepts::Null + Policy Classes</a> explains the concept of a null policy.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/trie_policy.hpp"><tt>trie_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Const_Node_Iterator1933878761" id= +"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a> +</pre> + </td> + + <td> + <p>Const node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Node_Iterator4206909839" id= +"Node_Iterator4206909839"><b>class</b> Node_Iterator</a> +</pre> + </td> + + <td> + <p>Node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="E_Access_Traits686553840" id= +"E_Access_Traits686553840"><b>class</b> E_Access_Traits</a> +</pre> + </td> + + <td> + <p>Comparison functor.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator</a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td>-</td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ov_tree_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ov_tree_tag.html new file mode 100644 index 000000000..01d7f9082 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ov_tree_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>ov_tree_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>ov_tree_tag</tt> Interface</h1> + + <p>Ordered-vector tree data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="tree_tag.html"><span class= +"c2"><tt>tree_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_heap_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_heap_tag.html new file mode 100644 index 000000000..5901d1a88 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_heap_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>pairing_heap_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>pairing_heap_tag</tt> Interface</h1> + + <p>Pairing-heap data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="priority_queue_tag.html"><span class= +"c2"><tt>priority_queue_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..4168787ec --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_local.png Binary files differnew file mode 100644 index 000000000..97ca4e9da --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..42b707965 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..9a7ce6c36 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_local.png Binary files differnew file mode 100644 index 000000000..cedcb4cf4 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..d5488efcf --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie.png Binary files differnew file mode 100644 index 000000000..e7129a1a6 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie_tag.html new file mode 100644 index 000000000..2e9a32c91 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>pat_trie_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>pat_trie_tag</tt> Interface</h1> + + <p>PATRICIA trie data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="tree_tag.html"><span class= +"c2"><tt>tree_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_invalidation_guarantee.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_invalidation_guarantee.html new file mode 100644 index 000000000..f67722169 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_invalidation_guarantee.html @@ -0,0 +1,51 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>point_invalidation_guarantee Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>point_invalidation_guarantee</tt> Interface</h1> + + <p>Signifies an invalidation guarantee that includes all those + of its base, and additionally, that any point-type iterator, + pointer, or reference to a container object's mapped value type + is valid as long as its corresponding entry has not be erased, + regardless of modifications to the container object.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="basic_invalidation_guarantee.html"><span class= +"c2"><tt>basic_invalidation_guarantee</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_cd.png Binary files differnew file mode 100644 index 000000000..25a69fc6e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_cd.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_1.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_1.png Binary files differnew file mode 100644 index 000000000..c5bc8e5d6 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_1.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_2.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_2.png Binary files differnew file mode 100644 index 000000000..c3f94ee93 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_2.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_container_traits.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_container_traits.html new file mode 100644 index 000000000..dcd995f5f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_container_traits.html @@ -0,0 +1,132 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>container_traits Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>container_traits</tt> Interface</h1> + + <p>Traits of a priority-queue container based on its underlying + data structure.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Cntnr59189" id="Cntnr59189"><b>class</b> Cntnr</a> +</pre> + </td> + + <td> + <p>Container type.</p> + </td> + + <td>-</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">Container Attributes</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="container_category1247973216" id= +"container_category1247973216">container_category</a> +</pre> + </td> + + <td> + <pre> +Underlying data structure. +</pre> + </td> + + <td> + <p>Data structure category.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="invalidation_guarantee3793555937" id= +"invalidation_guarantee3793555937">invalidation_guarantee</a> +</pre> + </td> + + <td> + <pre> +Invalidation guarantee. +</pre> + </td> + + <td> + <p>Invalidation-guarantee type.</p> + + <p>This is either <a href= + "basic_invalidation_guarantee.html"><span class= + "c2"><tt>basic_invalidation_guarantee</tt></span></a>, + <a href="point_invalidation_guarantee.html"><span class= + "c2"><tt>point_invalidation_guarantee</tt></span></a>, or + <a href="range_invalidation_guarantee.html"><span class= + "c2"><tt>range_invalidation_guarantee</tt></span></a></p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="split_join_can_throw3200477759" id= +"split_join_can_throw3200477759">split_join_can_throw</a> +</pre> + </td> + + <td> + <pre> +True only if split or join operations can throw. +</pre> + </td> + + <td> + <p>Split-join throw indicator.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_design.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_design.html new file mode 100644 index 000000000..959560045 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_design.html @@ -0,0 +1,381 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Priority-Queues</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Priority-Queue Design</h1> + + <h2><a name="overview" id="overview">Overview</a></h2> + + <p>The priority-queue container has the following + declaration:</p> + <pre> +<b>template</b>< + <b>typename</b> Value_Type, + <b>typename</b> Cmp_Fn = std::less<Value_Type>, + <b>typename</b> Tag = <a href="pairing_heap_tag.html">pairing_heap_tag</a>, + <b>typename</b> Allocator = std::allocator<<b>char</b>> > +<b>class</b> <a href="priority_queue.html">priority_queue</a>; +</pre> + + <p>The parameters have the following meaning:</p> + + <ol> + <li><tt>Value_Type</tt> is the value type.</li> + + <li><tt>Cmp_Fn</tt> is a value comparison functor</li> + + <li><tt>Tag</tt> specifies which underlying data structure + to use.</li> + + <li><tt>Allocator</tt> is an allocator + type.</li> + </ol> + + <p>The <tt>Tag</tt> parameter specifies which underlying + data structure to use. Instantiating it by <a href= + "pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>, + <a href= + "binary_heap_tag.html"><tt>binary_heap_tag</tt></a>, + <a href= + "binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>, + <a href= + "rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>, + or <a href= + "thin_heap_tag.html"><tt>thin_heap_tag</tt></a>, + specifies, respectively, an underlying pairing heap [<a href= + "references.html#fredman86pairing">fredman86pairing</a>], + binary heap [<a href="references.html#clrs2001">clrs2001</a>], + binomial heap [<a href= + "references.html#clrs2001">clrs2001</a>], a binomial heap with + a redundant binary counter [<a href= + "references.html#maverik_lowerbounds">maverik_lowerbounds</a>], + or a thin heap [<a href= + "references.html#kt99fat_heaps">kt99fat_heas</a>]. These are + explained further in <a href="#pq_imp">Implementations</a>.</p> + + <p>As mentioned in <a href= + "tutorial.html#pq">Tutorial::Priority Queues</a>, + <a href= + "priority_queue.html"><tt>__gnu_pbds::priority_queue</tt></a> + shares most of the same interface with <tt>std::priority_queue</tt>. + <i>E.g.</i> if <tt>q</tt> is a priority queue of type + <tt>Q</tt>, then <tt>q.top()</tt> will return the "largest" + value in the container (according to <tt><b>typename</b> + Q::cmp_fn</tt>). <a href= + "priority_queue.html"><tt>__gnu_pbds::priority_queue</tt></a> + has a larger (and very slightly different) interface than + <tt>std::priority_queue</tt>, however, since typically + <tt>push</tt> and <tt>pop</tt> are deemed insufficient for + manipulating priority-queues. </p> + + <p>Different settings require different priority-queue + implementations which are described in <a href= + "#pq_imp">Implementations</a>; <a href="#pq_traits">Traits</a> + discusses ways to differentiate between the different traits of + different implementations.</p> + + <h2><a name="pq_it" id="pq_it">Iterators</a></h2> + + <p>There are many different underlying-data structures for + implementing priority queues. Unfortunately, most such + structures are oriented towards making <tt>push</tt> and + <tt>top</tt> efficient, and consequently don't allow efficient + access of other elements: for instance, they cannot support an efficient + <tt>find</tt> method. In the use case where it + is important to both access and "do something with" an + arbitrary value, one would be out of luck. For example, many graph algorithms require + modifying a value (typically increasing it in the sense of the + priority queue's comparison functor).</p> + + <p>In order to access and manipulate an arbitrary value in a + priority queue, one needs to reference the internals of the + priority queue from some form of an associative container - + this is unavoidable. Of course, in order to maintain the + encapsulation of the priority queue, this needs to be done in a + way that minimizes exposure to implementation internals.</p> + + <p>In <tt>pb_ds</tt> the priority queue's <tt>insert</tt> + method returns an iterator, which if valid can be used for subsequent <tt>modify</tt> and + <tt>erase</tt> operations. This both preserves the priority + queue's encapsulation, and allows accessing arbitrary values (since the + returned iterators from the <tt>push</tt> operation can be + stored in some form of associative container).</p> + + <p>Priority queues' iterators present a problem regarding their + invalidation guarantees. One assumes that calling + <tt><b>operator</b>++</tt> on an iterator will associate it + with the "next" value. Priority-queues are + self-organizing: each operation changes what the "next" value + means. Consequently, it does not make sense that <tt>push</tt> + will return an iterator that can be incremented - this can have + no possible use. Also, as in the case of hash-based containers, + it is awkward to define if a subsequent <tt>push</tt> operation + invalidates a prior returned iterator: it invalidates it in the + sense that its "next" value is not related to what it + previously considered to be its "next" value. However, it might not + invalidate it, in the sense that it can be + de-referenced and used for <tt>modify</tt> and <tt>erase</tt> + operations.</p> + + <p>Similarly to the case of the other unordered associative + containers, <tt>pb_ds</tt> uses a distinction between + point-type and range type iterators. A priority queue's <tt>iterator</tt> can always be + converted to a <tt>point_iterator</tt>, and a + <tt>const_iterator</tt> can always be converted to a + <tt>const_point_iterator</tt>.</p> + + <p>The following snippet demonstrates manipulating an arbitrary + value:</p> + <pre> +<i>// A priority queue of integers.</i> +<a href= +"priority_queue.html">priority_queue</a><<b>int</b>> p; + +<i>// Insert some values into the priority queue.</i> +<a href= +"priority_queue.html">priority_queue</a><<b>int</b>>::point_iterator it = p.push(0); + +p.push(1); +p.push(2); + +<i>// Now modify a value.</i> +p.modify(it, 3); + +assert(p.top() == 3); +</pre> + + <p>(<a href="pq_examples.html#xref">Priority Queue + Examples::Cross-Referencing</a> shows a more detailed + example.)</p> + + <p>It should be noted that an alternative design could embed an + associative container in a priority queue. Could, but most probably should not. To begin with, it should be noted that one + could always encapsulate a priority queue and an associative + container mapping values to priority queue iterators with no + performance loss. One cannot, however, "un-encapsulate" a + priority queue embedding an associative container, which might + lead to performance loss. Assume, that one needs to + associate each value with some data unrelated to priority + queues. Then using <tt>pb_ds</tt>'s design, one could use an + associative container mapping each value to a pair consisting + of this data and a priority queue's iterator. Using the + embedded method would need to use two associative + containers. Similar problems might arise in cases where a value + can reside simultaneously in many priority queues.</p> + + <h2><a name="pq_imp" id="pq_imp">Implementations</a></h2> + + <p>There are three main implementations of priority queues: the + first employs a binary heap, typically one which uses a + sequence; the second uses a tree (or forest of trees), which is + typically less structured than an associative container's tree; + the third simply uses an associative container. These are + shown, respectively, in Figures <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> A1 and A2, Figure <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> B, and Figures <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> C.</p> + + <h6 class="c1"><a name="pq_different_underlying_dss" id= + "pq_different_underlying_dss"><img src= + "pq_different_underlying_dss.png" alt="no image" /></a></h6> + + <h6 class="c1">Underlying Priority-Queue Data-Structures.</h6> + + <p>Roughly speaking, any value that is both pushed and popped + from a priority queue must incur a logarithmic expense (in the + amortized sense). Any priority queue implementation that would + avoid this, would violate known bounds on comparison-based + sorting (see, <i>e.g.</i>, [<a href= + "references.html#clrs2001">clrs2001</a>] and <a href= + "references.html#brodal96priority">brodal96priority</a>]).</p> + + <p>Most implementations do + not differ in the asymptotic amortized complexity of + <tt>push</tt> and <tt>pop</tt> operations, but they differ in + the constants involved, in the complexity of other operations + (<i>e.g.</i>, <tt>modify</tt>), and in the worst-case + complexity of single operations. In general, the more + "structured" an implementation (<i>i.e.</i>, the more internal + invariants it possesses) - the higher its amortized complexity + of <tt>push</tt> and <tt>pop</tt> operations.</p> + + <p><tt>pb_ds</tt> implements different algorithms using a + single class: <a href="priority_queue.html">priority_queue</a>. + Instantiating the <tt>Tag</tt> template parameter, "selects" + the implementation:</p> + + <ol> + <li>Instantiating <tt>Tag = <a href= + "binary_heap_tag.html">binary_heap_tag</a></tt> creates + a binary heap of the form in Figures <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> A1 or A2. The former is internally + selected by <a href="priority_queue.html">priority_queue</a> + if <tt>Value_Type</tt> is instantiated by a primitive type + (<i>e.g.</i>, an <tt><b>int</b></tt>); the latter is + internally selected for all other types (<i>e.g.</i>, + <tt>std::string</tt>). This implementations is relatively + unstructured, and so has good <tt>push</tt> and <tt>pop</tt> + performance; it is the "best-in-kind" for primitive + types, <i>e.g.</i>, <tt><b>int</b></tt>s. Conversely, it has + high worst-case performance, and can support only linear-time + <tt>modify</tt> and <tt>erase</tt> operations; this is + explained further in <a href="#pq_traits">Traits</a>.</li> + + <li>Instantiating <tt>Tag = <a href= + "pairing_heap_tag.html">pairing_heap_tag</a></tt> + creates a pairing heap of the form in Figure <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> B. This implementations too is relatively + unstructured, and so has good <tt>push</tt> and <tt>pop</tt> + performance; it is the "best-in-kind" for non-primitive + types, <i>e.g.</i>, <tt>std:string</tt>s. It also has very + good worst-case <tt>push</tt> and <tt>join</tt> performance + (<i>O(1)</i>), but has high worst-case <tt>pop</tt> + complexity.</li> + + <li>Instantiating <tt>Tag = <a href= + "binomial_heap_tag.html">binomial_heap_tag</a></tt> + creates a binomial heap of the form in Figure <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> B. This implementations is more + structured than a pairing heap, and so has worse + <tt>push</tt> and <tt>pop</tt> performance. Conversely, it + has sub-linear worst-case bounds for <tt>pop</tt>, + <i>e.g.</i>, and so it might be preferred in cases where + responsiveness is important.</li> + + <li>Instantiating <tt>Tag = <a href= + "rc_binomial_heap_tag.html">rc_binomial_heap_tag</a></tt> + creates a binomial heap of the form in Figure <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> B, accompanied by a redundant counter + which governs the trees. This implementations is therefore + more structured than a binomial heap, and so has worse + <tt>push</tt> and <tt>pop</tt> performance. Conversely, it + guarantees <i>O(1)</i> <tt>push</tt> complexity, and so it + might be preferred in cases where the responsiveness of a + binomial heap is insufficient.</li> + + <li>Instantiating <tt>Tag = <a href= + "thin_heap_tag.html">thin_heap_tag</a></tt> creates a + thin heap of the form in Figure <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> B. This implementations too is more + structured than a pairing heap, and so has worse + <tt>push</tt> and <tt>pop</tt> performance. Conversely, it + has better worst-case and identical amortized complexities + than a Fibonacci heap, and so might be more appropriate for + some graph algorithms.</li> + </ol> + + <p><a href="pq_performance_tests.html">Priority-Queue + Performance Tests</a> shows some results for the above, and + discusses these points further.</p> + + <p>Of course, one can use any order-preserving associative + container as a priority queue, as in Figure <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> C, possibly by creating an adapter class + over the associative container (much as + <tt>std::priority_queue</tt> can adapt <tt>std::vector</tt>). + This has the advantage that no cross-referencing is necessary + at all; the priority queue itself is an associative container. + Most associative containers are too structured to compete with + priority queues in terms of <tt>push</tt> and <tt>pop</tt> + performance.</p> + + <h2><a name="pq_traits" id="pq_traits">Traits</a></h2> + + <p>It would be nice if all priority queues could + share exactly the same behavior regardless of implementation. Sadly, this is not possible. Just one for instance is in join operations: joining + two binary heaps might throw an exception (not corrupt + any of the heaps on which it operates), but joining two pairing + heaps is exception free.</p> + + <p>Tags and traits are very useful for manipulating generic + types. <a href= + "priority_queue.html"><tt>__gnu_pbds::priority_queue</tt></a> + publicly defines <tt>container_category</tt> as one of the tags + discussed in <a href="#pq_imp">Implementations</a>. Given any + container <tt>Cntnr</tt>, the tag of the underlying + data structure can be found via <tt><b>typename</b> + Cntnr::container_category</tt>; this is one of the types shown in + Figure <a href="#pq_tag_cd">Data-structure tag class + hierarchy</a>.</p> + + <h6 class="c1"><a name="pq_tag_cd" id= + "pq_tag_cd"><img src="priority_queue_tag_cd.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Data-structure tag class hierarchy.</h6> + + <p>Additionally, a traits mechanism can be used to query a + container type for its attributes. Given any container + <tt>Cntnr</tt>, then <tt><a href= + "assoc_container_traits.html">__gnu_pbds::container_traits</a><Cntnr></tt> + is a traits class identifying the properties of the + container.</p> + + <p>To find if a container might throw if two of its objects are + joined, one can use <a href= + "assoc_container_traits.html"><tt>container_traits</tt></a><tt><Cntnr>::split_join_can_throw</tt>, + for example.</p> + + <p>Different priority-queue implementations have different invalidation guarantees. This is + especially important, since as explained in <a href= + "#pq_it">Iterators</a>, there is no way to access an arbitrary + value of priority queues except for iterators. Similarly to + associative containers, one can use + <a href= + "assoc_container_traits.html"><tt>container_traits</tt></a><tt><Cntnr>::invalidation_guarantee</tt> + to get the invalidation guarantee type of a priority queue.</p> + + <p>It is easy to understand from Figure <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a>, what <a href= + "assoc_container_traits.html"><tt>container_traits</tt></a><tt><Cntnr>::invalidation_guarantee</tt> + will be for different implementations. All implementations of + type <a href="#pq_different_underlying_dss">Underlying + Priority-Queue Data-Structures</a> B have <a href= + "point_invalidation_guarantee.html"><tt>point_invalidation_guarantee</tt></a>: + the container can freely internally reorganize the nodes - + range-type iterators are invalidated, but point-type iterators + are always valid. Implementations of type <a href= + "#pq_different_underlying_dss">Underlying Priority-Queue + Data-Structures</a> A1 and A2 have <a href= + "basic_invalidation_guarantee.html"><tt>basic_invalidation_guarantee</tt></a>: + the container can freely internally reallocate the array - both + point-type and range-type iterators might be invalidated.</p> + + <p>This has major implications, and constitutes a good reason to avoid + using binary heaps. A binary heap can perform <tt>modify</tt> + or <tt>erase</tt> efficiently <u>given a valid point-type + iterator</u>. However, inn order to supply it with a valid point-type + iterator, one needs to iterate (linearly) over all + values, then supply the relevant iterator (recall that a + range-type iterator can always be converted to a point-type + iterator). This means that if the number of <tt>modify</tt> or + <tt>erase</tt> operations is non-negligible (say + super-logarithmic in the total sequence of operations) - binary + heaps will perform badly.</p> + <pre> + +</pre> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_different_underlying_dss.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_different_underlying_dss.png Binary files differnew file mode 100644 index 000000000..9d84791fc --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_different_underlying_dss.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html new file mode 100644 index 000000000..15311ebc3 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html @@ -0,0 +1,54 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Examples</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Priority-Queue Examples</h1> + + <h2><a name="basic_usage" id="basic_usage">Basic Use</a></h2> + + <ol> + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_priority_queue.cc"><tt>basic_priority_queue.cc</tt></a> + Basic use of priority queues.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/priority_queue_split_join.cc"><tt>priority_queue_split_join.cc</tt></a> + Splitting and joining priority queues.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/priority_queue_erase_if.cc"><tt>priority_queue_erase_if.cc</tt></a> + Conditionally erasing values from a container object.</li> + </ol> + + <h2><a name="generics" id="generics">Generics</a></h2> + + <ol> + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/priority_queue_container_traits.cc"><tt>priority_queue_container_traits.cc</tt></a> + Using <a href="assoc_container_traits.html"><tt>container_traits</tt></a> + to query about underlying data structure behavior.</li> + </ol> + + <h2><a name="xref" id="xref">Cross Referencing</a></h2> + + + <ol> + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/priority_queue_xref.cc"><tt>priority_queue_xref.cc</tt></a> + Cross referencing an associative container and a priority + queue.</li> + + <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/priority_queue_dijkstra.cc"><tt>priority_queue_dijkstra.cc</tt></a> + Cross referencing a vector and a priority queue using a + <u>very</u> simple version of Dijkstra's shortest path + algorithm.</li> + </ol> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_performance_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_performance_tests.html new file mode 100644 index 000000000..3a6b26912 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_performance_tests.html @@ -0,0 +1,332 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Priority-Queue Performance Tests</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Priority-Queue Performance Tests</h1> +<h2><a name="settings" id="settings">Settings</a></h2> +<p>This section describes performance tests and their results. + In the following, <a href="#gcc"><u>g++</u></a>, <a href="#msvc"><u>msvc++</u></a>, and <a href="#local"><u>local</u></a> (the build used for generating this + documentation) stand for three different builds:</p> +<div id="gcc_settings_div"> +<div class="c1"> +<h3><a name="gcc" id="gcc"><u>g++</u></a></h3> +<ul> +<li>CPU speed - cpu MHz : 2660.644</li> +<li>Memory - MemTotal: 484412 kB</li> +<li>Platform - + Linux-2.6.12-9-386-i686-with-debian-testing-unstable</li> +<li>Compiler - g++ (GCC) 4.0.2 20050808 (prerelease) + (Ubuntu 4.0.1-4ubuntu9) Copyright (C) 2005 Free Software + Foundation, Inc. This is free software; see the source + for copying conditions. There is NO warranty; not even + for MERCHANTABILITY or FITNESS FOR A PARTICULAR + PURPOSE.</li> +</ul> +</div> +<div class="c2"></div> +</div> +<div id="msvc_settings_div"> +<div class="c1"> +<h3><a name="msvc" id="msvc"><u>msvc++</u></a></h3> +<ul> +<li>CPU speed - cpu MHz : 2660.554</li> +<li>Memory - MemTotal: 484412 kB</li> +<li>Platform - Windows XP Pro</li> +<li>Compiler - Microsoft (R) 32-bit C/C++ Optimizing + Compiler Version 13.10.3077 for 80x86 Copyright (C) + Microsoft Corporation 1984-2002. All rights + reserved.</li> +</ul> +</div> +<div class="c2"></div> +</div> +<div id="local_settings_div"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h3><a name = "local"><u>local</u></a></h3><ul> +<li>CPU speed - cpu MHz : 2250.000</li> +<li>Memory - MemTotal: 2076248 kB</li> +<li>Platform - Linux-2.6.16-1.2133_FC5-i686-with-redhat-5-Bordeaux</li> +<li>Compiler - g++ (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) +Copyright (C) 2006 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +</li> +</ul> +</div><div style = "width: 100%; height: 20px"></div></div> +<h2><a name="pq_tests" id="pq_tests">Tests</a></h2> +<ol> +<li><a href="priority_queue_text_push_timing_test.html">Priority Queue + Text <tt>push</tt> Timing Test</a></li> +<li><a href="priority_queue_text_push_pop_timing_test.html">Priority + Queue Text <tt>push</tt> and <tt>pop</tt> Timing + Test</a></li> +<li><a href="priority_queue_random_int_push_timing_test.html">Priority + Queue Random Integer <tt>push</tt> Timing Test</a></li> +<li><a href="priority_queue_random_int_push_pop_timing_test.html">Priority + Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing + Test</a></li> +<li><a href="priority_queue_text_pop_mem_usage_test.html">Priority Queue + Text <tt>pop</tt> Memory Use Test</a></li> +<li><a href="priority_queue_text_join_timing_test.html">Priority Queue + Text <tt>join</tt> Timing Test</a></li> +<li><a href="priority_queue_text_modify_up_timing_test.html">Priority + Queue Text <tt>modify</tt> Timing Test - I</a></li> +<li><a href="priority_queue_text_modify_down_timing_test.html">Priority + Queue Text <tt>modify</tt> Timing Test - II</a></li> +</ol> +<h2><a name="pq_observations" id="pq_observations">Observations</a></h2> +<h3><a name="pq_observations_cplx" id="pq_observations_cplx">Underlying Data Structures + Complexity</a></h3> +<p>The following table shows the complexities of the different + underlying data structures in terms of orders of growth. It is + interesting to note that this table implies something about the + constants of the operations as well (see <a href="#pq_observations_amortized_push_pop">Amortized <tt>push</tt> + and <tt>pop</tt> operations</a>).</p> +<table class="c1" width="100%" border="1" summary="pq complexities"> +<tr> +<td align="left"></td> +<td align="left"><tt>push</tt></td> +<td align="left"><tt>pop</tt></td> +<td align="left"><tt>modify</tt></td> +<td align="left"><tt>erase</tt></td> +<td align="left"><tt>join</tt></td> +</tr> +<tr> +<td align="left"> +<p><tt>std::priority_queue</tt></p> +</td> +<td align="left"> +<p><i>Θ(n)</i> worst</p> +<p><i>Θ(log(n))</i> amortized</p> +</td> +<td align="left"> +<p class="c1">Θ(log(n)) Worst</p> +</td> +<td align="left"> +<p><i>Theta;(n log(n))</i> Worst</p> +<p><sub><a href="#std_mod1">[std note 1]</a></sub></p> +</td> +<td align="left"> +<p class="c3">Θ(n log(n))</p> +<p><sub><a href="#std_mod2">[std note 2]</a></sub></p> +</td> +<td align="left"> +<p class="c3">Θ(n log(n))</p> +<p><sub><a href="#std_mod1">[std note 1]</a></sub></p> +</td> +</tr> +<tr> +<td align="left"> +<p><a href="priority_queue.html"><tt>priority_queue</tt></a></p> +<p>with <tt>Tag</tt> =</p> +<p><a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a></p> +</td> +<td align="left"> +<p class="c1">O(1)</p> +</td> +<td align="left"> +<p><i>Θ(n)</i> worst</p> +<p><i>Θ(log(n))</i> amortized</p> +</td> +<td align="left"> +<p><i>Θ(n)</i> worst</p> +<p><i>Θ(log(n))</i> amortized</p> +</td> +<td align="left"> +<p><i>Θ(n)</i> worst</p> +<p><i>Θ(log(n))</i> amortized</p> +</td> +<td align="left"> +<p class="c1">O(1)</p> +</td> +</tr> +<tr> +<td align="left"> +<p><a href="priority_queue.html"><tt>priority_queue</tt></a></p> +<p>with <tt>Tag</tt> =</p> +<p><a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a></p> +</td> +<td align="left"> +<p><i>Θ(n)</i> worst</p> +<p><i>Θ(log(n))</i> amortized</p> +</td> +<td align="left"> +<p><i>Θ(n)</i> worst</p> +<p><i>Θ(log(n))</i> amortized</p> +</td> +<td align="left"> +<p class="c1">Θ(n)</p> +</td> +<td align="left"> +<p class="c1">Θ(n)</p> +</td> +<td align="left"> +<p class="c1">Θ(n)</p> +</td> +</tr> +<tr> +<td align="left"> +<p><a href="priority_queue.html"><tt>priority_queue</tt></a></p> +<p>with <tt>Tag</tt> =</p> +<p><a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a></p> +</td> +<td align="left"> +<p><i>Θ(log(n))</i> worst</p> +<p><i>O(1)</i> amortized</p> +</td> +<td align="left"> +<p class="c1">Θ(log(n))</p> +</td> +<td align="left"> +<p class="c1">Θ(log(n))</p> +</td> +<td align="left"> +<p class="c1">Θ(log(n))</p> +</td> +<td align="left"> +<p class="c1">Θ(log(n))</p> +</td> +</tr> +<tr> +<td align="left"> +<p><a href="priority_queue.html"><tt>priority_queue</tt></a></p> +<p>with <tt>Tag</tt> =</p> +<p><a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a></p> +</td> +<td align="left"> +<p class="c1">O(1)</p> +</td> +<td align="left"> +<p class="c1">Θ(log(n))</p> +</td> +<td align="left"> +<p class="c1">Θ(log(n))</p> +</td> +<td align="left"> +<p class="c1">Θ(log(n))</p> +</td> +<td align="left"> +<p class="c1">Θ(log(n))</p> +</td> +</tr> +<tr> +<td align="left"> +<p><a href="priority_queue.html"><tt>priority_queue</tt></a></p> +<p>with <tt>Tag</tt> =</p> +<p><a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a></p> +</td> +<td align="left"> +<p class="c1">O(1)</p> +</td> +<td align="left"> +<p><i>Θ(n)</i> worst</p> +<p><i>Θ(log(n))</i> amortized</p> +</td> +<td align="left"> +<p><i>Θ(log(n))</i> worst</p> +<p><i>O(1)</i> amortized,</p>or + + <p><i>Θ(log(n))</i> amortized</p> +<p><sub><a href="#thin_heap_note">[thin_heap_note]</a></sub></p> +</td> +<td align="left"> +<p><i>Θ(n)</i> worst</p> +<p><i>Θ(log(n))</i> amortized</p> +</td> +<td align="left"> +<p class="c1">Θ(n)</p> +</td> +</tr> +</table> +<p><sub><a name="std_mod1" id="std_mod1">[std note 1]</a> This + is not a property of the algorithm, but rather due to the fact + that the STL's priority queue implementation does not support + iterators (and consequently the ability to access a specific + value inside it). If the priority queue is adapting an + <tt>std::vector</tt>, then it is still possible to reduce this + to <i>Θ(n)</i> by adapting over the STL's adapter and + using the fact that <tt>top</tt> returns a reference to the + first value; if, however, it is adapting an + <tt>std::deque</tt>, then this is impossible.</sub></p> +<p><sub><a name="std_mod2" id="std_mod2">[std note 2]</a> As + with <a href="#std_mod1">[std note 1]</a>, this is not a + property of the algorithm, but rather the STL's implementation. + Again, if the priority queue is adapting an + <tt>std::vector</tt> then it is possible to reduce this to + <i>Θ(n)</i>, but with a very high constant (one must call + <tt>std::make_heap</tt> which is an expensive linear + operation); if the priority queue is adapting an + <tt>std::dequeu</tt>, then this is impossible.</sub></p> +<p><sub><a name="thin_heap_note" id="thin_heap_note">[thin_heap_note]</a> A thin heap has + <i>&Theta(log(n))</i> worst case <tt>modify</tt> time + always, but the amortized time depends on the nature of the + operation: I) if the operation increases the key (in the sense + of the priority queue's comparison functor), then the amortized + time is <i>O(1)</i>, but if II) it decreases it, then the + amortized time is the same as the worst case time. Note that + for most algorithms, I) is important and II) is not.</sub></p> +<h3><a name="pq_observations_amortized_push_pop" id="pq_observations_amortized_push_pop">Amortized <tt>push</tt> + and <tt>pop</tt> operations</a></h3> +<p>In many cases, a priority queue is needed primarily for + sequences of <tt>push</tt> and <tt>pop</tt> operations. All of + the underlying data structures have the same amortized + logarithmic complexity, but they differ in terms of + constants.</p> +<p>The table above shows that the different data structures are + "constrained" in some respects. In general, if a data structure + has lower worst-case complexity than another, then it will + perform slower in the amortized sense. Thus, for example a + redundant-counter binomial heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with + <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>) + has lower worst-case <tt>push</tt> performance than a binomial + heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>), + and so its amortized <tt>push</tt> performance is slower in + terms of constants.</p> +<p>As the table shows, the "least constrained" underlying + data structures are binary heaps and pairing heaps. + Consequently, it is not surprising that they perform best in + terms of amortized constants.</p> +<ol> +<li>Pairing heaps seem to perform best for non-primitive + types (<i>e.g.</i>, <tt>std::string</tt>s), as shown by + <a href="priority_queue_text_push_timing_test.html">Priority + Queue Text <tt>push</tt> Timing Test</a> and <a href="priority_queue_text_push_pop_timing_test.html">Priority + Queue Text <tt>push</tt> and <tt>pop</tt> Timing + Test</a></li> +<li>binary heaps seem to perform best for primitive types + (<i>e.g.</i>, <tt><b>int</b></tt>s), as shown by <a href="priority_queue_random_int_push_timing_test.html">Priority + Queue Random Integer <tt>push</tt> Timing Test</a> and + <a href="priority_queue_random_int_push_pop_timing_test.html">Priority + Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing + Test</a>.</li> +</ol> +<h3><a name="pq_observations_graph" id="pq_observations_graph">Graph Algorithms</a></h3> +<p>In some graph algorithms, a decrease-key operation is + required [<a href="references.html#clrs2001">clrs2001</a>]; + this operation is identical to <tt>modify</tt> if a value is + increased (in the sense of the priority queue's comparison + functor). The table above and <a href="priority_queue_text_modify_up_timing_test.html">Priority Queue + Text <tt>modify</tt> Timing Test - I</a> show that a thin heap + (<a href="priority_queue.html"><tt>priority_queue</tt></a> with + <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>) + outperforms a pairing heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with + <tt>Tag</tt> =<tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>), + but the rest of the tests show otherwise.</p> +<p>This makes it difficult to decide which implementation to + use in this case. Dijkstra's shortest-path algorithm, for + example, requires <i>Θ(n)</i> <tt>push</tt> and + <tt>pop</tt> operations (in the number of vertices), but + <i>O(n<sup>2</sup>)</i> <tt>modify</tt> operations, which can + be in practice <i>Θ(n)</i> as well. It is difficult to + find an <i>a-priori</i> characterization of graphs in which the + <u>actual</u> number of <tt>modify</tt> operations will dwarf + the number of <tt>push</tt> and <tt>pop</tt> operations.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_regression_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_regression_tests.html new file mode 100644 index 000000000..9084409d3 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_regression_tests.html @@ -0,0 +1,52 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Priority-Queue Regression Tests</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Priority-Queue Regression Tests</h1> + + <h2><a name="assoc_desc" id="assoc_desc">Description</a></h2> + + <p>The library contains a single comprehensive regression test. + For a given container type in <tt>pb_ds</tt>, the test creates + an object of the container type and an object of the + corresponding STL type (<i>i.e.</i>, + <tt>std::priority_queue</tt>). It then performs a random + sequence of methods with random arguments (<i>e.g.</i>, pushes, + pops, and so forth) on both objects. At each operation, the + test checks the return value of the method, and optionally both + compares <tt>pb_ds</tt>'s object with the STL's object as well + as performing other consistency checks on <tt>pb_ds</tt>'s + object (<i>e.g.</i>, that the size returned by the + <tt>size</tt> method corresponds to the distance between its + <tt>begin</tt> and end iterators).</p> + + <p>Additionally, the test integrally checks exception safety + and resource leaks. This is done as follows. A special + allocator type, written for the purpose of the test, both + randomly throws an exceptions when allocations are performed, + and tracks allocations and de-allocations. The exceptions thrown + at allocations simulate memory-allocation failures; the + tracking mechanism checks for memory-related bugs (<i>e.g.</i>, + resource leaks and multiple de-allocations). Both + <tt>pb_ds</tt>'s containers and the containers' value-types are + configured to use this allocator.</p> + + <h2><a name="pq_tests" id="pq_tests">Tests</a></h2> + + <p><a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/regression/priority_queue_rand.cc"><tt>priority_queue_rand.cc</tt></a> + checks all priority queue types.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_tests.html new file mode 100644 index 000000000..de8cb447c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_tests.html @@ -0,0 +1,24 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Priority-Queue Tests</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Priority-Queue Tests</h1> + + <p><a href="pq_regression_tests.html">Priority-Queue Regression + Tests</a> describes the regression tests; <a href= + "pq_performance_tests.html">Priority-Queue Performance + Tests</a> describes the performance tests.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/prerequisites.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/prerequisites.html new file mode 100644 index 000000000..7c8888499 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/prerequisites.html @@ -0,0 +1,46 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Prerequisites</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Usage Prerequisites</h1> + + <p><tt>pb_ds</tt> has been successfully tested with the + following compilers:</p> + + <ol> + <li>g++ 3.3.1, 3.4.4, 4.0, 4.1, and what will be 4.2</li> + + <li>Intel icpc 8.1 and 9</li> + + <li>Visual C++ .Net 2005</li> + </ol> + + <p>The library contains only header files, and does not require + any other libraries except the STL. All classes are defined in + <tt><b>namespace</b> pb_ds</tt>. The library internally uses + macros beginning with <tt>PB_DS</tt> (<i>e.g.</i>, for header + guards), but <tt>#<b>undef</b></tt>s anything it + <tt>#<b>define</b></tt>s (except for header guards). Compiling + the library in an environment where macros beginning in + <tt>PB_DS</tt> are defined, may yield unpredictable results in + compilation, execution, or both.</p> + + <p> Further dependencies are necessary to create the visual output + for the performance tests. To create these graphs, two additional + packages will be needed: <b>pychart</b> and <b>Beautiful + Soup</b>. Both are freely available. + </p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue.html new file mode 100644 index 000000000..def310f0c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue.html @@ -0,0 +1,995 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>priority_queue Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>priority_queue</tt> Interface</h1> + + <p>Basic priority queue.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/priority_queue.hpp"><tt>priority_queue.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Value_Type216514186" id= +"Value_Type216514186"><b>typename</b> Value_Type</a> +</pre> + </td> + + <td> + <p>Value type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Cmp_Fn294335" id="Cmp_Fn294335"><b>class</b> Cmp_Fn </a> +</pre> + </td> + + <td> + <p>Comparison functor.</p> + </td> + + <td> + <pre> +std::less<<a href= +"#Value_Type216514186"><tt>Value_Type</tt></a>> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Tag278938" id="Tag278938"><b>class</b> Tag </a> +</pre> + </td> + + <td> + <p>Data-structure tag.</p> + </td> + + <td><a href="pairing_heap_tag.html"><span class= + "c2"><tt>pairing_heap_tag</tt></span></a></td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator </a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td> + <pre> +std::allocator<<b>char</b>> +</pre> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Container + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::size_type +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="difference_type868028452" id= +"difference_type868028452">difference_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::difference_type +</pre> + </td> + + <td> + <p>Difference type.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">Categories</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="container_category1247973216" id= +"container_category1247973216">container_category</a> +</pre> + </td> + + <td> + <pre> +<a href="#Tag278938"><tt>Tag</tt></a> +</pre> + </td> + + <td> + <p>The underlying mapped-structure tag of the + container.</p> + + <p>This is one of:</p> + + <ol> + <li><a href="binary_heap_tag.html"><span class= + "c2"><tt>binary_heap_tag</tt></span></a></li> + + <li><a href="binomial_heap_tag.html"><span class= + "c2"><tt>binomial_heap_tag</tt></span></a></li> + + <li><a href="rc_binomial_heap_tag.html"><span class= + "c2"><tt>rc_binomial_heap_tag</tt></span></a></li> + + <li><a href="pairing_heap_tag.html"><span class= + "c2"><tt>pairing_heap_tag</tt></span></a></li> + + <li><a href="thin_heap_tag.html"><span class= + "c2"><tt>thin_heap_tag</tt></span></a></li> + </ol> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="cmp_fn394495" id="cmp_fn394495">cmp_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Cmp_Fn294335"><tt>Cmp_Fn</tt></a> +</pre> + </td> + + <td> + <p>Comparison functor type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="allocator48440069" id="allocator48440069">allocator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Allocator35940069"><tt>Allocator</tt></a> +</pre> + </td> + + <td> + <p><a href="#Allocator35940069"><tt>Allocator</tt></a> + type.</p> + </td> + </tr> + </table> + + <h3><a name="link6" id="link6">Value-Type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="value_type279018186" id= +"value_type279018186">value_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#Value_Type216514186"><tt>Value_Type</tt></a> +</pre> + </td> + + <td> + <p>Value type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="reference54418471" id="reference54418471">reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#value_type279018186"><tt>value_type</tt></a>>::other::reference +</pre> + </td> + + <td> + <p>Value reference type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_reference495461441" id= +"const_reference495461441">const_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#value_type279018186"><tt>value_type</tt></a>>::other::const_reference +</pre> + </td> + + <td> + <p>Const value <a href= + "#reference54418471"><tt>reference</tt></a> type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="pointer2179769" id="pointer2179769">pointer</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#value_type279018186"><tt>value_type</tt></a>>::other::pointer +</pre> + </td> + + <td> + <p>Value pointer type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_pointer878814947" id= +"const_pointer878814947">const_pointer</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind< + <a href= +"#value_type279018186"><tt>value_type</tt></a>>::other::const_pointer +</pre> + </td> + + <td> + <p>Const Value <a href= + "#pointer2179769"><tt>pointer</tt></a> type.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Iterator Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_point_iterator2364676009" id= +"const_point_iterator2364676009">const_point_iterator</a> +</pre> + </td> + + <td> + <pre> +Const point-type iterator. +</pre> + </td> + + <td> + <p>Const point-type iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="point_iterator2789896775" id= +"point_iterator2789896775">point_iterator</a> +</pre> + </td> + + <td> + <pre> +Point-type iterator. +</pre> + </td> + + <td> + <p>Point-type iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_iterator98626788" id= +"const_iterator98626788">const_iterator</a> +</pre> + </td> + + <td> + <pre> +Const range-type iterator. +</pre> + </td> + + <td> + <p>Const range-type iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="iterator10418194" id="iterator10418194">iterator</a> +</pre> + </td> + + <td> + <pre> +Range-type iterator. +</pre> + </td> + + <td> + <p>Range-type iterator.</p> + </td> + </tr> + </table> + + <h2><a name="link8" id="link8">Public Methods</a></h2> + + <h3><a name="link9" id="link9">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + priority_queue + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> + priority_queue + (<b>const</b> <a href= +"#cmp_fn394495"><tt>cmp_fn</tt></a> &r_cmp_fn) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_cmp_fn</tt></span> will be copied by the + <a href="#Cmp_Fn294335"><tt>Cmp_Fn</tt></a> object of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + priority_queue + (It first_it, + It last_it) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of <a href= + "#value_type279018186"><tt>value_type</tt></a>s. The + <a href="#value_type279018186"><tt>value_type</tt></a>s + between <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + priority_queue + (It first_it, + It last_it, + <b>const</b> <a href= +"#cmp_fn394495"><tt>cmp_fn</tt></a> &r_cmp_fn) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of <a href= + "#value_type279018186"><tt>value_type</tt></a>s and some + policy objects The <a href= + "#value_type279018186"><tt>value_type</tt></a>s between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object. <span class= + "c1"><tt>r_cmp_fn</tt></span> will be copied by the + <a href="#cmp_fn394495"><tt>cmp_fn</tt></a> object of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + priority_queue + (<b>const</b> <span class= +"c2"><tt>priority_queue</tt></span> &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~priority_queue + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<span class="c2"><tt>priority_queue</tt></span> & + <b>operator</b>= + (<b>const</b> <span class= +"c2"><tt>priority_queue</tt></span> &other) +</pre> + </td> + + <td> + <p>Assignment operator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class="c2"><tt>priority_queue</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h3><a name="link10" id="link10">Information Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + size + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns the number of distinct <a href= + "#value_type279018186"><tt>value_type</tt></a> objects + the container object is storing.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + max_size + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns an upper bound on the number of distinct + <a href="#value_type279018186"><tt>value_type</tt></a> + objects this container can store.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + empty + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns whether the container object is not storing + any <a href= + "#value_type279018186"><tt>value_type</tt></a> + objects.</p> + </td> + </tr> + </table> + + <h3><a name="link11" id="link11">Insert Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"#point_iterator2789896775"><tt>point_iterator</tt></a> + push + (<a href= +"#const_reference495461441"><tt>const_reference</tt></a> r_val) +</pre> + </td> + + <td> + <p>Inserts a <a href= + "#value_type279018186"><tt>value_type</tt></a> object. + returns a <a href= + "#point_iterator2789896775"><tt>point_iterator</tt></a> + object associated with the new pushed <span class= + "c1"><tt>r_val</tt></span>.</p> + </td> + </tr> + </table> + + <h3><a name="link12" id="link12">Find Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"#const_reference495461441"><tt>const_reference</tt></a> + top + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns the <a href= + "#const_reference495461441"><tt>const_reference</tt></a> + of the largest <a href= + "#value_type279018186"><tt>value_type</tt></a> in the + container object, i.e., a <a href= + "#value_type279018186"><tt>value_type</tt></a> v_max for + which any other <a href= + "#value_type279018186"><tt>value_type</tt></a> v in the + container object will satisfy !<a href= + "#cmp_fn394495"><tt>cmp_fn</tt></a>()(v_max, v).</p> + </td> + </tr> + </table> + + <h3><a name="link13" id="link13">Modify Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + modify + (<a href= +"#point_iterator2789896775"><tt>point_iterator</tt></a> it, + <a href= +"#const_reference495461441"><tt>const_reference</tt></a> r_new_val) +</pre> + </td> + + <td> + <p>Modifies the <a href= + "#value_type279018186"><tt>value_type</tt></a> associated + with the <a href= + "#point_iterator2789896775"><tt>point_iterator</tt></a> + <span class="c1"><tt>it</tt></span> into <span class= + "c1"><tt>r_new_val</tt></span>.</p> + + <p>To use this method, <a href= + "#value_type279018186"><tt>value_type</tt></a> must be + assignable.</p> + </td> + </tr> + </table> + + <h3><a name="link14" id="link14">Erase Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + pop + () +</pre> + </td> + + <td> + <p>Pops the largest <a href= + "#value_type279018186"><tt>value_type</tt></a>.</p> + + <p>If the container object is empty, results are + undefined.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + erase + (<a href= +"#point_iterator2789896775"><tt>point_iterator</tt></a> it) +</pre> + </td> + + <td> + <p>Erases the <a href= + "#value_type279018186"><tt>value_type</tt></a> associated + with the <a href= + "#point_iterator2789896775"><tt>point_iterator</tt></a> + <span class="c1"><tt>it</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> Pred> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + erase_if + (Pred prd) +</pre> + </td> + + <td> + <p>Erases any <a href= + "#value_type279018186"><tt>value_type</tt></a> satisfying + the predicate <span class="c1"><tt>prd</tt></span>; + returns the number of <a href= + "#value_type279018186"><tt>value_type</tt></a>s + erased.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + clear + () +</pre> + </td> + + <td> + <p>Clears the container object.</p> + </td> + </tr> + </table> + + <h3><a name="link15" id="link15">Split and join + Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + join + (<span class="c2"><tt>priority_queue</tt></span> &other) +</pre> + </td> + + <td> + <p>Joins two container objects. When this function + returns, <span class="c1"><tt>other</tt></span> will be + empty.</p> + + <p>When calling this method, <span class= + "c1"><tt>other</tt></span>'s policies must be + equivalent to this object's policies.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> Pred> +<b>inline</b> <b>void</b> + split + (Pred prd, + <span class="c2"><tt>priority_queue</tt></span> &other) +</pre> + </td> + + <td> + <p>Splits into two container objects. When this function + returns, <span class="c1"><tt>other</tt></span> will be + contain only values v for which <span class= + "c1"><tt>prd</tt></span>(v) is <tt><b>true</b></tt>.</p> + + <p>When calling this method, <span class= + "c1"><tt>other</tt></span>'s policies must be + equivalent to this object's policies.</p> + </td> + </tr> + </table> + + <h3><a name="link16" id="link16">Iteration Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#iterator10418194"><tt>iterator</tt></a> + begin + () +</pre> + </td> + + <td> + <p>Returns an <a href= + "#iterator10418194"><tt>iterator</tt></a> corresponding + to the first <a href= + "#value_type279018186"><tt>value_type</tt></a> in the + container.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a> + begin + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> + corresponding to the first <a href= + "#value_type279018186"><tt>value_type</tt></a> in the + container.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#iterator10418194"><tt>iterator</tt></a> + end + () +</pre> + </td> + + <td> + <p>Returns an <a href= + "#iterator10418194"><tt>iterator</tt></a> corresponding + to the just-after-last <a href= + "#value_type279018186"><tt>value_type</tt></a> in the + container.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a> + end + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> + corresponding to the just-after-last <a href= + "#value_type279018186"><tt>value_type</tt></a> in the + container.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test.html new file mode 100644 index 000000000..903331d9d --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test.html @@ -0,0 +1,161 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Priority Queue Random Int Push Pop Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Priority Queue Random Integer <tt>push</tt> and + <tt>pop</tt> Timing Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with i.i.d. integer + keys into a container using <tt>push</tt> , then removes them + using <tt>pop</tt> . It measures the average time for + <tt>push</tt> and <tt>pop</tt> as a function of the number of + values.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_random_int_push_pop_timing.cc"> +<tt>priority_queue_random_int_push_pop_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures (see <a href="pq_design.html#pq_imp">Design::Priority + Queues::Implementations</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and + <a href="#NPL">NPL</a> shows the results for the native + priority queues and <tt>pb_ds</tt> 's priority queues in + <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, + <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NPG_res_div"> +<div id="NPG_gcc"> +<div id="NPG_priority_queue_random_int_push_pop_timing_test"> +<div id="NPG_pq"> +<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt___tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_random_int_push_pop_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>push</tt> <tt>pop</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPM_res_div"> +<div id="NPM_msvc"> +<div id="NPM_priority_queue_random_int_push_pop_timing_test"> +<div id="NPM_pq"> +<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt___tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_random_int_push_pop_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>push</tt> <tt>pop</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPL_res_div"> +<div id="NPL_local"> +<div id="NPL_priority_queue_random_int_push_pop_timing_test"> +<div id="NPL_pq"> +<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt___tt_pop_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_random_int_push_pop_timing_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>push</tt> <tt>pop</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>Binary heaps are the most suited for sequences of + <tt>push</tt> and <tt>pop</tt> operations of primitive types + (<i>e.g.</i> <tt><b>int</b></tt>s). This is explained in + <a href="priority_queue_random_int_push_timing_test.html">Priority + Queue Random Int <tt>push</tt> Timing Test</a> . (See <a href="priority_queue_text_push_pop_timing_test.html">Priority Queue + Text <tt>push</tt> Timing Test</a> for the case of primitive + types.)</p> +<p>At first glance it seems that the STL's vector-based + priority queue is approximately on par with <tt>pb_ds</tt>'s + corresponding priority queue. There are two differences + however:</p> +<ol> +<li>The STL's priority queue does not downsize the underlying + vector (or deque) as the priority queue becomes smaller + (see <a href="priority_queue_text_pop_mem_usage_test.html">Priority Queue + Text <tt>pop</tt> Memory Use Test</a>). It is therefore + gaining some speed at the expense of space.</li> +<li>From <a href="priority_queue_random_int_push_pop_timing_test.html">Priority + Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing + Test</a>, it seems that the STL's priority queue is slower in + terms of <tt>pus</tt> operations. Since the number of + <tt>pop</tt> operations is at most that of <tt>push</tt> + operations, the test here is the "best" for the STL's + priority queue.</li> +</ol> +<p><a href="pq_performance_tests.html#pq_observations">Priority-Queue + Performance Tests::Observations</a> discusses this further and + summarizes.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..68f5e2b6b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_local.png Binary files differnew file mode 100644 index 000000000..51f8211f1 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..4fc191c8b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test.html new file mode 100644 index 000000000..ba91f601a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test.html @@ -0,0 +1,200 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Priority Queue Random Int Push Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Priority Queue Random Integer <tt>push</tt> Timing + Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with i.i.d integer keys + into a container using <tt>push</tt> . It measures the average + time for <tt>push</tt> as a function of the number of + values.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_random_int_push_timing.cc"><tt> + priority_queue_random_intpush_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures (see <a href="pq_design.html#pq_imp">Design::Priority + Queues::Implementations</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and + <a href="#NPL">NPL</a> show the results for the native priority + queues and <tt>pb_ds</tt> 's priority queues in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NBPG">NBPG</a>, <a href="#NBPM">NBPM</a>, and <a href="#NBPL">NBPL</a> shows the + results for the binary-heap based native priority queues and + <tt>pb_ds</tt> 's priority queues in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively</p> +<div id="NPG_res_div"> +<div id="NPG_gcc"> +<div id="NPG_priority_queue_random_int_push_timing_test"> +<div id="NPG_pq"> +<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_random_int_push_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPM_res_div"> +<div id="NPM_msvc"> +<div id="NPM_priority_queue_random_int_push_timing_test"> +<div id="NPM_pq"> +<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_random_int_push_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPL_res_div"> +<div id="NPL_local"> +<div id="NPL_priority_queue_random_int_push_timing_test"> +<div id="NPL_pq"> +<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_random_int_push_timing_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NBPG_res_div"> +<div id="NBPG_gcc"> +<div id="NBPG_binary_priority_queue_random_int_push_timing_test"> +<div id="NBPG_pq"> +<div id="NBPG_Native_and__tt_pb_ds_455tt__binary_priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBPG" id="NBPG"><img src="binary_priority_queue_random_int_push_timing_test_gcc.png" alt="no image" /></a></h6>NBPG: Native and <tt>pb ds</tt> binary priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NBPM_res_div"> +<div id="NBPM_msvc"> +<div id="NBPM_binary_priority_queue_random_int_push_timing_test"> +<div id="NBPM_pq"> +<div id="NBPM_Native_and__tt_pb_ds_455tt__binary_priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBPM" id="NBPM"><img src="binary_priority_queue_random_int_push_timing_test_msvc.png" alt="no image" /></a></h6>NBPM: Native and <tt>pb ds</tt> binary priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NBPL_res_div"> +<div id="NBPL_local"> +<div id="NBPL_binary_priority_queue_random_int_push_timing_test"> +<div id="NBPL_pq"> +<div id="NBPL_Native_and__tt_pb_ds_455tt__binary_priority_queue__tt_push_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBPL" id= "NBPL"><img src="binary_priority_queue_random_int_push_timing_test_local.png" alt="no image" /></a></h6>NBPL: Native and <tt>pb ds</tt> binary priority queue <tt>push</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>Binary heaps are the most suited for sequences of + <tt>push</tt> and <tt>pop</tt> operations of primitive types + (<i>e.g.</i> <tt><b>int</b></tt>s). They are less constrained + than any other type, and since it is very efficient to store + such types in arrays, they outperform even pairing heaps. (See + <a href="priority_queue_text_push_timing_test.html">Priority + Queue Text <tt>push</tt> Timing Test</a> for the case of + non-primitive types.)</p> +<p><a href="pq_performance_tests.html#pq_observations">Priority-Queue + Performance Tests::Observations</a> discusses this further and + summarizes.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..ee8c9b7d9 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_local.png Binary files differnew file mode 100644 index 000000000..dead185fa --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..0a1a8eaef --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag.html new file mode 100644 index 000000000..8b6d81c37 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>priority_queue_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>priority_queue_tag</tt> Interface</h1> + + <p>Basic priority-queue data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="container_tag.html"><span class= +"c2"><tt>container_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.png Binary files differnew file mode 100644 index 000000000..ed8d875f0 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.svg b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.svg new file mode 100644 index 000000000..be007aecb --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.svg @@ -0,0 +1,368 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> +<svg + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://web.resource.org/cc/" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:xlink="http://www.w3.org/1999/xlink" + xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="11in" + height="8.5in" + id="svg2" + sodipodi:version="0.32" + inkscape:version="0.43" + version="1.0" + sodipodi:docbase="/mnt/share/src/policy_based_data_structures/pb_ds_images" + sodipodi:docname="pq_tag_diagram_2.svg" + inkscape:export-filename="/mnt/share/src/policy_based_data_structures/pb_ds_images/pq_tag_diagram_2.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90"> + <defs + id="defs4"> + <marker + inkscape:stockid="Arrow1Mstart" + orient="auto" + refY="0.0" + refX="0.0" + id="Arrow1Mstart" + style="overflow:visible"> + <path + id="path3311" + d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none" + transform="scale(0.4)" /> + </marker> + <marker + inkscape:stockid="Arrow2Sstart" + orient="auto" + refY="0" + refX="0" + id="Arrow2Sstart" + style="overflow:visible"> + <path + id="path3319" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(0.3,0,0,0.3,-1.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Sstart" + orient="auto" + refY="0" + refX="0" + id="Arrow1Sstart" + style="overflow:visible"> + <path + id="path3337" + d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none" + transform="scale(0.2,0.2)" /> + </marker> + <marker + inkscape:stockid="Arrow2Send" + orient="auto" + refY="0" + refX="0" + id="Arrow2Send" + style="overflow:visible"> + <path + id="path3316" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(-0.3,0,0,-0.3,1.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend" + style="overflow:visible"> + <path + id="path3322" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(-0.6,0,0,-0.6,3,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Lend" + style="overflow:visible"> + <path + id="path3346" + d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z " + style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none" + transform="scale(-0.8,-0.8)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lstart" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lstart" + style="overflow:visible"> + <path + id="path3331" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(1.1,0,0,1.1,-5.5,0)" /> + </marker> + <marker + inkscape:stockid="Arrow2Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lend" + style="overflow:visible"> + <path + id="path3328" + style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round" + d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z " + transform="matrix(-1.1,0,0,-1.1,5.5,0)" /> + </marker> + </defs> + <sodipodi:namedview + id="base" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="2" + inkscape:cx="608.69002" + inkscape:cy="490.05621" + inkscape:document-units="in" + inkscape:current-layer="layer1" + showguides="true" + inkscape:guide-bbox="true" + inkscape:window-width="1278" + inkscape:window-height="973" + inkscape:window-x="0" + inkscape:window-y="0" + gridtolerance="0.125in" + guidetolerance="0.125in"> + <sodipodi:guide + orientation="horizontal" + position="629" + id="guide1307" /> + <sodipodi:guide + orientation="horizontal" + position="449" + id="guide1309" /> + <sodipodi:guide + orientation="horizontal" + position="269" + id="guide1311" /> + <sodipodi:guide + orientation="vertical" + position="496" + id="guide1313" /> + <sodipodi:guide + orientation="vertical" + position="383" + id="guide1315" /> + <sodipodi:guide + orientation="vertical" + position="241" + id="guide1317" /> + <sodipodi:guide + orientation="vertical" + position="680" + id="guide1319" /> + <sodipodi:guide + orientation="vertical" + position="749" + id="guide1321" /> + <sodipodi:guide + orientation="vertical" + position="124" + id="guide1345" /> + <sodipodi:guide + orientation="vertical" + position="901" + id="guide1347" /> + <sodipodi:guide + orientation="horizontal" + position="539" + id="guide3390" /> + <sodipodi:guide + orientation="horizontal" + position="359" + id="guide3392" /> + <sodipodi:guide + orientation="vertical" + position="280.5" + id="guide3324" /> + <sodipodi:guide + orientation="vertical" + position="195" + id="guide3326" /> + <sodipodi:guide + orientation="vertical" + position="427" + id="guide3328" /> + <sodipodi:guide + orientation="vertical" + position="795" + id="guide3340" /> + <sodipodi:guide + orientation="horizontal" + position="179" + id="guide1395" /> + </sodipodi:namedview> + <metadata + id="metadata7"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:creator> + <cc:Agent> + <dc:title>Benjamin Kosnik</dc:title> + </cc:Agent> + </dc:creator> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1"> + <rect + y="382.17499" + x="241.73018" + height="23.200001" + width="141.64481" + id="rect3420" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3418" + width="141.64481" + height="23.200001" + x="52.730194" + y="382.17499" /> + <text + xml:space="preserve" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="122.35258" + y="395.91092" + id="text3394" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1383" + x="122.35258" + y="395.91092">pairing_heap_tag</tspan></text> + <text + sodipodi:linespacing="100%" + id="text3400" + y="395.91092" + x="310.55255" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1381" + x="310.55255" + y="395.91092">bionomial_heap_tag</tspan></text> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3380" + width="141.64481" + height="23.200001" + x="425.57764" + y="292.56177" /> + <text + xml:space="preserve" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="495.20001" + y="307.09772" + id="text1323" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1363" + x="495.20001" + y="307.09772">priority_queue_tag</tspan></text> + <path + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.16226137;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="M 124.54034,382.1132 L 124.54034,360.6132 L 311.75594,359.6132 L 311.75594,382.1132" + id="path2244" /> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect3422" + width="141.64481" + height="23.200001" + x="425.73022" + y="382.17499" /> + <text + sodipodi:linespacing="100%" + id="text3406" + y="395.91092" + x="495.3526" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1377" + x="495.3526" + y="395.91092">rc_binomial_heap_tag</tspan></text> + <rect + y="382.17499" + x="607.93024" + height="23.200001" + width="141.64481" + id="rect3424" + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <text + xml:space="preserve" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + x="679.15259" + y="395.91092" + id="text3412" + sodipodi:linespacing="100%"><tspan + sodipodi:role="line" + id="tspan1379" + x="679.15259" + y="395.91092">binary_heap_tag</tspan></text> + <path + id="path3347" + d="M 495.79886,382.13056 L 495.79886,321.40547" + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <rect + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + id="rect2281" + width="141.64481" + height="23.200001" + x="795.625" + y="382.17499" /> + <text + sodipodi:linespacing="100%" + id="text2283" + y="395.91092" + x="866.84735" + style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans" + xml:space="preserve"><tspan + sodipodi:role="line" + id="tspan1359" + x="866.84735" + y="395.91092">thin_heap_tag</tspan></text> + <path + style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="M 311.5,360 L 680,360" + id="path2309" /> + <use + x="0" + y="0" + xlink:href="#path2244" + id="use2311" + transform="matrix(-1,0,0,1,992.3371,0)" + width="990" + height="765" /> + </g> +</svg> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test.html new file mode 100644 index 000000000..a4bf576ff --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test.html @@ -0,0 +1,141 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Priority Queue Text Join Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Priority Queue Text <tt>join</tt> Timing Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into + two containers, then merges the containers. It uses + <tt>join</tt> for <tt>pb_ds</tt>'s priority queues; for the + STL's priority queues, it successively pops values from one + container and pushes them into the other. The test measures the + average time as a function of the number of values.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_join_timing.cc"><tt>priority_queue_text_join_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures (see <a href="pq_design.html#pq_imp">Design::Priority + Queues::Implementations</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and + <a href="#NPL">NPL</a> show the results for the native priority + queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc</u></a>, and <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NPG_res_div"> +<div id="NPG_gcc"> +<div id="NPG_priority_queue_text_join_timing_test"> +<div id="NPG_pq"> +<div id="NPG_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_join_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPM_res_div"> +<div id="NPM_msvc"> +<div id="NPM_priority_queue_text_join_timing_test"> +<div id="NPM_pq"> +<div id="NPM_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_join_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPL_res_div"> +<div id="NPL_local"> +<div id="NPL_priority_queue_text_join_timing_test"> +<div id="NPL_pq"> +<div id="NPL_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_join_timing_test_local.png" alt="no image" /></a></h6>NPL: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>In this test the node-based heaps perform <tt>join</tt> in + either logarithmic or constant time. The binary heap requires + linear time, since the well-known heapify algorithm [<a href="references.html#clrs2001">clrs2001</a>] is linear.</p> +<p>It would be possible to apply the heapify algorithm to the + STL containers, if they would support iteration (which they + don't). Barring iterators, it is still somehow possible to + perform linear-time merge on a <tt>std::vector</tt>-based STL + priority queue, using <tt>top()</tt> and <tt>size()</tt> (since + they are enough to expose the underlying array), but this is + impossible for a <tt>std::deque</tt>-based STL priority queue. + Without heapify, the cost is super-linear.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..a48bb3586 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_local.png Binary files differnew file mode 100644 index 000000000..1701b4d8a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..0575b99c0 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html new file mode 100644 index 000000000..7ece80bcf --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html @@ -0,0 +1,204 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Priority Queue Text Modify (Down) Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Priority Queue Text <tt>modify</tt> Timing Test - II</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into + into a container then modifies each one "down" (<i>i.e.,</i> it + makes it smaller). It uses <tt>modify</tt> for <tt>pb_ds</tt>'s + priority queues; for the STL's priority queues, it pops values + from a container until it reaches the value that should be + modified, then pushes values back in. It measures the average + time for <tt>modify</tt> as a function of the number of + values.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_modify_timing.cc"><tt>priority_queue_text_modify_down_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100 f)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The main purpose of this test is to contrast <a href="priority_queue_text_modify_up_timing_test.html">Priority Queue + Text <tt>modify</tt> Timing Test - I</a>.</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and + <a href="#NPL">NPL</a> show the results for the native priority + queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NRTG">NRTG</a>, <a href="#NRTM">NRTM</a>, and <a href="#NRTL">NRTL</a> show the results + for the pairing heap and thin heaps in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively,</p> +<div id="NPG_res_div"> +<div id="NPG_gcc"> +<div id="NPG_priority_queue_text_modify_down_timing_test"> +<div id="NPG_pq"> +<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_modify_down_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPM_res_div"> +<div id="NPM_msvc"> +<div id="NPM_priority_queue_text_modify_down_timing_test"> +<div id="NPM_pq"> +<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_modify_down_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPL_res_div"> +<div id="NPL_local"> +<div id="NPL_priority_queue_text_modify_down_timing_test"> +<div id="NPL_pq"> +<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_modify_down_timing_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NRTG_res_div"> +<div id="NRTG_gcc"> +<div id="NRTG_priority_queue_text_modify_down_timing_test_pairing_thin"> +<div id="NRTG_pq"> +<div id="NRTG_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTG" id="NRTG"><img src="priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png" alt="no image" /></a></h6>NRTG: Pairing and thin priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NRTM_res_div"> +<div id="NRTM_msvc"> +<div id="NRTM_priority_queue_text_modify_down_timing_test_pairing_thin"> +<div id="NRTM_pq"> +<div id="NRTM_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTM" id="NRTM"><img src="priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png" alt="no image" /></a></h6>NRTM: Pairing and thin priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NRTL_res_div"> +<div id="NRTL_local"> +<div id="NRTL_priority_queue_text_modify_down_timing_test_pairing_thin"> +<div id="NRTL_pq"> +<div id="NRTL_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTL" id= "NRTL"><img src="priority_queue_text_modify_down_timing_test_pairing_thin_local.png" alt="no image" /></a></h6>NRTL: Pairing and thin priority queue <tt>modify</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>Most points in these results are similar to <a href="priority_queue_text_modify_up_timing_test.html">Priority Queue + Text <tt>modify</tt> Timing Test - I</a>.</p> +<p>It is interesting to note, however, that as opposed to that + test, a thin heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with + <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>) is + outperformed by a pairing heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with + <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>). + In this case, both heaps essentially perform an <tt>erase</tt> + operation followed by a <tt>push</tt> operation. As the other + tests show, a pairing heap is usually far more efficient than a + thin heap, so this is not surprising.</p> +<p>Most algorithms that involve priority queues increase values + (in the sense of the priority queue's comparison functor), and + so <a href="priority_queue_text_modify_up_timing_test.html">Priority Queue + Text <tt>modify</tt> Timing Test - I</a> is more interesting + than this test.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..74cbc6523 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.png Binary files differnew file mode 100644 index 000000000..2fa9c7988 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..20b663736 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png Binary files differnew file mode 100644 index 000000000..ca901831e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.png Binary files differnew file mode 100644 index 000000000..977d16718 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png Binary files differnew file mode 100644 index 000000000..bf68bf992 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html new file mode 100644 index 000000000..72a1e0a75 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html @@ -0,0 +1,222 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Priority Queue Text Modify (Up) Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Priority Queue Text <tt>modify</tt> Timing Test - I</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into + into a container then modifies each one "up" (<i>i.e.,</i> it + makes it larger). It uses <tt>modify</tt> for <tt>pb_ds</tt>'s + priority queues; for the STL's priority queues, it pops values + from a container until it reaches the value that should be + modified, then pushes values back in. It measures the average + time for <tt>modify</tt> as a function of the number of + values.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_modify_timing.cc"><tt>priority_queue_text_modify_up_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100 t)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures (see <a href="pq_design.html#pq_imp">Design::Priority + Queues::Implementations</a>) for graph algorithms settings. + Note that making an arbitrary value larger (in the sense of the + priority queue's comparison functor) corresponds to + decrease-key in standard graph algorithms [<a href="references.html#clrs2001">clrs2001</a>].</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and + <a href="#NPL">NPL</a> show the results for the native priority + queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NRTG">NRTG</a>, <a href="#NRTM">NRTM</a>, and <a href="#NRTL">NRTL</a> show the results + for the pairing heap and thin heaps in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively,</p> +<div id="NPG_res_div"> +<div id="NPG_gcc"> +<div id="NPG_priority_queue_text_modify_up_timing_test"> +<div id="NPG_pq"> +<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_modify_up_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPM_res_div"> +<div id="NPM_msvc"> +<div id="NPM_priority_queue_text_modify_up_timing_test"> +<div id="NPM_pq"> +<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_modify_up_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPL_res_div"> +<div id="NPL_local"> +<div id="NPL_priority_queue_text_modify_up_timing_test"> +<div id="NPL_pq"> +<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_modify_up_timing_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NRTG_res_div"> +<div id="NRTG_gcc"> +<div id="NRTG_priority_queue_text_modify_up_timing_test_pairing_thin"> +<div id="NRTG_pq"> +<div id="NRTG_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTG" id="NRTG"><img src="priority_queue_text_modify_up_timing_test_pairing_thin_gcc.png" alt="no image" /></a></h6>NRTG: Pairing and thin priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NRTM_res_div"> +<div id="NRTM_msvc"> +<div id="NRTM_priority_queue_text_modify_up_timing_test_pairing_thin"> +<div id="NRTM_pq"> +<div id="NRTM_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTM" id="NRTM"><img src="priority_queue_text_modify_up_timing_test_pairing_thin_msvc.png" alt="no image" /></a></h6>NRTM: Pairing and thin priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NRTL_res_div"> +<div id="NRTL_local"> +<div id="NRTL_priority_queue_text_modify_up_timing_test_pairing_thin"> +<div id="NRTL_pq"> +<div id="NRTL_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTL" id= "NRTL"><img src="priority_queue_text_modify_up_timing_test_pairing_thin_local.png" alt="no image" /></a></h6>NRTL: Pairing and thin priority queue <tt>modify</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>As noted above, increasing an arbitrary value (in the sense + of the priority queue's comparison functor) is very common in + graph-related algorithms. In this case, a thin heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with + <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>) + outperforms a pairing heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with + <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>). + Conversely, <a href="priority_queue_text_push_timing_test.html">Priority Queue Text + <tt>push</tt> Timing Test</a>, <a href="priority_queue_text_push_pop_timing_test.html">Priority Queue + Text <tt>push</tt> and <tt>pop</tt> Timing Test</a>, <a href="priority_queue_random_int_push_timing_test.html">Priority + Queue Random Integer <tt>push</tt> Timing Test</a>, and + <a href="priority_queue_random_int_push_pop_timing_test.html">Priority + Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing + Test</a> show that the situation is reversed for other + operations. It is not clear when to prefer one of these two + different types.</p> +<p>In this test <tt>pb_ds</tt>'s binary heaps effectively + perform modify in linear time. As explained in <a href="pq_design.html#pq_traits">Priority Queue Design::Traits</a>, + given a valid point-type iterator, a binary heap can perform + <tt>modify</tt> logarithmically. The problem is that binary + heaps invalidate their find iterators with each modifying + operation, and so the only way to obtain a valid point-type + iterator is to iterate using a range-type iterator until + finding the appropriate value, then use the range-type iterator + for the <tt>modify</tt> operation.</p> +<p>The explanation for the STL's priority queues' performance + is similar to that in <a href="priority_queue_text_join_timing_test.html">Priority Queue Text + <tt>join</tt> Timing Test</a>.</p> +<p><a href="pq_performance_tests.html#pq_observations">Priority-Queue + Performance Tests::Observations</a> discusses this further and + summarizes.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..d9dedc20c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_local.png Binary files differnew file mode 100644 index 000000000..31575b452 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..4005547c8 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_gcc.png Binary files differnew file mode 100644 index 000000000..1aa5aba94 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_local.png Binary files differnew file mode 100644 index 000000000..b878dde66 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_msvc.png Binary files differnew file mode 100644 index 000000000..740594384 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test.html new file mode 100644 index 000000000..2545fc07d --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test.html @@ -0,0 +1,143 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Priority Queue Text Pop Memory Use Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Priority Queue Text <tt>pop</tt> Memory Use Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into + a container, then pops them until only one is left in the + container. It measures the memory use as a function of the + number of values pushed to the container.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_pop_mem_usage.cc"><tt>priority_queue_text_pop_mem_usage_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures (see <a href="pq_design.html#pq_imp">Design::Priority + Queues::Implementations</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and + <a href="#NPL">NPL</a> show the results for the native priority + queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NPG_res_div"> +<div id="NPG_gcc"> +<div id="NPG_priority_queue_text_pop_mem_usage_test"> +<div id="NPG_pq"> +<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_pop_455tt__memory-use_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_pop_mem_usage_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>pop</tt> memory-use test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPM_res_div"> +<div id="NPM_msvc"> +<div id="NPM_priority_queue_text_pop_mem_usage_test"> +<div id="NPM_pq"> +<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_pop_455tt__memory-use_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_pop_mem_usage_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>pop</tt> memory-use test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPL_res_div"> +<div id="NPL_local"> +<div id="NPL_priority_queue_text_pop_mem_usage_test"> +<div id="NPL_pq"> +<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_pop_455tt__memory-use_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_pop_mem_usage_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>pop</tt> memory-use test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>The priority queue implementations (excluding the STL's) use + memory proportionally to the number of values they hold: + node-based implementations (<i>e.g.</i>, a pairing heap) do so + naturally; <tt>pb_ds</tt>'s binary heap de-allocates memory when + a certain lower threshold is exceeded.</p> +<p>Note from <a href="priority_queue_text_push_pop_timing_test.html">Priority Queue + Text <tt>push</tt> and <tt>pop</tt> Timing Test</a> and + <a href="priority_queue_random_int_push_pop_timing_test.html">Priority + Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing + Test</a> that this does not impede performance compared to the + STL's priority queues.</p> +<p>(See <a href="hash_random_int_erase_mem_usage_test.html">Hash-Based Erase + Memory Use Test</a> for a similar phenomenon regarding priority + queues.)</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_gcc.png Binary files differnew file mode 100644 index 000000000..2c1918d06 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_local.png Binary files differnew file mode 100644 index 000000000..c1413fc93 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_msvc.png Binary files differnew file mode 100644 index 000000000..9717f498b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test.html new file mode 100644 index 000000000..3c143fe5a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test.html @@ -0,0 +1,209 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Priority Queue Text Push Pop Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Priority Queue Text <tt>push</tt> and <tt>pop</tt> Timing + Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into + a container using <tt>push</tt> , then removes them using + <tt>pop</tt> . It measures the average time for <tt>push</tt> + as a function of the number of values.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_push_pop_timing.cc"><tt> + priority_queue_text_push_pop_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures (see <a href="pq_design.html#pq_imp">Design::Priority + Queues::Implementations</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and + <a href="#NPL">NPL</a> show the results for the native priority + queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NBRG">NBRG</a>, <a href="#NBRM">NBRM</a>, and <a href="#NBRL">NBRL</a> show the results + for the native priority queues and <tt>pb_ds</tt>'s pairing + queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NPG_res_div"> +<div id="NPG_gcc"> +<div id="NPG_priority_queue_text_push_pop_timing_test"> +<div id="NPG_pq"> +<div id="NPG_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_push_pop_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPM_res_div"> +<div id="NPM_msvc"> +<div id="NPM_priority_queue_text_push_pop_timing_test"> +<div id="NPM_pq"> +<div id="NPM_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_push_pop_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPL_res_div"> +<div id="NPL_local"> +<div id="NPL_priority_queue_text_push_pop_timing_test"> +<div id="NPL_pq"> +<div id="NPL_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_push_pop_timing_test_local.png" alt="no image" /></a></h6>NPL: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NBRG_res_div"> +<div id="NBRG_gcc"> +<div id="NBRG_pairing_priority_queue_text_push_pop_timing_test"> +<div id="NBRG_pq"> +<div id="NBRG_Native_tree_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRG" id="NBRG"><img src="pairing_priority_queue_text_push_pop_timing_test_gcc.png" alt="no image" /></a></h6>NBRG: Native tree and <tt>pb ds</tt> pairing priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NBRM_res_div"> +<div id="NBRM_msvc"> +<div id="NBRM_pairing_priority_queue_text_push_pop_timing_test"> +<div id="NBRM_pq"> +<div id="NBRM_Native_tree_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRM" id="NBRM"><img src="pairing_priority_queue_text_push_pop_timing_test_msvc.png" alt="no image" /></a></h6>NBRM: Native tree and <tt>pb ds</tt> pairing priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NBRL_res_div"> +<div id="NBRL_local"> +<div id="NBRL_pairing_priority_queue_text_push_pop_timing_test"> +<div id="NBRL_pq"> +<div id="NBRL_Native_tree_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRL" id= "NBRL"><img src="pairing_priority_queue_text_push_pop_timing_test_local.png" alt="no image" /></a></h6>NBRL: Native tree and <tt>pb ds</tt> pairing priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>These results are very similar to <a href="priority_queue_text_push_timing_test.html">Priority Queue Text + <tt>push</tt> Timing Test</a>. As stated there, pairing heaps + (<a href="priority_queue.html"><tt>priority_queue</tt></a> with + <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>) + are most suited for <tt>push</tt> and <tt>pop</tt> sequences of + non-primitive types such as strings. Observing these two tests, + one can note that a pairing heap outperforms the others in + terms of <tt>push</tt> operations, but equals binary heaps + (<a href="priority_queue.html"><tt>priority_queue</tt></a> with + <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>) if + the number of <tt>push</tt> and <tt>pop</tt> operations is + equal. As the number of <tt>pop</tt> operations is at most + equal to the number of <tt>push</tt> operations, pairing heaps + are better in this case. See <a href="priority_queue_random_int_push_pop_timing_test.html">Priority + Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing + Test</a> for a case which is different.</p> +<p><a href="pq_performance_tests.html#pq_observations">Priority-Queue + Performance Tests::Observations</a> discusses this further and + summarizes.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..d4886ae59 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_local.png Binary files differnew file mode 100644 index 000000000..a7c5f8987 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..a5720402b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test.html new file mode 100644 index 000000000..542eb913c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test.html @@ -0,0 +1,219 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Priority Queue Text Push Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Priority Queue Text <tt>push</tt> Timing Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into + a container using <tt>push</tt> . It measures the average time + for <tt>push</tt> as a function of the number of values + pushed.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_push_timing.cc"><tt>priority_queue_text_push_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures (see <a href="pq_design.html#pq_imp">Design::Priority + Queues::Implementations</a>).</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and + <a href="#NPL">NPL</a> show the results for the native priority + queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively; Figures <a href="#NBRG">NBRG</a>, <a href="#NBRM">NBRM</a>, and <a href="#NBRL">NBRL</a> shows the + results for the binary-heap based native priority queues and + <tt>pb_ds</tt>'s pairing-heap priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="pq_performance_tests.html#local"><u>local</u></a>, + respectively</p> +<div id="NPG_res_div"> +<div id="NPG_gcc"> +<div id="NPG_priority_queue_text_push_timing_test"> +<div id="NPG_pq"> +<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_push_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPM_res_div"> +<div id="NPM_msvc"> +<div id="NPM_priority_queue_text_push_timing_test"> +<div id="NPM_pq"> +<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_push_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +rc_binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a> +</li> +<li> +binary_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a> +</li> +<li> +binomial_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a> +</li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPL_res_div"> +<div id="NPL_local"> +<div id="NPL_priority_queue_text_push_timing_test"> +<div id="NPL_pq"> +<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_push_timing_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NBRG_res_div"> +<div id="NBRG_gcc"> +<div id="NBRG_pairing_priority_queue_text_push_timing_test"> +<div id="NBRG_pq"> +<div id="NBRG_Native_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRG" id="NBRG"><img src="pairing_priority_queue_text_push_timing_test_gcc.png" alt="no image" /></a></h6>NBRG: Native and <tt>pb ds</tt> pairing priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NBRM_res_div"> +<div id="NBRM_msvc"> +<div id="NBRM_pairing_priority_queue_text_push_timing_test"> +<div id="NBRM_pq"> +<div id="NBRM_Native_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRM" id="NBRM"><img src="pairing_priority_queue_text_push_timing_test_msvc.png" alt="no image" /></a></h6>NBRM: Native and <tt>pb ds</tt> pairing priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_pq_deque- +<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li> +<li> +n_pq_vector- +<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li> +<li> +pairing_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> +</li> +<li> +thin_heap- +<a href="priority_queue.html"><tt>priority_queue</tt></a> + with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NBRL_res_div"> +<div id="NBRL_local"> +<div id="NBRL_pairing_priority_queue_text_push_timing_test"> +<div id="NBRL_pq"> +<div id="NBRL_Native_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRL" id= "NBRL"><img src="pairing_priority_queue_text_push_timing_test_local.png" alt="no image" /></a></h6>NBRL: Native and <tt>pb ds</tt> pairing priority queue <tt>push</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>Pairing heaps (<a href="priority_queue.html"><tt>priority_queue</tt></a> with + <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>) + are the most suited for sequences of <tt>push</tt> and + <tt>pop</tt> operations of non-primitive types (<i>e.g.</i> +<tt>std::string</tt>s). (see also <a href="priority_queue_text_push_pop_timing_test.html">Priority Queue + Text <tt>push</tt> and <tt>pop</tt> Timing Test</a>.) They are + less constrained than binomial heaps, <i>e.g.</i>, and since + they are node-based, they outperform binary heaps. (See + <a href="priority_queue_random_int_push_timing_test.html">Priority + Queue Random Integer <tt>push</tt> Timing Test</a> for the case + of primitive types.)</p> +<p>The STL's priority queues do not seem to perform well in + this case: the <tt>std::vector</tt> implementation needs to + perform a logarithmic sequence of string operations for each + operation, and the deque implementation is possibly hampered by + its need to manipulate a relatively-complex type (deques + support a <i>O(1)</i> <tt>push_front</tt>, even though it is + not used by <tt>std::priority_queue</tt>.)</p> +<p><a href="pq_performance_tests.html#pq_observations">Priority-Queue + Performance Tests::Observations</a> discusses this further and + summarizes.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..8895f507c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_local.png Binary files differnew file mode 100644 index 000000000..da7297bff --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..ff39ca37d --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/quadratic_probe_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/quadratic_probe_fn.html new file mode 100644 index 000000000..00367dac8 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/quadratic_probe_fn.html @@ -0,0 +1,141 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>quadratic_probe_fn Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>quadratic_probe_fn</tt> Interface</h1> + + <p>A probe sequence policy using square increments.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Size_Type42920436" id= +"Size_Type42920436"><b>typename</b> Size_Type </a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + + <td>size_t</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#Size_Type42920436"><tt>Size_Type</tt></a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link4" id="link4">Public Methods</a></h2> + + <h3><a name="link5" id="link5">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class= +"c2"><tt>quadratic_probe_fn</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h2><a name="link6" id="link6">Protected Methods</a></h2> + + <h3><a name="link7" id="link7">Offset Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + <b>operator</b>() + (<a href= +"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b> +</pre> + </td> + + <td> + <p>Returns the <span class="c1"><tt>i</tt></span>-th + offset from the hash value.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.png Binary files differnew file mode 100644 index 000000000..61962704f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.png Binary files differnew file mode 100644 index 000000000..83105202a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.png Binary files differnew file mode 100644 index 000000000..2206cef5a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/range_invalidation_guarantee.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/range_invalidation_guarantee.html new file mode 100644 index 000000000..7bfba19e8 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/range_invalidation_guarantee.html @@ -0,0 +1,52 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>range_invalidation_guarantee Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>range_invalidation_guarantee</tt> Interface</h1> + + <p>Signifies an invalidation guarantee that includes all those + of its base, and additionally, that any range-type iterator + (including the returns of begin() and end()) is in the correct + relative positions to other range-type iterators as long as its + corresponding entry has not be erased, regardless of + modifications to the container object.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="point_invalidation_guarantee.html"><span class= +"c2"><tt>point_invalidation_guarantee</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rationale_null_node_updator.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rationale_null_node_updator.png Binary files differnew file mode 100644 index 000000000..438748915 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rationale_null_node_updator.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rb_tree_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rb_tree_tag.html new file mode 100644 index 000000000..2adbd09bf --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rb_tree_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>rb_tree_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>rb_tree_tag</tt> Interface</h1> + + <p>Red-black tree data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="tree_tag.html"><span class= +"c2"><tt>tree_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rc_binomial_heap_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rc_binomial_heap_tag.html new file mode 100644 index 000000000..1a4ba9f2e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rc_binomial_heap_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>rc_binomial_heap_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>rc_binomial_heap_tag</tt> Interface</h1> + + <p>Redundant-counter binomial-heap data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="priority_queue_tag.html"><span class= +"c2"><tt>priority_queue_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/references.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/references.html new file mode 100644 index 000000000..b96827bd3 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/references.html @@ -0,0 +1,258 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>References</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>References</h1> + + <ol> + <li>[<a name="abrahams97exception" id= + "abrahams97exception">abrahams97exception</a>] Dave Abrahams, + STL Exception Handling Contract, <a href= + "http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1075.pdf"> + http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1075.pdf</a></li> + + <li>[<a name="alexandrescu01modern" id= + "alexandrescu01modern">alexandrescu01modern</a>] Andrei + Alexandrescu, <i>Modern C++ Design: Generic Programming and + Design Patterns Applied</i>, Addison-Wesley Publishing + Company, 2001</li> + + <li>[<a name="andrew04mtf" id="andrew04mtf">andrew04mtf</a>] + K. Andrew and D. Gleich, "MTF, Bit, and COMB: A Guide to + Deterministic and Randomized Algorithms for the List Update + Problem"</li> + + <li>[<a name="austern00noset" id= + "austern00noset">austern00noset</a>] Matthew Austern, "Why + You shouldn't use <tt>set</tt> - and What You Should Use + Instead", C++ Report, April, 2000</li> + + <li>[<a name="austern01htprop" id= + "austern01htprop">austern01htprop</a>] Matthew Austern, "A + Proposal to Add Hashtables to the Standard Library", <a href= + "http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1326l.html"> + http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1326l.html</a></li> + + <li>[<a name="austern98segmented" id= + "austern98segmented">austern98segmented</a>] Matthew Austern, + "Segmented iterators and hierarchical algorithms", Generic + Programming, April 1998, pp. 80-90</li> + + <li>[<a name="boost_timer" id="boost_timer">boost_timer</a>], + "Boost timer library", <a href= + "http://www.boost.org/">http://www.boost.org</a> by Beman + Dawes</li> + + <li>[<a name="boost_pool" id="boost_pool">boost_pool</a>], + "Boost pool library", <a href= + "http://www.boost.org/">http://www.boost.org</a> by Stephen + Cleary</li> + + <li>[<a name="boost_type_traits" id= + "boost_type_traits">boost_type_traits</a>], "Boost + <tt>type_traits</tt> library", <a href= + "http://www.boost.org/">http://www.boost.org</a> by John + Maddock, Steve Cleary, <i>et. al.</i></li> + + <li>[<a name="brodal96priority" id= + "brodal96priority">brodal96priority</a>] Gerth Stolting + Brodal, <a href= + "http://portal.acm.org/citation.cfm?id=313883">Worst-case + efficient priority queues</a></li> + + <li>[<a name="bulka99efficient" id= + "bulka99efficient">bulka99efficient</a>] D. Bulka, and D. + Mayhew, "Efficient C++ Programming Techniques.", + Addison-Wesley Publishing Company, Addison-Wesley, 1997</li> + + <li>[<a name="clrs2001" id="clrs2001">clrs2001</a>] T. H. + Cormen, C. E., Leiserson, R. L. Rivest, C. and Stein, + "Introduction to Algorithms, 2nd ed.", MIT Press, 2001</li> + + <li>[<a name="dinkumware_stl" id= + "dinkumware_stl">dinkumware_stl</a>], "Dinkumware C++ Library + Reference", <a href= + "http://www.dinkumware.com/htm_cpl/index.html">http://www.dinkumware.com/htm_cpl/index.html</a></li> + + <li>[<a name="dubhashi98neg" id= + "dubhashi98neg">dubhashi98neg</a>] D. Dubashi, and D. Ranjan, + "Balls and bins: A study in negative dependence.", Random + Structures and Algorithms 13, 2 (1998), 99-124</li> + + <li>[<a name="fagin79extendible" id= + "fagin79extendible">fagin79extendible</a>] R. Fagin, J. + Nievergelt, N. Pippenger, and H. R. Strong, "Extendible + hashing - a fast access method for dynamic files", ACM Trans. + Database Syst. 4, 3 (1979), 315-344</li> + + <li>[<a name="filliatre2000ptset" id= + "filliatre2000ptset">filliatre2000ptset</a>], J. C. + Filliatre, "Ptset: Sets of integers implemented as Patricia + trees", <a href= + "http://www.lri.fr/~filliatr/ftp/ocaml/misc/ptset.ml">http://www.lri.fr/~filliatr/ftp/ocaml/misc/ptset.ml</a></li> + + <li>[<a name="fredman86pairing" id= + "fredman86pairing">fredman86pairing</a>], M. L. Fredman, R + Sedgewick, D. D. Sleator, R. E. Tarjan, <a href= + "http://www.cs.cmu.edu/~sleator/papers/pairing-heaps.pdf">The + pairing heap: a new form of self-adjusting heap</a></li> + + <li>[<a name="gamma95designpatterns" id= + "gamma95designpatterns">gamma95designpatterns</a>] E. Gamma, + R. Helm, R. Johnson, and J. Vlissides, "Design Patterns - + Elements of Reusable Object-Oriented Software", + Addison-Wesley Publishing Company, Addison-Wesley, 1995</li> + + <li>[<a name="garg86order" id="garg86order">garg86order</a>] + A. K. Garg and C. C. Gotlieb, "Order-preserving key + transformations", Trans. Database Syst. 11, 2 (1986), + 213-234</li> + + <li>[<a name="hyslop02making" id= + "hyslop02making">hyslop02making</a>] J. Hyslop, and H. + Sutter, "Making a real hash of things", C++ Report, May + 2002</li> + + <li>[<a name="jossutis01stl" id= + "jossutis01stl">jossutis01stl</a>] N. M. Jossutis, "The C++ + Standard Library - A Tutorial and Reference", Addison-Wesley + Publishing Company, Addison-Wesley, 2001</li> + + <li>[<a name="kt99fat_heaps" id= + "kt99fat_heaps">kt99fat_heas</a>] Haim Kaplan and Robert E. + Tarjan, <a href= + "http://www.cs.princeton.edu/research/techreps/TR-597-99">New + Heap Data Structures</a></li> + + <li>[<a name="kleft00sets" id="kleft00sets">kleft00sets</a>] + Klaus Kleft and Angelika Langer, "Are Set Iterators Mutable + or Immutable?", C/C++ Users Jornal, October 2000</li> + + <li>[<a name="knuth98sorting" id= + "knuth98sorting">knuth98sorting</a>] D. E. Knuth, "The Art of + Computer Programming - Sorting and Searching", Addison-Wesley + Publishing Company, Addison-Wesley, 1998</li> + + <li>[<a name="liskov98data" id= + "liskov98data">liskov98data</a>] B. Liskov, "Data abstraction + and hierarchy", SIGPLAN Notices 23, 5 (May 1998)</li> + + <li>[<a name="litwin80lh" id="litwin80lh">litwin80lh</a>] W. + Litwin, "Linear hashing: A new tool for file and table + addressing", Proceedings of International Conference on Very + Large Data Bases (June 1980), pp. 212-223</li> + + <li>[<a name="maverik_lowerbounds" id= + "maverik_lowerbounds">maverik_lowerbounds</a>] Maverik Woo, + <a href= + "http://magic.aladdin.cs.cmu.edu/2005/08/01/deamortization-part-2-binomial-heaps/"> + Deamortization - Part 2: Binomial Heaps</a></li> + + <li>[<a name="metrowerks_stl" id= + "metrowerks_stl">metrowerks_stl</a>], "Metrowerks CodeWarrior + Pro 7 MSL C++ Reference Manual",</li> + + <li>[<a name="meyers96more" id= + "meyers96more">meyers96more</a>] S. Meyers, "More Effective + C++: 35 New Ways to Improve Your Programs and Designs - 2nd + ed.", Addison-Wesley Publishing Company, Addison-Wesley, + 1996</li> + + <li>[<a name="meyers00nonmember" id= + "meyers00nonmember">meyers00nonmember</a>] S. Meyers, "How + Non-Member Functions Improve Encapsulation", C/C++ Users + Journal, 2000</li> + + <li>[<a name="meyers01stl" id="meyers01stl">meyers01stl</a>] + S. Meyers, "Effective STL: 50 Specific Ways to Improve Your + Use of the Standard Template Library", Addison-Wesley + Publishing Company, Addison-Wesley, 2001</li> + + <li>[<a name="meyers02both" id= + "meyers02both">meyers02both</a>] S. Meyers, "Class Template, + Member Template - or Both?", C/C++ Users Journal, 2003</li> + + <li>[<a name="motwani95random" id= + "motwani95random">motwani95random</a>] R. Motwani, and P. + Raghavan, "Randomized Algorithms", Cambridge University + Press</li> + + <li>[<a name="mscom" id="mscom">mscom</a>] <a href= + "http://www.microsoft.com/com">COM: Component Model Object + Technologies</a></li> + + <li>[<a name="musser95rationale" id= + "musser95rationale">musser95rationale</a>], David R. Musser, + "Rationale for Adding Hash Tables to the C++ Standard + Template Library"</li> + + <li>[<a name="musser96stltutorial" id= + "musser96stltutorial">musser96stltutorial</a>] D. R. Musser + and A. Saini, "STL Tutorial and Reference Guide", + Addison-Wesley Publishing Company, Addison-Wesley, 1996</li> + + <li>[<a name="nelson96stlpq" id= + "nelson96stlpq">nelson96stlpql</a>] Mark Nelson, <a href= + "http://www.dogma.net/markn/articles/pq_stl/priority.htm">Priority + Queues and the STL</a>, Dr. Dobbs Journal, January, 1996</li> + + <li>[<a name="okasaki98mereable" id= + "okasaki98mereable">okasaki98mereable</a>] C. Okasaki and A. + Gill, "Fast mergeable integer maps", In Workshop on ML, pages + 77--86, September 1998. 95</li> + + <li>[<a name="sgi_stl" id="sgi_stl">sgi_stl</a>] SGI, + "Standard Template Library Programmer's Guide", <a href= + "http://www.sgi.com/tech/stl">http://www.sgi.com/tech/stl</a></li> + + <li>[<a name="select_man" id="select_man">select_man</a>] + <a href= + "http://www.scit.wlv.ac.uk/cgi-bin/mansec?3C+select"><tt>select</tt> + man page.</a></li> + + <li>[<a name="sleator84amortized" id= + "sleator84amortized">sleator84amortized</a>] D. D. Sleator + and R. E. Tarjan, "Amortized Efficiency of List Update + Problems", ACM Symposium on Theory of Computing, 1984</li> + + <li>[<a name="sleator85self" id= + "sleator85self">sleator85self</a>] D. D. Sleator and R. E. + Tarjan, "Self-Adjusting Binary Search Trees", ACM Symposium + on Theory of Computing, 1985</li> + + <li>[<a name="stepanov94standard" id= + "stepanov94standard">stepanov94standard</a>] A. A. Stepanov + and M. Lee", "The Standard Template Library"</li> + + <li>[<a name="stroustrup97cpp" id= + "stroustrup97cpp">stroustrup97cpp</a>] Bjarne Stroustrup, + <i>The C++ Programming Langugage -3rd ed.</i>, Addison-Wesley + Publishing Company,Reading, MA, USA, 1997</li> + + <li>[<a name="vandevoorde2002cpptemplates" id= + "vandevoorde2002cpptemplates">vandevoorde2002cpptemplates</a>] + D. Vandevoorde, and N. M. Josuttis, "C++ Templates: The + Complete Guide", Addison-Wesley Publishing Company, + Addison-Wesley, 2002</li> + + <li>[<a name="wickland96thirty" id= + "wickland96thirty">wickland96thirty</a>] C. A. Wickland, + "Thirty Years Among the Dead", National Psychological + Institute, Los Angeles, 1996,<a href= + "http://myweb.wvnet.edu/~gsa00121/books/amongdead30.zip">http://myweb.wvnet.edu/gsa00121/books/amongdead30.zip</a></li> + </ol> + <hr /> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_error.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_error.html new file mode 100644 index 000000000..6aab88c15 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_error.html @@ -0,0 +1,50 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + +<title>resize_error Interface</title> +<meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> +</head> + +<body> +<div id="page"> +<h1><tt>resize_error</tt> Interface</h1> + +<p>A container cannot be resized.</p> + +<p>Exception thrown when a size policy cannot supply an + adequate size for an external resize.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/exception.hpp"><tt>exception.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> + <a href="exceptions.html"><span class= + "c2"><tt>resize_error</tt></span></a> + </pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> + </body> + </html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_policy_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_policy_cd.png Binary files differnew file mode 100644 index 000000000..338e33c15 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_policy_cd.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/restoring_node_invariants.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/restoring_node_invariants.png Binary files differnew file mode 100644 index 000000000..33ba84bfe --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/restoring_node_invariants.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_probe_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_probe_fn.html new file mode 100644 index 000000000..51dccce5c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_probe_fn.html @@ -0,0 +1,152 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_probe_fn Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_probe_fn</tt> Interface</h1> + + <p>A sample probe policy.</p> + + <p>This class serves to show the interface a probe functor + needs to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/hash_fn/sample_probe_fn.hpp"><tt>sample_probe_fn.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">General definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +size_t, e.g. +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Methods</a></h2> + + <h3><a name="link4" id="link4">Constructors, destructor, and + related.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + sample_probe_fn + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + + <p>Must be default constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> + sample_probe_fn + (<b>const</b> sample_probe_fn &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + + <p>Must be copy constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + swap + (sample_probe_fn &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + + <p>Must be swappable (if there is such a word).</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Protected Methods</a></h2> + + <h3><a name="link6" id="link6">Offset methods.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + <b>operator</b>() + (const_key_reference r_key, + <a href= +"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b> +</pre> + </td> + + <td> + <p>Returns the <span class="c1"><tt>i</tt></span>-th + offset from the hash value of some key <span class= + "c1"><tt>r_key</tt></span>.</p> + + <p><tt>size_type</tt> is the size type on which the + functor operates.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_range_hashing.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_range_hashing.html new file mode 100644 index 000000000..85051873c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_range_hashing.html @@ -0,0 +1,172 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_range_hashing Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_range_hashing</tt> Interface</h1> + + <p>A sample range-hashing functor.</p> + + <p>This class serves to show the interface a range-hashing + functor needs to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/hash_fn/sample_range_hashing.hpp"><tt>sample_range_hashing.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">General definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +size_t, e.g. +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Methods</a></h2> + + <h3><a name="link4" id="link4">Constructors, destructor, and + related.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + sample_range_hashing + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + + <p>Must be default constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> + sample_range_hashing + (<b>const</b> sample_range_hashing &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + + <p>Must be copy constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + swap + (sample_range_hashing &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + + <p>Must be swappable (if there is such a word).</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Protected Methods</a></h2> + + <h3><a name="link6" id="link6">Notification methods.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> size) +</pre> + </td> + + <td> + <p>Notifies the policy object that the container's size + has changed to <span class="c1"><tt>size</tt></span>.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Operators.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + <b>operator</b>() + (<a href= +"#size_type55424436"><tt>size_type</tt></a> hash) <b>const</b> +</pre> + </td> + + <td> + <p>Transforms the hash value <span class= + "c1"><tt>hash</tt></span> into a ranged-hash value.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_hash_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_hash_fn.html new file mode 100644 index 000000000..834f49650 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_hash_fn.html @@ -0,0 +1,171 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_ranged_hash_fn Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_ranged_hash_fn</tt> Interface</h1> + + <p>A sample ranged-hash functor.</p> + + <p>This class serves to show the interface a ranged-hash + functor needs to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/hash_fn/sample_ranged_hash_fn.hpp"><tt>sample_ranged_hash_fn.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">General definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +size_t, e.g. +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Methods</a></h2> + + <h3><a name="link4" id="link4">Constructors, destructor, and + related.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + sample_ranged_hash_fn + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + + <p>Must be default constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> + sample_ranged_hash_fn + (<b>const</b> sample_ranged_hash_fn &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + + <p>Must be copy constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + swap + (sample_ranged_hash_fn &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + + <p>Must be swappable (if there is such a word).</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Protected Methods</a></h2> + + <h3><a name="link6" id="link6">Notification methods.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> size) +</pre> + </td> + + <td> + <p>Notifies the policy object that the container's size + has changed to <span class="c1"><tt>size</tt></span>.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Operators.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + <b>operator</b>() + (const_key_reference r_key) <b>const</b> +</pre> + </td> + + <td> + <p>Transforms <span class="c1"><tt>r_key</tt></span> into + a position within the table.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_probe_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_probe_fn.html new file mode 100644 index 000000000..ee1bc0664 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_probe_fn.html @@ -0,0 +1,178 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_ranged_probe_fn Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_ranged_probe_fn</tt> Interface</h1> + + <p>A sample ranged-probe functor.</p> + + <p>This class serves to show the interface a ranged-probe + functor needs to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/hash_fn/sample_ranged_probe_fn.hpp"><tt>sample_ranged_probe_fn.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">General definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +size_t, e.g. +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Methods</a></h2> + + <h3><a name="link4" id="link4">Constructors, destructor, and + related.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + sample_ranged_probe_fn + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + + <p>Must be default constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> + sample_ranged_probe_fn + (<b>const</b> sample_ranged_probe_fn &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + + <p>Must be copy constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + swap + (sample_ranged_probe_fn &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + + <p>Must be swappable (if there is such a word).</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Protected Methods</a></h2> + + <h3><a name="link6" id="link6">Notification methods.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> size) +</pre> + </td> + + <td> + <p>Notifies the policy object that the container's size + has changed to <span class="c1"><tt>size</tt></span>.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Operators.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + <b>operator</b>() + (const_key_reference r_key, + size_t hash, + <a href= +"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b> +</pre> + </td> + + <td> + <p>Transforms the <tt><b>const</b></tt> key reference + <span class="c1"><tt>r_key</tt></span> <span class= + "c1"><tt>into the </tt></span><span class= + "c1"><tt>i-th </tt></span>position within the table. This + method <span class="c1"><tt>i</tt></span>s called for + each collision within the probe sequence.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_policy.html new file mode 100644 index 000000000..61ff09ba0 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_policy.html @@ -0,0 +1,413 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_resize_policy Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_resize_policy</tt> Interface</h1> + + <p>A sample resize policy.</p> + + <p>This class serves to show the interface a resize policy + needs to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/resize_policy/sample_resize_policy.hpp"><tt>sample_resize_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">General definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +size_t, e.g. +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Methods</a></h2> + + <h3><a name="link4" id="link4">Constructors, destructor, and + related.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + sample_resize_policy + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + + <p>Must be default constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> + sample_range_hashing + (<b>const</b> sample_resize_policy &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + + <p>Must be copy constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + swap + (sample_resize_policy &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + + <p>Must be swappable (if there is such a word).</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Protected Methods</a></h2> + + <h3><a name="link6" id="link6">Insert search + notifications.</a></h3> + + <p>Notifications called during an insert operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Find search + notifications.</a></h3> + + <p>Notifications called during a find operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link8" id="link8">Erase search + notifications.</a></h3> + + <p>Notifications called during an insert operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link9" id="link9">Content change + notifications.</a></h3> + + <p>Notifications called when the content of the table changes + in a way that can affect the resize policy.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_inserted + (<a href="#size_type55424436"><tt>size_type</tt></a> num_e) +</pre> + </td> + + <td> + <p>Notifies an element was inserted.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erased + (<a href="#size_type55424436"><tt>size_type</tt></a> num_e) +</pre> + </td> + + <td> + <p>Notifies an element was erased.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_cleared + () +</pre> + </td> + + <td> + <p>Notifies the table was cleared.</p> + </td> + </tr> + </table> + + <h3><a name="link10" id="link10">Size change + notifications.</a></h3> + + <p>Notifications called when the table changes size.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Notifies the table was resized to <span class= + "c1"><tt>new_size</tt></span>.</p> + </td> + </tr> + </table> + + <h3><a name="link11" id="link11">Queries.</a></h3> + + <p>Called to query whether/how to resize.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + is_resize_needed + () <b>const</b> +</pre> + </td> + + <td> + <p>Queries whether a resize is needed.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#size_type55424436"><tt>size_type</tt></a> + get_new_size + (<a href="#size_type55424436"><tt>size_type</tt></a> size, + <a href= +"#size_type55424436"><tt>size_type</tt></a> num_used_e) <b>const</b> +</pre> + </td> + + <td> + <p>Queries what the new <span class= + "c1"><tt>size</tt></span> should be.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_trigger.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_trigger.html new file mode 100644 index 000000000..5c8173c8e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_trigger.html @@ -0,0 +1,462 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_resize_trigger Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_resize_trigger</tt> Interface</h1> + + <p>A sample resize trigger policy.</p> + + <p>This class serves to show the interface a trigger policy + needs to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/resize_policy/sample_resize_trigger.hpp"><tt> + sample_resize_trigger.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">General definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +size_t, e.g. +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Methods</a></h2> + + <h3><a name="link4" id="link4">Constructors, destructor, and + related.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + sample_resize_trigger + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + + <p>Must be default constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> + sample_range_hashing + (<b>const</b> sample_resize_trigger &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + + <p>Must be copy constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + swap + (sample_resize_trigger &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + + <p>Must be swappable (if there is such a word).</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Protected Methods</a></h2> + + <h3><a name="link6" id="link6">Insert search + notifications.</a></h3> + + <p>Notifications called during an insert operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_insert_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Find search + notifications.</a></h3> + + <p>Notifications called during a find operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_find_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link8" id="link8">Erase search + notifications.</a></h3> + + <p>Notifications called during an insert operation.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_start + () +</pre> + </td> + + <td> + <p>Notifies a search started.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_collision + () +</pre> + </td> + + <td> + <p>Notifies a search encountered a collision.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erase_search_end + () +</pre> + </td> + + <td> + <p>Notifies a search ended.</p> + </td> + </tr> + </table> + + <h3><a name="link9" id="link9">Content change + notifications.</a></h3> + + <p>Notifications called when the content of the table changes + in a way that can affect the resize policy.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_inserted + (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries) +</pre> + </td> + + <td> + <p>Notifies an element was inserted. the total number of + entries in the table is <span class= + "c1"><tt>num_entries</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + notify_erased + (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries) +</pre> + </td> + + <td> + <p>Notifies an element was erased.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_cleared + () +</pre> + </td> + + <td> + <p>Notifies the table was cleared.</p> + </td> + </tr> + </table> + + <h3><a name="link10" id="link10">Size change + notifications.</a></h3> + + <p>Notifications called when the table changes size.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Notifies the table was resized as a result of this + object's signifying that a resize is needed.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + notify_externally_resized + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Notifies the table was resized externally.</p> + </td> + </tr> + </table> + + <h3><a name="link11" id="link11">Queries.</a></h3> + + <p>Called to query whether/how to resize.</p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + is_resize_needed + () <b>const</b> +</pre> + </td> + + <td> + <p>Queries whether a resize is needed.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + is_grow_needed + (<a href="#size_type55424436"><tt>size_type</tt></a> size, + <a href= +"#size_type55424436"><tt>size_type</tt></a> num_entries) <b>const</b> +</pre> + </td> + + <td> + <p>Queries whether a grow is needed.</p> + + <p>This method is called only if this object indicated + resize is needed. The actual <span class= + "c1"><tt>size</tt></span> of the table is <span class= + "c1"><tt>size</tt></span>, and the number of entries in + it is <span class="c1"><tt>num_entries</tt></span>.</p> + </td> + </tr> + </table> + + <h2><a name="link12" id="link12">Private Methods</a></h2> + + <h3><a name="link13" id="link13">Overrides.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <b>void</b> + do_resize + (<a href="#size_type55424436"><tt>size_type</tt></a> new_size) +</pre> + </td> + + <td> + <p>Resizes to <span class= + "c1"><tt>new_size</tt></span>.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_size_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_size_policy.html new file mode 100644 index 000000000..ebb14d30b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_size_policy.html @@ -0,0 +1,163 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_size_policy Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_size_policy</tt> Interface</h1> + + <p>A sample size policy.</p> + + <p>This class serves to show the interface a size policy needs + to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/resize_policy/sample_size_policy.hpp"><tt>sample_size_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">General definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +size_t, e.g. +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Methods</a></h2> + + <h3><a name="link4" id="link4">Constructors, destructor, and + related.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + sample_size_policy + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + + <p>Must be default constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> + sample_range_hashing + (<b>const</b> sample_size_policy &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + + <p>Must be copy constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + swap + (sample_size_policy &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + + <p>Must be swappable (if there is such a word).</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Protected Methods</a></h2> + + <h3><a name="link6" id="link6">Size methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + get_nearest_larger_size + (<a href= +"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b> +</pre> + </td> + + <td> + <p>Given a size <span class="c1"><tt>size</tt></span>, + returns a size that is larger.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + get_nearest_smaller_size + (<a href= +"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b> +</pre> + </td> + + <td> + <p>Given a size <span class="c1"><tt>size</tt></span>, + returns a size that is smaller.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_tree_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_tree_node_update.html new file mode 100644 index 000000000..aefd67056 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_tree_node_update.html @@ -0,0 +1,193 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_tree_node_update Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_tree_node_update</tt> Interface</h1> + + <p>A sample node updater.</p> + + <p>This class serves to show the interface a node update + functor needs to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/tree_policy/sample_tree_node_update.hpp"><tt> + sample_tree_node_update.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Const_Node_Iterator1933878761" id= +"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a> +</pre> + </td> + + <td> + <p>Const node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Node_Iterator4206909839" id= +"Node_Iterator4206909839"><b>class</b> Node_Iterator</a> +</pre> + </td> + + <td> + <p>Node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Cmp_Fn294335" id="Cmp_Fn294335"><b>class</b> Cmp_Fn</a> +</pre> + </td> + + <td> + <p>Comparison functor.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator</a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td>-</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">Metadata definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_type2849297114" id= +"metadata_type2849297114">metadata_type</a> +</pre> + </td> + + <td> + <pre> +size_t +</pre> + </td> + + <td> + <p>Metadata type.</p> + + <p>This can be any type; size_t is merely an example.</p> + </td> + </tr> + </table> + + <h2><a name="link4" id="link4">Protected Methods</a></h2> + + <h3><a name="link5" id="link5">Conclassors, declassor, and + related.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + sample_tree_node_update + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + + <p>Must be default constructable.</p> + </td> + </tr> + </table> + + <h3><a name="link6" id="link6">Operators.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + <b>operator</b>() + (node_iterator node_it, + const_node_iterator end_nd_it) <b>const</b> +</pre> + </td> + + <td> + <p>Updates the rank of a node through a <span class= + "c1"><tt>node_iterator</tt></span> <span class= + "c1"><tt>node_it</tt></span>; <span class= + "c1"><tt>end_nd_it</tt></span> is the end node + iterator.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_e_access_traits.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_e_access_traits.html new file mode 100644 index 000000000..a46c91b1d --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_e_access_traits.html @@ -0,0 +1,231 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_trie_e_access_traits Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_trie_e_access_traits</tt> Interface</h1> + + <p>A sample trie element-access traits.</p> + + <p>This class serves to show the interface an element- access + traits class needs to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/trie_policy/sample_trie_e_access_traits.hpp"> + <tt>sample_trie_e_access_traits.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">General definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +size_t, e.g. +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="key_type10393186" id="key_type10393186">key_type</a> +</pre> + </td> + + <td> + <pre> +std::string, e.g. +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_key_reference3185471705" id= +"const_key_reference3185471705">const_key_reference</a> +</pre> + </td> + + <td> + <pre> +const string &, e.g. +</pre> + </td> + + <td> + <p>Const key reference type.</p> + </td> + </tr> + </table> + + <h3><a name="link3" id="link3">Element definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_iterator98626788" id= +"const_iterator98626788">const_iterator</a> +</pre> + </td> + + <td> + <pre> +string::const_iterator, e.g. +</pre> + </td> + + <td> + <p>Element <tt><b>const</b></tt> iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="e_type393186" id="e_type393186">e_type</a> +</pre> + </td> + + <td> + <pre> +char, e.g. +</pre> + </td> + + <td> + <p>Element type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="max_size10483336" id="max_size10483336">max_size</a> +</pre> + </td> + + <td> + <pre> +4, e.g. +</pre> + </td> + + <td> + <p>Number of distinct elements.</p> + </td> + </tr> + </table> + + <h2><a name="link4" id="link4">Public Methods</a></h2> + + <h3><a name="link5" id="link5">Access methods.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>static</b> <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a> + begin + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> to + the first element of <span class= + "c1"><tt>r_key</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>static</b> <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a> + end + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> to + the after-last element of <span class= + "c1"><tt>r_key</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>static</b> <a href= +"#size_type55424436"><tt>size_type</tt></a> + e_pos + (<a href="#e_type393186"><tt>e_type</tt></a> e) +</pre> + </td> + + <td> + <p>Maps an <span class="c1"><tt>element</tt></span> to a + position.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_node_update.html new file mode 100644 index 000000000..61b6b407f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_node_update.html @@ -0,0 +1,194 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_trie_node_update Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_trie_node_update</tt> Interface</h1> + + <p>A sample node updater.</p> + + <p>This class serves to show the interface a node update + functor needs to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/trie_policy/sample_trie_node_update.hpp"><tt> + sample_trie_node_update.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Const_Node_Iterator1933878761" id= +"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a> +</pre> + </td> + + <td> + <p>Const node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Node_Iterator4206909839" id= +"Node_Iterator4206909839"><b>class</b> Node_Iterator</a> +</pre> + </td> + + <td> + <p>Node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="E_Access_Traits686553840" id= +"E_Access_Traits686553840"><b>class</b> E_Access_Traits</a> +</pre> + </td> + + <td> + <p>Comparison functor.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator</a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td>-</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">Metadata definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_type2849297114" id= +"metadata_type2849297114">metadata_type</a> +</pre> + </td> + + <td> + <pre> +size_t +</pre> + </td> + + <td> + <p>Metadata type.</p> + + <p>This can be any type; size_t is merely an example.</p> + </td> + </tr> + </table> + + <h2><a name="link4" id="link4">Protected Methods</a></h2> + + <h3><a name="link5" id="link5">Conclassors, declassor, and + related.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + sample_trie_node_update + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + + <p>Must be default constructable.</p> + </td> + </tr> + </table> + + <h3><a name="link6" id="link6">Operators.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + <b>operator</b>() + (node_iterator node_it, + const_node_iterator end_nd_it) <b>const</b> +</pre> + </td> + + <td> + <p>Updates the rank of a node through a <span class= + "c1"><tt>node_iterator</tt></span> <span class= + "c1"><tt>node_it</tt></span>; <span class= + "c1"><tt>end_nd_it</tt></span> is the end node + iterator.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_update_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_update_policy.html new file mode 100644 index 000000000..8a286c74c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_update_policy.html @@ -0,0 +1,178 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>sample_update_policy Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>sample_update_policy</tt> Interface</h1> + + <p>A sample list-update policy.</p> + + <p>This class serves to show the interface a list update + functor needs to support.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/list_update_policy/sample_update_policy.hpp"><tt>sample_update_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Public Methods</a></h2> + + <h3><a name="link2" id="link2">Constructors, destructor, and + related.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + sample_update_policy + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + + <p>Must be default constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> + sample_update_policy + (<b>const</b> sample_update_policy &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + + <p>Must be copy constructable.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + swap + (sample_update_policy &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + + <p>Must be swappable (if there is such a word).</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Protected Types and + Constants</a></h2> + + <h3><a name="link4" id="link4">Metadata definitions.</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_type2849297114" id= +"metadata_type2849297114">metadata_type</a> +</pre> + </td> + + <td> + <pre> +Some metadata type. +</pre> + </td> + + <td> + <p>Metadata on which this functor operates.</p> + + <p>The <tt><b>class</b></tt> must declare the metadata + type on which it operates; the list-update based + containers will append to each node an object of this + type.</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Protected Methods</a></h2> + + <h3><a name="link6" id="link6">Metadata operations.</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#metadata_type2849297114"><tt>metadata_type</tt></a> + <b>operator</b>() + () <b>const</b> +</pre> + </td> + + <td> + <p>Creates a metadata object.</p> + + <p>A list-update based container object will call this + method to create a metadata type when a node is + created.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>bool</b> + <b>operator</b>() + (metadata_reference r_data) <b>const</b> +</pre> + </td> + + <td> + <p>Decides whether a metadata object should be moved to + the front of the list. A list-update based containers + object will call this method to decide whether to move a + node to the front of the list. The method should return + <tt><b>true</b></tt> if the node should be moved to the + front of the list.</p> + + <p><tt>metadata_reference</tt> is a reference to a + <a href= + "#metadata_type2849297114"><tt>metadata_type</tt></a>.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/simple_list.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/simple_list.png Binary files differnew file mode 100644 index 000000000..9a05d3f5e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/simple_list.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/splay_tree_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/splay_tree_tag.html new file mode 100644 index 000000000..3e6a64b1c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/splay_tree_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>splay_tree_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>splay_tree_tag</tt> Interface</h1> + + <p>Splay tree data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="tree_tag.html"><span class= +"c2"><tt>tree_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/string_trie_e_access_traits.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/string_trie_e_access_traits.html new file mode 100644 index 000000000..4ce9e864a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/string_trie_e_access_traits.html @@ -0,0 +1,400 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>string_trie_e_access_traits Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>string_trie_e_access_traits</tt> Interface</h1> + + <p>Element access traits for string types.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/trie_policy.hpp"><tt>trie_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="String349403" id="String349403"><b>class</b> String </a> +</pre> + </td> + + <td> + <p>String type.</p> + </td> + + <td><tt>std::string</tt></td> + </tr> + + <tr> + <td> + <pre> +<a name="Min_E_Val40354618" id= +"Min_E_Val40354618"><b>typename</b> </a><a href= +"#String349403"><tt>String</tt></a>::value_type Min_E_Val +</pre> + </td> + + <td> + <p>Minimal element.</p> + </td> + + <td><tt>SCHAR_MIN</tt></td> + </tr> + + <tr> + <td> + <pre> +<a name="Max_E_Val39885868" id= +"Max_E_Val39885868"><b>typename</b> </a><a href= +"#String349403"><tt>String</tt></a>::value_type Max_E_Val +</pre> + </td> + + <td> + <p>Maximal element.</p> + </td> + + <td><tt>SCHAR_MAX</tt></td> + </tr> + + <tr> + <td> + <pre> +<a name="Reverse1686776" id= +"Reverse1686776"><b>bool</b> Reverse </a> +</pre> + </td> + + <td> + <p>Indicates whether reverse iteration should be + used.</p> + </td> + + <td><tt><b>false</b></tt></td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator </a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td> + <pre> +std::allocator<<b>char</b>> +</pre> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::size_type +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">Key-Type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="key_type10393186" id="key_type10393186">key_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#String349403"><tt>String</tt></a> +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_key_reference3185471705" id= +"const_key_reference3185471705">const_key_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind< + <a href= +"#key_type10393186"><tt>key_type</tt></a>>::other::const_reference +</pre> + </td> + + <td> + <p>Const key reference type.</p> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Element-Type + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="reverse2186776" id="reverse2186776">reverse</a> +</pre> + </td> + + <td> + <pre> +<a href="#Reverse1686776"><tt>Reverse</tt></a> +</pre> + </td> + + <td> + <p><a href="#Reverse1686776"><tt>Reverse</tt></a> + iteration indicator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_iterator98626788" id= +"const_iterator98626788">const_iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> __gnu_pbds::detail::__conditional_type< + <a href="#Reverse1686776"><tt>Reverse</tt></a>, + <b>typename</b> <a href= +"#String349403"><tt>String</tt></a>::const_reverse_iterator, + <b>typename</b> <a href= +"#String349403"><tt>String</tt></a>::const_iterator>::__type +</pre> + </td> + + <td> + <p>Element <tt><b>const</b></tt> iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="e_type393186" id="e_type393186">e_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> std::iterator_traits<<a href= +"#const_iterator98626788"><tt>const_iterator</tt></a>>::value_type +</pre> + </td> + + <td> + <p>Element type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="min_e_val52875418" id="min_e_val52875418">min_e_val</a> +</pre> + </td> + + <td> + <pre> +<a href="#Min_E_Val40354618"><tt>Min_E_Val</tt></a> +</pre> + </td> + + <td> + <p>Minimal element.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="max_e_val52406668" id="max_e_val52406668">max_e_val</a> +</pre> + </td> + + <td> + <pre> +<a href="#Max_E_Val39885868"><tt>Max_E_Val</tt></a> +</pre> + </td> + + <td> + <p>Maximal element.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="max_size10483336" id="max_size10483336">max_size</a> +</pre> + </td> + + <td> + <pre> +<a href="#max_e_val52406668"><tt>max_e_val</tt></a> - <a href= +"#min_e_val52875418"><tt>min_e_val</tt></a> + 1 +</pre> + </td> + + <td> + <p>Number of distinct elements.</p> + </td> + </tr> + </table> + + <h2><a name="link6" id="link6">Public Methods</a></h2> + + <h3><a name="link7" id="link7">Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>static</b> <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a> + begin + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> to + the first element of <span class= + "c1"><tt>r_key</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>static</b> <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a> + end + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> to + the after-last element of <span class= + "c1"><tt>r_key</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>static</b> <a href= +"#size_type55424436"><tt>size_type</tt></a> + e_pos + (<a href="#e_type393186"><tt>e_type</tt></a> e) +</pre> + </td> + + <td> + <p>Maps an <span class="c1"><tt>e</tt></span>element to a + position.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tests.html new file mode 100644 index 000000000..ab5d54bb4 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tests.html @@ -0,0 +1,24 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Tests</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Tests</h1> + + <p><a href="assoc_tests.html">Associative-Container Tests</a> + describes tests for associative containers; <a href= + "pq_tests.html">Priority-Queue Tests</a> describes tests for + priority queues.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_gcc.png Binary files differnew file mode 100644 index 000000000..59247ec6a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_local.png Binary files differnew file mode 100644 index 000000000..d85980f30 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_msvc.png Binary files differnew file mode 100644 index 000000000..227164568 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_gcc.png Binary files differnew file mode 100644 index 000000000..8b6c4f0f0 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_local.png Binary files differnew file mode 100644 index 000000000..b7fdc4746 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_msvc.png Binary files differnew file mode 100644 index 000000000..dc82a4e7e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/thin_heap_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/thin_heap_tag.html new file mode 100644 index 000000000..c44189664 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/thin_heap_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>thin_heap_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>thin_heap_tag</tt> Interface</h1> + + <p>Thin heap data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="priority_queue_tag.html"><span class= +"c2"><tt>priority_queue_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree.html new file mode 100644 index 000000000..3202a6e9f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree.html @@ -0,0 +1,516 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>tree Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>tree</tt> Interface</h1> + + <p>A concrete basic tree-based associative container.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Key2501" id="Key2501"><b>typename</b> Key</a> +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a> +</pre> + </td> + + <td> + <p>Mapped type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Cmp_Fn294335" id="Cmp_Fn294335"><b>class</b> Cmp_Fn </a> +</pre> + </td> + + <td> + <p>Comparison functor.</p> + </td> + + <td> + <pre> +std::less<<a href="#Key2501"><tt>Key</tt></a>> +</pre> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="Tag278938" id="Tag278938"><b>class</b> Tag </a> +</pre> + </td> + + <td> + <p>Mapped-structure tag.</p> + </td> + + <td><a href="rb_tree_tag.html"><span class= + "c2"><tt>rb_tree_tag</tt></span></a></td> + </tr> + + <tr> + <td> + <pre> +<a name="Node_Update841554648" id= +"Node_Update841554648"><b>template</b>< + <b>typename</b> Const_Node_Iterator, + <b>typename</b> Node_Iterator, + <b>class</b> Cmp_Fn_, + <b>typename</b> Allocator_> +<b>class</b> Node_Update </a> +</pre> + </td> + + <td> + <p>Node updater type.</p> + + <p><a href= + "tree_based_containers.html#invariants">Design::Tree-Based + Containers::Node Invariants</a> explains this + concept.</p> + </td> + + <td><a href="null_tree_node_update.html"><span class= + "c2"><tt>null_tree_node_update</tt></span></a></td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator </a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td> + <pre> +std::allocator<<b>char</b>> +</pre> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="basic_tree.html"><span class= +"c2"><tt>basic_tree</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + + <h2><a name="link3" id="link3">Public Types and + Constants</a></h2> + + <h3><a name="link4" id="link4">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="cmp_fn394495" id="cmp_fn394495">cmp_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Cmp_Fn294335"><tt>Cmp_Fn</tt></a> +</pre> + </td> + + <td> + <p>Comparison functor type.</p> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Iterator Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_node_iterator4205924553" id= +"const_node_iterator4205924553">const_node_iterator</a> +</pre> + </td> + + <td> + <pre> +<a href= +"tree_const_node_iterator.html"><span class= +"c2"><tt>const_node_iterator</tt></span></a> +</pre> + </td> + + <td> + <p>Const node iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="node_iterator3431975247" id= +"node_iterator3431975247">node_iterator</a> +</pre> + </td> + + <td> + <pre> +<a href="tree_node_iterator.html"><span class= +"c2"><tt>node_iterator</tt></span></a> +</pre> + </td> + + <td> + <p>Node iterator.</p> + </td> + </tr> + </table> + + <h2><a name="link6" id="link6">Public Methods</a></h2> + + <h3><a name="link7" id="link7">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + tree + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> + tree + (<b>const</b> <a href= +"#cmp_fn394495"><tt>cmp_fn</tt></a> &r_cmp_fn) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_cmp_fn</tt></span> will be copied by the + <a href="#Cmp_Fn294335"><tt>Cmp_Fn</tt></a> object of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + tree + (It first_it, + It last_it) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of + value_types. The value_types between <span class= + "c1"><tt>first_it</tt></span> and <span class= + "c1"><tt>last_it</tt></span> will be inserted into the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + tree + (It first_it, + It last_it, + <b>const</b> <a href= +"#cmp_fn394495"><tt>cmp_fn</tt></a> &r_cmp_fn) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object. <span class= + "c1"><tt>r_cmp_fn</tt></span> will be copied by the + <a href="#cmp_fn394495"><tt>cmp_fn</tt></a> object of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + tree + (<b>const</b> <span class= +"c2"><tt>tree</tt></span> &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~tree + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<span class="c2"><tt>tree</tt></span> & + <b>operator</b>= + (<b>const</b> <span class= +"c2"><tt>tree</tt></span> &other) +</pre> + </td> + + <td> + <p>Assignment operator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class= +"c2"><tt>tree</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h3><a name="link8" id="link8">Policy Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#cmp_fn394495"><tt>cmp_fn</tt></a> & + get_cmp_fn + () +</pre> + </td> + + <td> + <p>Access to the <a href= + "#cmp_fn394495"><tt>cmp_fn</tt></a> object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>const</b> <a href="#cmp_fn394495"><tt>cmp_fn</tt></a> & + get_cmp_fn + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access to the <a href= + "#cmp_fn394495"><tt>cmp_fn</tt></a> object.</p> + </td> + </tr> + </table> + + <h3><a name="link9" id="link9">Node-Iteration Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#node_iterator3431975247"><tt>node_iterator</tt></a> + node_begin + () +</pre> + </td> + + <td> + <p>Returns a <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + corresponding to the node at the root of the tree.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + node_begin + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + corresponding to the node at the root of the tree.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#node_iterator3431975247"><tt>node_iterator</tt></a> + node_end + () +</pre> + </td> + + <td> + <p>Returns a <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + corresponding to a node just after a leaf of the + tree.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + node_end + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + corresponding to a node just after a leaf of the + tree.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_based_containers.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_based_containers.html new file mode 100644 index 000000000..63c7c7482 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_based_containers.html @@ -0,0 +1,358 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Tree-Based Containers</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Tree Design</h1> + + <h2><a name="overview" id="overview">Overview</a></h2> + + <p>The tree-based container has the following declaration:</p> + <pre> +<b>template</b>< + <b>typename</b> Key, + <b>typename</b> Mapped, + <b>typename</b> Cmp_Fn = std::less<Key>, + <b>typename</b> Tag = <a href="rb_tree_tag.html">rb_tree_tag</a>, + <b>template</b>< + <b>typename</b> Const_Node_Iterator, + <b>typename</b> Node_Iterator, + <b>typename</b> Cmp_Fn_, + <b>typename</b> Allocator_> + <b>class</b> Node_Update = <a href= +"null_tree_node_update.html">null_tree_node_update</a>, + <b>typename</b> Allocator = std::allocator<<b>char</b>> > +<b>class</b> <a href= +"tree.html">tree</a>; +</pre> + + <p>The parameters have the following meaning:</p> + + <ol> + <li><tt>Key</tt> is the key type.</li> + + <li><tt>Mapped</tt> is the mapped-policy.</li> + + <li><tt>Cmp_Fn</tt> is a key comparison functor</li> + + <li><tt>Tag</tt> specifies which underlying data structure + to use.</li> + + <li><tt>Node_Update</tt> is a policy for updating node + invariants. This is described in <a href="#invariants">Node + Invariants</a>.</li> + + <li><tt>Allocator</tt> is an allocator + type.</li> + </ol> + + <p>The <tt>Tag</tt> parameter specifies which underlying + data structure to use. Instantiating it by <a href= + "rb_tree_tag.html"><tt>rb_tree_tag</tt></a>, <a href= + "splay_tree_tag.html"><tt>splay_tree_tag</tt></a>, or + <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>, + specifies an underlying red-black tree, splay tree, or + ordered-vector tree, respectively; any other tag is illegal. + Note that containers based on the former two contain more types + and methods than the latter (<i>e.g.</i>, + <tt>reverse_iterator</tt> and <tt>rbegin</tt>), and different + exception and invalidation guarantees.</p> + + <h2><a name="invariants" id="invariants">Node + Invariants</a></h2> + + <p>Consider the two trees in Figures <a href= + "#node_invariants">Some node invariants</a> A and B. The first + is a tree of floats; the second is a tree of pairs, each + signifying a geometric line interval. Each element in a tree is refered to as a node of the tree. Of course, each of + these trees can support the usual queries: the first can easily + search for <tt>0.4</tt>; the second can easily search for + <tt>std::make_pair(10, 41)</tt>.</p> + + <p>Each of these trees can efficiently support other queries. + The first can efficiently determine that the 2rd key in the + tree is <tt>0.3</tt>; the second can efficiently determine + whether any of its intervals overlaps + <tt>std::make_pair(29,42)</tt> (useful in geometric + applications or distributed file systems with leases, for + example). (See <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_order_statistics.cc"><tt>tree_order_statistics.cc</tt></a> + and <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_intervals.cc"><tt>tree_intervals.cc</tt></a> + for examples.) It should be noted that an <tt>std::set</tt> can + only solve these types of problems with linear complexity.</p> + + <p>In order to do so, each tree stores some <i>metadata</i> in + each node, and maintains node invariants <a href= + "references.html#clrs2001">clrs2001</a>]. The first stores in + each node the size of the sub-tree rooted at the node; the + second stores at each node the maximal endpoint of the + intervals at the sub-tree rooted at the node.</p> + + <h6 class="c1"><a name="node_invariants" id= + "node_invariants"><img src="node_invariants.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Some node invariants.</h6> + + <p>Supporting such trees is difficult for a number of + reasons:</p> + + <ol> + <li>There must be a way to specify what a node's metadata + should be (if any).</li> + + <li>Various operations can invalidate node invariants. + <i>E.g.</i>, Figure <a href= + "#node_invariant_invalidations">Invalidation of node + invariants</a> shows how a right rotation, performed on A, + results in B, with nodes <i>x</i> and <i>y</i> having + corrupted invariants (the grayed nodes in C); Figure <a href= + "#node_invariant_invalidations">Invalidation of node + invariants</a> shows how an insert, performed on D, results + in E, with nodes <i>x</i> and <i>y</i> having corrupted + invariants (the grayed nodes in F). It is not feasible to + know outside the tree the effect of an operation on the nodes + of the tree.</li> + + <li>The search paths of standard associative containers are + defined by comparisons between keys, and not through + metadata.</li> + + <li>It is not feasible to know in advance which methods trees + can support. Besides the usual <tt>find</tt> method, the + first tree can support a <tt>find_by_order</tt> method, while + the second can support an <tt>overlaps</tt> method.</li> + </ol> + + <h6 class="c1"><a name="node_invariant_invalidations" id= + "node_invariant_invalidations"><img src= + "node_invariant_invalidations.png" alt="no image" /></a></h6> + + <h6 class="c1">Invalidation of node invariants.</h6> + + <p>These problems are solved by a combination of two means: + node iterators, and template-template node updater + parameters.</p> + + <h3><a name="node_it" id="node_it">Node Iterators</a></h3> + + <p>Each tree-based container defines two additional iterator + types, <a href= + "tree_const_node_iterator.html"><tt>const_node_iterator</tt></a> + and <a href= + "tree_node_iterator.html"><tt>node_iterator</tt></a>. + These iterators allow descending from a node to one of its + children. Node iterator allow search paths different than those + determined by the comparison functor. <a href= + "tree.html">tree</a> + supports the methods:</p> + <pre> + <a href="tree_const_node_iterator.html"><tt>const_node_iterator</tt></a> + node_begin() <b>const</b>; + + <a href="tree_node_iterator.html"><tt>node_iterator</tt></a> + node_begin(); + + <a href="tree_const_node_iterator.html"><tt>const_node_iterator</tt></a> + node_end() <b>const</b>; + + <a href="tree_node_iterator.html"><tt>node_iterator</tt></a> + node_end(); +</pre> + + <p>The first pairs return node iterators corresponding to the + root node of the tree; the latter pair returns node iterators + corresponding to a just-after-leaf node.</p> + + <h3><a name="node_up" id="node_up">Node Updater + (Template-Template) Parameters</a></h3> + + <p>The tree-based containers are parametrized by a + <tt>Node_Update</tt> template-template parameter. A tree-based + container instantiates <tt>Node_Update</tt> to some + <tt>node_update</tt> class, and publicly + subclasses <tt>node_update</tt>. Figure + <a href="#tree_node_update_cd">A tree and its update + policy</a> shows this scheme, as well as some predefined + policies (which are explained below).</p> + + <h6 class="c1"><a name="tree_node_update_cd" id= + "tree_node_update_cd"><img src= + "tree_node_update_policy_cd.png" alt="no image" /></a></h6> + + <h6 class="c1">A tree and its update policy.</h6> + + <p><tt>node_update</tt> (an instantiation of + <tt>Node_Update</tt>) must define <tt>metadata_type</tt> as + the type of metadata it requires. For order statistics, + <i>e.g.</i>, <tt>metadata_type</tt> might be <tt>size_t</tt>. + The tree defines within each node a <tt>metadata_type</tt> + object.</p> + + <p><tt>node_update</tt> must also define the following method + for restoring node invariants:</p> + <pre> + void + operator()(<a href= +"tree_node_iterator.html"><tt>node_iterator</tt></a> nd_it, <a href= +"tree_const_node_iterator.html"><tt>const_node_iterator</tt></a> end_nd_it) +</pre> + + <p>In this method, <tt>nd_it</tt> is a <a href= + "tree_node_iterator.html"><tt>node_iterator</tt></a> + corresponding to a node whose A) all descendants have valid + invariants, and B) its own invariants might be violated; + <tt>end_nd_it</tt> is a <a href= + "tree_const_node_iterator.html"><tt>const_node_iterator</tt></a> + corresponding to a just-after-leaf node. This method should + correct the node invariants of the node pointed to by + <tt>nd_it</tt>. For example, say node <i>x</i> in Figure + <a href="#restoring_node_invariants">Restoring node + invariants</a>-A has an invalid invariant, but its' children, + <i>y</i> and <i>z</i> have valid invariants. After the + invocation, all three nodes should have valid invariants, as in + Figure <a href="#restoring_node_invariants">Restoring node + invariants</a>-B.</p> + + <h6 class="c1"><a name="restoring_node_invariants" id= + "restoring_node_invariants"><img src= + "restoring_node_invariants.png" alt="no image" /></a></h6> + + <h6 class="c1">Invalidation of node invariants.</h6> + + <p>When a tree operation might invalidate some node invariant, + it invokes this method in its <tt>node_update</tt> base to + restore the invariant. For example, Figure <a href= + "#update_seq_diagram">Insert update sequence diagram</a> shows + an <tt>insert</tt> operation (point A); the tree performs some + operations, and calls the update functor three times (points B, + C, and D). (It is well known that any <tt>insert</tt>, + <tt>erase</tt>, <tt>split</tt> or <tt>join</tt>, can restore + all node invariants by a small number of node invariant updates + [<a href="references.html#clrs2001">clrs2001</a>].)</p> + + <h6 class="c1"><a name="update_seq_diagram" id= + "update_seq_diagram"><img src="update_seq_diagram.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Insert update sequence diagram.</h6> + + <p>To complete the description of the scheme, three questions + need to be answered:</p> + + <ol> + <li>How can a tree which supports order statistics define a + method such as <tt>find_by_order</tt>?</li> + + <li>How can the node updater base access methods of the + tree?</li> + + <li>How can the following cyclic dependency be resolved? + <tt>node_update</tt> is a base class of the tree, yet it + uses node iterators defined in the tree (its child).</li> + </ol> + + <p>The first two questions are answered by the fact that + <tt>node_update</tt> (an instantiation of + <tt>Node_Update</tt>) is a <tt><b>public</b></tt> base class + of the tree. Consequently:</p> + + <ol> + <li>Any public methods of <tt>node_update</tt> are + automatically methods of the tree [<a href= + "references.html#alexandrescu01modern">alexandrescu01modern</a>]. + Thus an order-statistics node updater, <a href= + "tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a> + defines the <tt>find_by_order</tt> method; any tree + instantiated by this policy consequently supports this method + as well.</li> + + <li>In C++, if a base class declares a method as + <tt><b>virtual</b></tt>, it is <tt><b>virtual</b></tt> in its + subclasses. If <tt>node_update</tt> needs to access one of + the tree's methods, say the member function <tt>end</tt>, it simply + declares that method as <tt><b>virtual</b></tt> + abstract.</li> + </ol> + + <p>The cyclic dependency is solved through template-template + parameters. <tt>Node_Update</tt> is parametrized by the tree's node iterators, its comparison + functor, and its allocator type. Thus, + instantiations of <tt>Node_Update</tt> have all information required.</p> + + <p class="c1"><tt>pb_ds</tt> assumes that constructing a metadata object and modifying it + are exception free. Suppose that during some method, say + <tt>insert</tt>, a metadata-related operation + (<i>e.g.</i>, changing the value of a metadata) throws an + exception. Ack! Rolling back the method is unusually complex.</p> + + <p>In <a href= + "concepts.html#concepts_null_policies">Interface::Concepts::Null + Policy Classes</a> a distinction was made between <i>redundant + policies</i> and <i>null policies</i>. Node invariants show a + case where null policies are required.</p> + + <p>Assume a regular tree is required, one which need not + support order statistics or interval overlap queries. + Seemingly, in this case a redundant policy - a policy which + doesn't affect nodes' contents would suffice. This, would lead + to the following drawbacks:</p> + + <ol> + <li>Each node would carry a useless metadata object, wasting + space.</li> + + <li>The tree cannot know if its <tt>Node_Update</tt> policy + actually modifies a node's metadata (this is halting + reducible). In Figure <a href= + "#rationale_null_node_update">Useless update path</a> , + assume the shaded node is inserted. The tree would have to + traverse the useless path shown to the root, applying + redundant updates all the way.</li> + </ol> + + <h6 class="c1"><a name="rationale_null_node_update" id= + "rationale_null_node_update"><img src= + "rationale_null_node_update.png" alt="no image" /></a></h6> + + <h6 class="c1">Useless update path.</h6> + + <p>A null policy class, <a href= + "null_tree_node_update.html"><tt>null_tree_node_update</tt></a> + solves both these problems. The tree detects that node + invariants are irrelevant, and defines all accordingly.</p> + + <h2><a name="add_methods" id="add_methods">Additional + Methods</a></h2> + + <p>Tree-based containers support split and join methods. + It is possible to split a tree so that it passes + all nodes with keys larger than a given key to a different + tree. These methods have the following advantages over the + alternative of externally inserting to the destination + tree and erasing from the source tree:</p> + + <ol> + <li>These methods are efficient - red-black trees are split + and joined in poly-logarithmic complexity; ordered-vector + trees are split and joined at linear complexity. The + alternatives have super-linear complexity.</li> + + <li>Aside from orders of growth, these operations perform + few allocations and de-allocations. For red-black trees, allocations are not performed, + and the methods are exception-free. </li> + </ol> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_iterator.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_iterator.html new file mode 100644 index 000000000..ba09b5b4d --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_iterator.html @@ -0,0 +1,143 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>tree::node_iterator Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt><span class= + "c2"><tt>tree</tt></span>::node_iterator</tt> + Interface</h1> + + <p>Node iterator.</p> + + <p>This is an <quote>iterator to an iterator </quote> - it + iterates over nodes, and de-referencing it returns one of the + tree's iterators</p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href= +"tree.html#const_node_iterator4205924553"><span class="c2"><tt>tree</tt></span>::const_node_iterator</a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Methods</a></h2> + + <h3><a name="link3" id="link3">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> + node_iterator + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"container_base.html#iterator10418194"><span class= +"c2"><tt>container_base</tt></span>::iterator</a> + <b>operator</b>* + () <b>const</b> +</pre> + </td> + + <td> + <p>Access.</p> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Movement Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <span class="c2"><tt>node_iterator</tt></span> + get_l_child + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns the node iterator associated with the left + node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <span class="c2"><tt>node_iterator</tt></span> + get_r_child + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns the node iterator associated with the right + node.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_updator_policy_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_updator_policy_cd.png Binary files differnew file mode 100644 index 000000000..5cae5781a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_updator_policy_cd.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_node_update.html new file mode 100644 index 000000000..f4345531f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_node_update.html @@ -0,0 +1,678 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>tree_order_statistics_node_update Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>tree_order_statistics_node_update</tt> Interface</h1> + + <p>Functor updating ranks of entrees.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tree_policy.hpp"><tt>tree_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Const_Node_Iterator1933878761" id= +"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a> +</pre> + </td> + + <td> + <p>Const node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Node_Iterator4206909839" id= +"Node_Iterator4206909839"><b>class</b> Node_Iterator</a> +</pre> + </td> + + <td> + <p>Node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Cmp_Fn294335" id="Cmp_Fn294335"><b>class</b> Cmp_Fn</a> +</pre> + </td> + + <td> + <p>Comparison functor.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator</a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td>-</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="cmp_fn394495" id="cmp_fn394495">cmp_fn</a> +</pre> + </td> + + <td> + <pre> +<a href="#Cmp_Fn294335"><tt>Cmp_Fn</tt></a> +</pre> + </td> + + <td> + <p><a href="#Allocator35940069"><tt>Allocator</tt></a> + type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="allocator48440069" id="allocator48440069">allocator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Allocator35940069"><tt>Allocator</tt></a> +</pre> + </td> + + <td> + <p><a href="#Allocator35940069"><tt>Allocator</tt></a> + type.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::size_type +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Key-type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="key_type10393186" id="key_type10393186">key_type</a> +</pre> + </td> + + <td> + <pre> +The instantiating container's key type. +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_key_reference3185471705" id= +"const_key_reference3185471705">const_key_reference</a> +</pre> + </td> + + <td> + <pre> +The instantiating container's const key reference type. +</pre> + </td> + + <td> + <p>Const key reference.</p> + </td> + </tr> + </table> + + <h3><a name="link6" id="link6">Metadata-Type + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_type2849297114" id= +"metadata_type2849297114">metadata_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#size_type55424436"><tt>size_type</tt></a> +</pre> + </td> + + <td> + <p>Metadata type.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Iterator Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_node_iterator4205924553" id= +"const_node_iterator4205924553">const_node_iterator</a> +</pre> + </td> + + <td> + <pre> +<a href= +"#Const_Node_Iterator1933878761"><tt>Const_Node_Iterator</tt></a> +</pre> + </td> + + <td> + <p>Const node iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="node_iterator3431975247" id= +"node_iterator3431975247">node_iterator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Node_Iterator4206909839"><tt>Node_Iterator</tt></a> +</pre> + </td> + + <td> + <p>Node iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_iterator98626788" id= +"const_iterator98626788">const_iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>::value_type +</pre> + </td> + + <td> + <p>Const iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="iterator10418194" id="iterator10418194">iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a>::value_type +</pre> + </td> + + <td> + <p>Iterator type.</p> + </td> + </tr> + </table> + + <h2><a name="link8" id="link8">Public Methods</a></h2> + + <h3><a name="link9" id="link9">Find-Type Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a> + find_by_order + (<a href= +"#size_type55424436"><tt>size_type</tt></a> order) <b>const</b> +</pre> + </td> + + <td> + <p>Finds an entry by order. Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> to + the entry with the order <span class= + "c1"><tt>order</tt></span>, or a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> to + the container object's end if <span class= + "c1"><tt>order</tt></span> is at least the size of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#iterator10418194"><tt>iterator</tt></a> + find_by_order + (<a href="#size_type55424436"><tt>size_type</tt></a> order) +</pre> + </td> + + <td> + <p>Finds an entry by order. Returns an <a href= + "#iterator10418194"><tt>iterator</tt></a> to the entry + with the order <span class="c1"><tt>order</tt></span>, or + an <a href="#iterator10418194"><tt>iterator</tt></a> to + the container object's end if <span class= + "c1"><tt>order</tt></span> is at least the size of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + order_of_key + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b> +</pre> + </td> + + <td> + <p>Returns the order of a key within a sequence. For + example, if <span class="c1"><tt>r_key</tt></span> is the + smallest key, this method will return 0; if <span class= + "c1"><tt>r_key</tt></span> is a key between the smallest + and next key, this method will return 1; if <span class= + "c1"><tt>r_key</tt></span> is a key larger than the + largest key, this method will return the size of r_c.</p> + </td> + </tr> + </table> + + <h2><a name="link10" id="link10">Protected Types and + Constants</a></h2> + + <h3><a name="link11" id="link11">Value-type + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_reference495461441" id= +"const_reference495461441">const_reference</a> +</pre> + </td> + + <td> + <pre> +The instantiating container's const reference type. +</pre> + </td> + + <td> + <p>Const reference to the container's value-type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_pointer878814947" id= +"const_pointer878814947">const_pointer</a> +</pre> + </td> + + <td> + <pre> +The instantiating container's const pointer type. +</pre> + </td> + + <td> + <p>Const pointer to the container's value-type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_metadata_reference1108857465" id= +"const_metadata_reference1108857465">const_metadata_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind< + <a href= +"#metadata_type2849297114"><tt>metadata_type</tt></a>>::other::<a href="#const_reference495461441"><tt>const_reference</tt></a> +</pre> + </td> + + <td> + <p>Const metadata reference.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_reference583863863" id= +"metadata_reference583863863">metadata_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind< + <a href= +"#metadata_type2849297114"><tt>metadata_type</tt></a>>::other::reference +</pre> + </td> + + <td> + <p>Metadata reference.</p> + </td> + </tr> + </table> + + <h2><a name="link12" id="link12">Protected Methods</a></h2> + + <h3><a name="link13" id="link13">Operators</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + <b>operator</b>() + (<a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a> node_it, + <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> end_nd_it) <b>const</b> +</pre> + </td> + + <td> + <p>Updates the rank of a node through a <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + <span class="c1"><tt>node_it</tt></span>; <span class= + "c1"><tt>end_nd_it</tt></span> is the end node <a href= + "#iterator10418194"><tt>iterator</tt></a>.</p> + </td> + </tr> + </table> + + <h3><a name="link14" id="link14">Constructors, destructor, and + related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~tree_order_statistics_node_update + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + </table> + + <h2><a name="link15" id="link15">Private Methods</a></h2> + + <h3><a name="link16" id="link16">Overrides</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + node_begin + () <b>const</b> = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + associated with the tree's root node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a> + node_begin + () = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + associated with the tree's root node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + node_end + () <b>const</b> = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + associated with a just-after leaf node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a> + node_end + () = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + associated with a just-after leaf node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href="#cmp_fn394495"><tt>cmp_fn</tt></a> & + get_cmp_fn + () = 0 +</pre> + </td> + + <td> + <p>Access to the <a href= + "#cmp_fn394495"><tt>cmp_fn</tt></a> object.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test.html new file mode 100644 index 000000000..ef811613e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test.html @@ -0,0 +1,118 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Tree Order Statistics Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Tree Order-Statistics Timing Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test creates a container, inserts random integers into + the the container, and then checks the order-statistics of the + container's values. (If the container is one of <tt>pb_ds</tt> + 's trees, it does this with the <tt>order_of_key</tt> method of + <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a> + ; otherwise, it uses the <tt>find</tt> method and + <tt>std::distance</tt> .) It measures the average time for such + queries as a function of the number of values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/tree_order_statistics_timing.cc"><tt>tree_order_statistics_timing_test</tt></a> + 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the performance difference of policies based + on node-invariant as opposed to a external functions. (see + <a href="tree_based_containers.html#invariants">Design::Associative + Containers::Tree-Based Containers::Node Invariants</a> .)</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and + <a href="#NTL">NTL</a> show the results for the native and + tree-based containers in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTG_res_div"> +<div id="NTG_gcc"> +<div id="NTG_tree_order_statistics_timing_test"> +<div id="NTG_assoc"> +<div id="NTG_Native_and_tree-based_container_order-statistics_queries"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="tree_order_statistics_timing_test_gcc.png" alt="no image" /></a></h6>NTG: Native and tree-based container order-statistics queries - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_set- +<tt>std::set</tt></li> +<li> +splay_tree_ost_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a> +</li> +<li> +rb_tree_ost_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTM_res_div"> +<div id="NTM_msvc"> +<div id="NTM_tree_order_statistics_timing_test"> +<div id="NTM_assoc"> +<div id="NTM_Native_and_tree-based_container_order-statistics_queries"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="tree_order_statistics_timing_test_msvc.png" alt="no image" /></a></h6>NTM: Native and tree-based container order-statistics queries - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_set- +<tt>std::set</tt></li> +<li> +splay_tree_ost_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a> +</li> +<li> +rb_tree_ost_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTL_res_div"> +<div id="NTL_local"> +<div id="NTL_tree_order_statistics_timing_test"> +<div id="NTL_assoc"> +<div id="NTL_Native_and_tree-based_container_order-statistics_queries"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="tree_order_statistics_timing_test_local.png" alt="no image" /></a></h6>NTL: Native and tree-based container order-statistics queries - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>In this test, the native red-black tree can support + order-statistics queries only externally, by performing a + <tt>find</tt> (alternatively, <tt>lower_bound</tt> or + <tt>upper_bound</tt> ) and then using <tt>std::distance</tt> . + This is clearly linear, and it is not that surprising that the + cost is high.</p> +<p><tt>pb_ds</tt> 's tree-based containers use in this test the + <tt>order_of_key</tt> method of <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a>. + This method has only linear complexity in the length of the + root-node path. Unfortunately, the average path of a splay tree + (<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> ) can + be higher than logarithmic; the longest path of a red-black + tree (<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> ) is + logarithmic in the number of elements. Consequently, the splay + tree has worse performance than the red-black tree.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..bdb00d07a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_local.png Binary files differnew file mode 100644 index 000000000..2b921743f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..76dcbee44 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_random_int_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_random_int_find_find_timing_test.html new file mode 100644 index 000000000..c34354f3e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_random_int_find_find_timing_test.html @@ -0,0 +1,160 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Tree Text Find Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Tree-Based and Trie-Based Text <tt>find</tt> Find Timing + Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([<a href="references.html#wickland96thirty">wickland96thirty</a>]) into + a container, then performs a series of finds using + <tt>find</tt>. It measures the average time for <tt>find</tt> + as a function of the number of values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/text_find_timing.cc"><tt>text_find_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures.</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTTG">NTTG</a>, <a href="#NTTM">NTTM</a>, + and <a href="#NTTG">NTTL</a> show the results for the native, + tree-based, and trie-based types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#local"><u>local</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTTG_res_div"> +<div id="NTTG_gcc"> +<div id="NTTG_random_int_find_find_timing_test_tree"> +<div id="NTTG_assoc"> +<div id="NTTG_Native_456_tree-based_456_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTG" id="NTTG"><img src="random_int_find_find_timing_test_tree_gcc.png" alt="no image" /></a></h6>NTTG: Native, tree-based, random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +splay_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +ov_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +<li> +rb_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +<div id="NTTM_res_div"> +<div id="NTTM_msvc"> +<div id="NTTM_random_int_find_find_timing_test_tree"> +<div id="NTTM_assoc"> +<div id="NTTM_Native_456_tree-based_456_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTM" id="NTTM"><img src="random_int_find_find_timing_test_tree_msvc.png" alt="no image" /></a></h6>NTTM: Native, tree-based, random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +splay_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +ov_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +<li> +rb_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +<div id="NTTL_res_div"> +<div id="NTTL_local"> +<div id="NTTL_random_int_find_find_timing_test_tree"> +<div id="NTTL_assoc"> +<div id="NTTL_Native_456_tree-based_456_random_int_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTL" id= "NTTL"><img src="random_int_find_find_timing_test_tree_local.png" alt="no image" /></a></h6>NTTL: Native, tree-based, random int find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>For this setting, a splay tree (<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>) + does not do well. This is possibly due to two + reasons:</p> +<ol> +<li>A splay tree is not guaranteed to be balanced + [<a href="references.html#motwani95random">motwani95random</a>]. + If a splay tree contains <i>n</i> nodes, its + average root-leaf path can be <i>m >> + log(n)</i>.</li> +<li>Assume a specific root-leaf search path has + length <i>m</i>, and the search-target node has + distance <i>m'</i> from the root. A red-black + tree will require <i>m + 1</i> comparisons to + find the required node; a splay tree will require + <i>2 m'</i> comparisons. A splay tree, + consequently, can perform many more comparisons + than a red-black tree.</li> +</ol> +<p>An ordered-vector tree (<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>), + a red-black tree (<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>rb_tree_tag</tt></a>), + and the native red-black tree all share + approximately the same performance.</p> +<p>An ordered-vector tree is slightly slower than + red-black trees, since it requires, in order to + find a key, more math operations than they do. + Conversely, an ordered-vector tree requires far + lower space than the others. ([<a href="references.html#austern00noset">austern00noset</a>], + however, seems to have an implementation that is + also faster than a red-black tree).</p> +<p>A PATRICIA trie (<a href="trie.html"><tt>trie</tt></a> + with <tt>Tag =</tt> <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a>) + has good look-up performance, due to its large + fan-out in this case. In this setting, a PATRICIA + trie has lookup performance comparable to a hash + table (see <a href="hash_text_find_find_timing_test.html">Hash-Based + Text <tt>find</tt> Find Timing Test</a>), but it is + order preserving. This is not that surprising, + since a large fan-out PATRICIA trie works like a + hash table with collisions resolved by a sub-trie. + A large fan-out PATRICIA trie does not do well on + modifications (see <a href="tree_text_insert_timing_test.html">Tree-Based and + Trie-Based Text Insert Timing Test</a>). It is + possibly beneficial to semi-static settings, + therefore.</p> +<p><a href="assoc_performance_tests.html#tree_like_based_types"> + Observations::Tree-Like-Based Container Types</a> + summarizes some observations on tree-based and + trie-based containers.</p> +</div> +</div> +</div> +</div> +</div> +</div> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test.html new file mode 100644 index 000000000..9164984d1 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test.html @@ -0,0 +1,143 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Tree Split Join Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Tree Split-Join Timing Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test a container, inserts into a number of values, + splits the container at the median, and joins the two + containers. (If the containers are one of <tt>pb_ds</tt> 's + trees, it splits and joins with the <tt>split</tt> and + <tt>join</tt> method; otherwise, it uses the <tt>erase</tt> and + <tt>insert</tt> methods.) It measures the time for splitting + and joining the containers as a function of the number of + values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/tree_split_join_timing.cc"><tt>tree_split_join_timing_test</tt></a> + 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the performance difference of <tt>join</tt> + as opposed to a sequence of <tt>insert</tt> operations; by + implication, this test checks the most efficient way to erase a + sub-sequence from a tree-like-based container, since this can + always be performed by a small sequence of splits and joins + (see <a href="motivation.html#assoc_split_join_methods">Motivation::Associative + Containers::Slightly Different Methods::Methods Related to + Split and Join</a> and <a href="tree_based_containers.html#add_methods">Design::Associative + Containers::Tree-Based Containers::Additional Methods</a> + .)</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and + <a href="#NTL">NTL</a> show the results for the native and + tree-based containers in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTG_res_div"> +<div id="NTG_gcc"> +<div id="NTG_tree_split_join_timing_test"> +<div id="NTG_assoc"> +<div id="NTG_Native_and_tree-based_container_splits_and_joins"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="tree_split_join_timing_test_gcc.png" alt="no image" /></a></h6>NTG: Native and tree-based container splits and joins - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_set- +<tt>std::set</tt></li> +<li> +splay_tree_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +rb_tree_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +ov_tree_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTM_res_div"> +<div id="NTM_msvc"> +<div id="NTM_tree_split_join_timing_test"> +<div id="NTM_assoc"> +<div id="NTM_Native_and_tree-based_container_splits_and_joins"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="tree_split_join_timing_test_msvc.png" alt="no image" /></a></h6>NTM: Native and tree-based container splits and joins - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_set- +<tt>std::set</tt></li> +<li> +splay_tree_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +rb_tree_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +ov_tree_set- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTL_res_div"> +<div id="NTL_local"> +<div id="NTL_tree_split_join_timing_test"> +<div id="NTL_assoc"> +<div id="NTL_Native_and_tree-based_container_splits_and_joins"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="tree_split_join_timing_test_local.png" alt="no image" /></a></h6>NTL: Native and tree-based container splits and joins - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>In this test, the native red-black trees must be split and + joined externally, through a sequence of <tt>erase</tt> and + <tt>insert</tt> operations. This is clearly super-linear, and + it is not that surprising that the cost is high.</p> +<p><tt>pb_ds</tt> 's tree-based containers use in this test the + <tt>split</tt> and <tt>join</tt> methods, which have lower + complexity: the <tt>join</tt> method of a splay tree ( <a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> ) is + quadratic in the length of the longest root-leaf path, and + linear in the total number of elements; the <tt>join</tt> + method of a red-black tree ( <a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> ) or an + ordered-vector tree ( <a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> ) is linear + in the number of elements.</p> +<p>Asides from orders of growth, <tt>pb_ds</tt> 's trees access + their allocator very little in these operations, and some of + them do not access it at all. This leads to lower constants in + their complexity, and, for some containers, to exception-free + splits and joins (which can be determined via <a href="assoc_container_traits.html"><tt>container_traits</tt></a>).</p> +<p>It is important to note that <tt>split</tt> and + <tt>join</tt> are not esoteric methods - they are the most + efficient means of erasing a contiguous range of values from a + tree based container.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..88867eca6 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_local.png Binary files differnew file mode 100644 index 000000000..131d24a1a --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..37ed1b2e7 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_tag.html new file mode 100644 index 000000000..d7265ac18 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>tree_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>tree_tag</tt> Interface</h1> + + <p>Basic tree data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="basic_tree_tag.html"><span class= +"c2"><tt>basic_tree_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_find_find_timing_test.html new file mode 100644 index 000000000..fbfdfeffa --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_find_find_timing_test.html @@ -0,0 +1,162 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Tree Text Find Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Tree-Based and Trie-Based Text <tt>find</tt> Find Timing + Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([<a href="references.html#wickland96thirty">wickland96thirty</a>]) into + a container, then performs a series of finds using + <tt>find</tt>. It measures the average time for <tt>find</tt> + as a function of the number of values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/text_find_timing.cc"><tt>text_find_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures.</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTTG">NTTG</a>, <a href="#NTTM">NTTM</a>, + and <a href="#NTTG">NTTL</a> show the results for the native, + tree-based, and trie-based types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#local"><u>local</u></a>, and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTTG_res_div"> +<div id="NTTG_gcc"> +<div id="NTTG_text_find_timing_test_tree_like"> +<div id="NTTG_assoc"> +<div id="NTTG_Native_456_tree-based_456_and_trie-based_456_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTG" id="NTTG"><img src="text_find_timing_test_tree_like_gcc.png" alt="no image" /></a></h6>NTTG: Native, tree-based, and trie-based, text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +splay_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +ov_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +rb_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +<li> +pat_trie_map- +<a href="trie.html"><tt>trie</tt></a> + with <tt>Tag</tt> = <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_trie_node_update.html"><tt>null_trie_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTTM_res_div"> +<div id="NTTM_msvc"> +<div id="NTTM_text_find_timing_test_tree_like"> +<div id="NTTM_assoc"> +<div id="NTTM_Native_456_tree-based_456_and_trie-based_456_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTM" id="NTTM"><img src="text_find_timing_test_tree_like_msvc.png" alt="no image" /></a></h6>NTTM: Native, tree-based, and trie-based, text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +splay_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +ov_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +rb_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +<li> +pat_trie_map- +<a href="trie.html"><tt>trie</tt></a> + with <tt>Tag</tt> = <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_trie_node_update.html"><tt>null_trie_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTTL_res_div"> +<div id="NTTL_local"> +<div id="NTTL_text_find_timing_test_tree_like"> +<div id="NTTL_assoc"> +<div id="NTTL_Native_456_tree-based_456_and_trie-based_456_text_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTL" id= "NTTL"><img src="text_find_timing_test_tree_like_local.png" alt="no image" /></a></h6>NTTL: Native, tree-based, and trie-based, text find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>For this setting, a splay tree (<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>) does + not do well. This is possibly due to two reasons:</p> +<ol> +<li>A splay tree is not guaranteed to be balanced [<a href="references.html#motwani95random">motwani95random</a>]. If a + splay tree contains <i>n</i> nodes, its average root-leaf + path can be <i>m >> log(n)</i>.</li> +<li>Assume a specific root-leaf search path has length + <i>m</i>, and the search-target node has distance <i>m'</i> + from the root. A red-black tree will require <i>m + 1</i> + comparisons to find the required node; a splay tree will + require <i>2 m'</i> comparisons. A splay tree, consequently, + can perform many more comparisons than a red-black tree.</li> +</ol> +<p>An ordered-vector tree (<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>), a red-black + tree (<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>rb_tree_tag</tt></a>), and the + native red-black tree all share approximately the same + performance.</p> +<p>An ordered-vector tree is slightly slower than red-black + trees, since it requires, in order to find a key, more math + operations than they do. Conversely, an ordered-vector tree + requires far lower space than the others. ([<a href="references.html#austern00noset">austern00noset</a>], however, + seems to have an implementation that is also faster than a + red-black tree).</p> +<p>A PATRICIA trie (<a href="trie.html"><tt>trie</tt></a> + with <tt>Tag =</tt> <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a>) has good + look-up performance, due to its large fan-out in this case. In + this setting, a PATRICIA trie has look-up performance comparable + to a hash table (see <a href="hash_text_find_find_timing_test.html">Hash-Based Text + <tt>find</tt> Find Timing Test</a>), but it is order + preserving. This is not that surprising, since a large-fan-out + PATRICIA trie works like a hash table with collisions resolved + by a sub-trie. A large-fan-out PATRICIA trie does not do well on + modifications (see <a href="tree_text_insert_timing_test.html">Tree-Based and Trie-Based + Text Insert Timing Test</a>). It is possibly beneficial to + semi-static settings, therefore.</p> +<p><a href="assoc_performance_tests.html#tree_like_based_types">Observations::Tree-Like-Based + Container Types</a> summarizes some observations on tree-based + and trie-based containers.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test.html new file mode 100644 index 000000000..a5815fb2e --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test.html @@ -0,0 +1,226 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Tree Text Insert Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Tree-Based and Trie-Based Text Insert Timing Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into + a container using <tt>insert</tt> . It measures the average + time for <tt>insert</tt> as a function of the number of values + inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/tree_text_insert_timing.cc"><tt>tree_text_insert_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures.</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NNTG">NNTG</a>, <a href="#NVTG">NVTG</a>, + and <a href="#NPTG">NPTG</a> show the results for the native + tree and <tt>pb_ds</tt>'s node-based trees, the native tree and + <tt>pb_ds</tt>'s vector-based trees, and the native tree + and<tt>pb_ds</tt>'s PATRICIA-trie, respectively, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>; Figures + <a href="#NNTM">NNTM</a>, <a href="#NVTM">NVTM</a>, and + <a href="#NPTM">NPTM</a> show the same in <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>; Figures + <a href="#NNTL">NNTL</a>, <a href="#NVTL">NVTL</a>, and + <a href="#NPTL">NPTL</a> show the same in <a href="assoc_performance_tests.html#local"><u>local</u></a>.</p> +<div id="NNTG_res_div"> +<div id="NNTG_gcc"> +<div id="NNTG_tree_text_insert_timing_test_node_tree"> +<div id="NNTG_assoc"> +<div id="NNTG_Native_tree_and_node-based_trees_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NNTG" id="NNTG"><img src="tree_text_insert_timing_test_node_tree_gcc.png" alt="no image" /></a></h6>NNTG: Native tree and node-based trees text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +splay_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +<li> +rb_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NVTG_res_div"> +<div id="NVTG_gcc"> +<div id="NVTG_tree_text_insert_timing_test_vector_tree"> +<div id="NVTG_assoc"> +<div id="NVTG_Native_tree_and_vector-based_tree_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NVTG" id="NVTG"><img src="tree_text_insert_timing_test_vector_tree_gcc.png" alt="no image" /></a></h6>NVTG: Native tree and vector-based tree text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +ov_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPTG_res_div"> +<div id="NPTG_gcc"> +<div id="NPTG_tree_text_insert_timing_test_pat_trie"> +<div id="NPTG_assoc"> +<div id="NPTG_Native_tree_and_PATRICIA_trie_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPTG" id="NPTG"><img src="tree_text_insert_timing_test_pat_trie_gcc.png" alt="no image" /></a></h6>NPTG: Native tree and PATRICIA trie text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +n_map- +<tt>std::map</tt></li> +<li> +pat_trie_map- +<a href="trie.html"><tt>trie</tt></a> + with <tt>Tag</tt> = <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_trie_node_update.html"><tt>null_trie_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NNTM_res_div"> +<div id="NNTM_msvc"> +<div id="NNTM_tree_text_insert_timing_test_node_tree"> +<div id="NNTM_assoc"> +<div id="NNTM_Native_tree_and_node-based_trees_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NNTM" id="NNTM"><img src="tree_text_insert_timing_test_node_tree_msvc.png" alt="no image" /></a></h6>NNTM: Native tree and node-based trees text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +splay_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +<li> +rb_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NVTM_res_div"> +<div id="NVTM_msvc"> +<div id="NVTM_tree_text_insert_timing_test_vector_tree"> +<div id="NVTM_assoc"> +<div id="NVTM_Native_tree_and_vector-based_tree_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NVTM" id="NVTM"><img src="tree_text_insert_timing_test_vector_tree_msvc.png" alt="no image" /></a></h6>NVTM: Native tree and vector-based tree text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +ov_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPTM_res_div"> +<div id="NPTM_msvc"> +<div id="NPTM_tree_text_insert_timing_test_pat_trie"> +<div id="NPTM_assoc"> +<div id="NPTM_Native_tree_and_PATRICIA_trie_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPTM" id="NPTM"><img src="tree_text_insert_timing_test_pat_trie_msvc.png" alt="no image" /></a></h6>NPTM: Native tree and PATRICIA trie text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +pat_trie_map- +<a href="trie.html"><tt>trie</tt></a> + with <tt>Tag</tt> = <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_trie_node_update.html"><tt>null_trie_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NNTL_res_div"> +<div id="NNTL_local"> +<div id="NNTL_tree_text_insert_timing_test_node_tree"> +<div id="NNTL_assoc"> +<div id="NNTL_Native_tree_and_node-based_trees_text_insert_timing_test_using__tt_insert_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NNTL" id= "NNTL"><img src="tree_text_insert_timing_test_node_tree_local.png" alt="no image" /></a></h6>NNTL: Native tree and node-based trees text insert timing test using <tt>insert</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NVTL_res_div"> +<div id="NVTL_local"> +<div id="NVTL_tree_text_insert_timing_test_vector_tree"> +<div id="NVTL_assoc"> +<div id="NVTL_Native_tree_and_vector-based_tree_text_insert_timing_test_using__tt_insert_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NVTL" id= "NVTL"><img src="tree_text_insert_timing_test_vector_tree_local.png" alt="no image" /></a></h6>NVTL: Native tree and vector-based tree text insert timing test using <tt>insert</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NPTL_res_div"> +<div id="NPTL_local"> +<div id="NPTL_tree_text_insert_timing_test_pat_trie"> +<div id="NPTL_assoc"> +<div id="NPTL_Native_tree_and_PATRICIA_trie_text_insert_timing_test_using__tt_insert_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPTL" id= "NPTL"><img src="tree_text_insert_timing_test_pat_trie_local.png" alt="no image" /></a></h6>NPTL: Native tree and PATRICIA trie text insert timing test using <tt>insert</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>Observing Figure <a href="#NNTG">NNTG</a> , for this + setting, a splay tree, ( <a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> ) does + not do well. This was covered in <a href="tree_text_find_find_timing_test.html">Tree-Based and + Trie-Based Text <tt>find</tt> Find Timing Test</a> . The two + red-black trees perform better.</p> +<p>Observing Figure <a href="#NVTG">NVTG</a>, an ordered-vector + tree ( <a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>) performs + abysmally. Inserting into this type of tree has linear + complexity [ <a href="references.html#austern00noset">austern00noset</a>].</p> +<p>Observing Figure <a href="#NPTG">NPTG</a> , A PATRICIA trie + ( <a href="trie.html"><tt>trie</tt></a> + with <tt>Tag =</tt> <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a> ) has + abysmal performance, as well. This is not that surprising, + since a large-fan-out PATRICIA trie works like a hash table with + collisions resolved by a sub-trie. Each time a collision is + encountered, a new "hash-table" is built A large fan-out + PATRICIA trie, however, doe does well in look-ups (see <a href="tree_text_find_find_timing_test.html">Tree-Based and + Trie-Based Text <tt>find</tt> Find Timing Test</a> ). It is + possibly beneficial to semi-static settings, therefore.</p> +<p><a href="assoc_performance_tests.html#tree_like_based_types">Observations::Tree-Like-Based + Container Types</a> summarizes some observations on tree-based + and trie-based containers.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_gcc.png Binary files differnew file mode 100644 index 000000000..22d8f6fc2 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_local.png Binary files differnew file mode 100644 index 000000000..bb100084b --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_msvc.png Binary files differnew file mode 100644 index 000000000..18b219851 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_gcc.png Binary files differnew file mode 100644 index 000000000..5fe063e63 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_local.png Binary files differnew file mode 100644 index 000000000..228de1442 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_msvc.png Binary files differnew file mode 100644 index 000000000..9f13db0c0 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_gcc.png Binary files differnew file mode 100644 index 000000000..dd85dcd7c --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_local.png Binary files differnew file mode 100644 index 000000000..cecb8a107 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_msvc.png Binary files differnew file mode 100644 index 000000000..8c0731391 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_find_timing_test.html new file mode 100644 index 000000000..c577a56db --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_find_timing_test.html @@ -0,0 +1,126 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> +<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> +<title>Tree Text Locality of Reference Find Timing Test</title> +<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" /> +</head> +<body> +<div id="page"> +<h1>Tree-Based Locality-of-Reference Text <tt>find</tt> Find + Timing Test</h1> +<h2><a name="description" id="description">Description</a></h2> +<p>This test inserts a number of values with keys from an + arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into + a container, then performs a series of finds using + <tt>find</tt> . It is different than <a href="tree_text_find_find_timing_test.html">Tree-Based and + Trie-Based Text <tt>find</tt> Find Timing Test</a> in the + sequence of finds it performs: this test performs multiple + <tt>find</tt> s on the same key before moving on to the next + key. It measures the average time for <tt>find</tt> as a + function of the number of values inserted.</p> +<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/tree_text_lor_find_timing.cc"><tt>tree_text_lor_find_timing_test</tt></a> + thirty_years_among_the_dead_preproc.txt 200 200 2100)</p> +<h2><a name="purpose" id="purpose">Purpose</a></h2> +<p>The test checks the effect of different underlying + data structures in a locality-of-reference setting.</p> +<h2><a name="results" id="results">Results</a></h2> +<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and + <a href="#NTL">NTL</a> show the results for the native and + <tt>pb_ds</tt> tree-based types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a> and + <a href="assoc_performance_tests.html#local"><u>local</u></a>, + respectively.</p> +<div id="NTG_res_div"> +<div id="NTG_gcc"> +<div id="NTG_tree_text_lor_find_timing_test"> +<div id="NTG_assoc"> +<div id="NTG_Native_and_tree-based_locality-of-reference_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="tree_text_lor_find_timing_test_gcc.png" alt="no image" /></a></h6>NTG: Native and tree-based locality-of-reference text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +ov_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +rb_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +<li> +splay_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTM_res_div"> +<div id="NTM_msvc"> +<div id="NTM_tree_text_lor_find_timing_test"> +<div id="NTM_assoc"> +<div id="NTM_Native_and_tree-based_locality-of-reference_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="tree_text_lor_find_timing_test_msvc.png" alt="no image" /></a></h6>NTM: Native and tree-based locality-of-reference text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p> +<ol> +<li> +ov_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +rb_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +<li> +n_map- +<tt>std::map</tt></li> +<li> +splay_tree_map- +<a href="tree.html"><tt>tree</tt></a> + with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> +, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a> +</li> +</ol> +</div><div style="width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<div id="NTL_res_div"> +<div id="NTL_local"> +<div id="NTL_tree_text_lor_find_timing_test"> +<div id="NTL_assoc"> +<div id="NTL_Native_and_tree-based_locality-of-reference_text_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="tree_text_lor_find_timing_test_local.png" alt="no image" /></a></h6>NTL: Native and tree-based locality-of-reference text find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div> +</div> +</div> +</div> +</div> +<h2><a name="observations" id="observations">Observations</a></h2> +<p>For this setting, an ordered-vector tree ( <a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> ), a + red-black tree ( <a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>rb_tree_tag</tt></a> ), and the + native red-black tree all share approximately the same + performance.</p> +<p>A splay tree ( <a href="tree.html"><tt>tree</tt></a> + with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> ) does + much better, since each (successful) find "bubbles" the + corresponding node to the root of the tree.</p> +<p><a href="assoc_performance_tests.html#tree_like_based_types">Observations::Tree-Like-Based + Container Types</a> summarizes some observations on tree-based + and trie-based containers.</p> +</div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_gcc.png Binary files differnew file mode 100644 index 000000000..cf5174d99 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_gcc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_local.png Binary files differnew file mode 100644 index 000000000..26f71510f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_local.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_msvc.png Binary files differnew file mode 100644 index 000000000..583a027f3 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_msvc.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie.html new file mode 100644 index 000000000..32a2ab1b5 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie.html @@ -0,0 +1,489 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>trie Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>trie</tt> Interface</h1> + + <p>A concrete basic trie-based associative container.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Key2501" id="Key2501"><b>typename</b> Key</a> +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a> +</pre> + </td> + + <td> + <p>Mapped type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="E_Access_Traits686553840" id= +"E_Access_Traits686553840"><b>class</b> E_Access_Traits </a> +</pre> + </td> + + <td> + <p>Element-access traits.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Tag278938" id="Tag278938"><b>class</b> Tag </a> +</pre> + </td> + + <td> + <p>Data-structure tag.</p> + </td> + + <td><a href="pat_trie_tag.html"><span class= + "c2"><tt>pat_trie_tag</tt></span></a></td> + </tr> + + <tr> + <td> + <pre> +<a name="Node_Update841554648" id= +"Node_Update841554648"><b>template</b>< + <b>typename</b> Const_Node_Iterator, + <b>typename</b> Node_Iterator, + <b>class</b> E_Access_Traits_, + <b>typename</b> Allocator_> +<b>class</b> Node_Update </a> +</pre> + </td> + + <td> + <p>Node updater type.</p> + + <p><a href= + "tree_based_containers.html#invariants">Design::Tree-Based + Containers::Node Invariants</a> explains this + concept.</p> + </td> + + <td><a href="null_trie_node_update.html"><span class= + "c2"><tt>null_trie_node_update</tt></span></a></td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator </a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td> + <pre> +std::allocator<<b>char</b>> +</pre> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="e_access_traits1948190928" id= +"e_access_traits1948190928">e_access_traits</a> +</pre> + </td> + + <td> + <pre> +<a href="#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a> +</pre> + </td> + + <td> + <p>Element access traits type.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">Iterator Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_node_iterator4205924553" id= +"const_node_iterator4205924553">const_node_iterator</a> +</pre> + </td> + + <td> + <pre> +<a href= +"trie_const_node_iterator.html"><span class= +"c2"><tt>const_node_iterator</tt></span></a> +</pre> + </td> + + <td> + <p>Const node iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="node_iterator3431975247" id= +"node_iterator3431975247">node_iterator</a> +</pre> + </td> + + <td> + <pre> +<a href="trie_node_iterator.html"><span class= +"c2"><tt>node_iterator</tt></span></a> +</pre> + </td> + + <td> + <p>Node iterator.</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Public Methods</a></h2> + + <h3><a name="link6" id="link6">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> + trie + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> + trie + (<b>const</b> <a href= +"#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a> &r_e_access_traits) +</pre> + </td> + + <td> + <p>Constructor taking some policy objects. <span class= + "c1"><tt>r_e_access_traits</tt></span> will be copied by + the <a href= + "#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a> + object of the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + trie + (It first_it, + It last_it) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of + value_types. The value_types between <span class= + "c1"><tt>first_it</tt></span> and <span class= + "c1"><tt>last_it</tt></span> will be inserted into the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>template</b>< + <b>class</b> It> + trie + (It first_it, + It last_it, + <b>const</b> <a href= +"#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a> &r_e_access_traits) +</pre> + </td> + + <td> + <p>Constructor taking iterators to a range of value_types + and some policy objects. The value_types between + <span class="c1"><tt>first_it</tt></span> and + <span class="c1"><tt>last_it</tt></span> will be inserted + into the container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> + trie + (<b>const</b> <span class= +"c2"><tt>trie</tt></span> &other) +</pre> + </td> + + <td> + <p>Copy constructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~trie + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<span class="c2"><tt>trie</tt></span> & + <b>operator</b>= + (<b>const</b> <span class= +"c2"><tt>trie</tt></span> &other) +</pre> + </td> + + <td> + <p>Assignment operator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>void</b> + swap + (<span class= +"c2"><tt>trie</tt></span> &other) +</pre> + </td> + + <td> + <p>Swaps content.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Policy Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href= +"#e_access_traits1948190928"><tt>e_access_traits</tt></a> & + get_e_access_traits + () +</pre> + </td> + + <td> + <p>Access to the comb_hash_fn object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href= +"#e_access_traits1948190928"><tt>e_access_traits</tt></a> & + get_e_access_traits + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access to the comb_hash_fn object.</p> + </td> + </tr> + </table> + + <h3><a name="link8" id="link8">Node-Iteration Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="#node_iterator3431975247"><tt>node_iterator</tt></a> + node_begin + () +</pre> + </td> + + <td> + <p>Returns a <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + corresponding to the node at the root of the trie.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + node_begin + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + corresponding to the node at the root of the trie.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href="#node_iterator3431975247"><tt>node_iterator</tt></a> + node_end + () +</pre> + </td> + + <td> + <p>Returns a <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + corresponding to a node just after a leaf of the + trie.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + node_end + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns a <a href= + "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + corresponding to a node just after a leaf of the + trie.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_based_containers.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_based_containers.html new file mode 100644 index 000000000..72bdd0697 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_based_containers.html @@ -0,0 +1,241 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Trie-Based Containers</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Trie Design</h1> + + <h2><a name="overview" id="overview">Overview</a></h2> + + <p>The trie-based container has the following declaration:</p> + <pre> +<b>template</b>< + <b>typename</b> Key, + <b>typename</b> Mapped, + <b>typename</b> Cmp_Fn = std::less<Key>, + <b>typename</b> Tag = <a href="pat_trie_tag.html">pat_trie_tag</a>, + <b>template</b>< + <b>typename</b> Const_Node_Iterator, + <b>typename</b> Node_Iterator, + <b>typename</b> E_Access_Traits_, + <b>typename</b> Allocator_> + <b>class</b> Node_Update = <a href= +"null_trie_node_update.html">null_trie_node_update</a>, + <b>typename</b> Allocator = std::allocator<<b>char</b>> > +<b>class</b> <a href= +"trie.html">trie</a>; +</pre> + + <p>The parameters have the following meaning:</p> + + <ol> + <li><tt>Key</tt> is the key type.</li> + + <li><tt>Mapped</tt> is the mapped-policy, and is explained in + <a href="tutorial.html#assoc_ms">Tutorial::Associative + Containers::Associative Containers Others than Maps</a>.</li> + + <li><tt>E_Access_Traits</tt> is described in <a href= + "#e_access_traits">Element-Access Traits</a>.</li> + + <li><tt>Tag</tt> specifies which underlying data structure + to use, and is described shortly.</li> + + <li><tt>Node_Update</tt> is a policy for updating node + invariants. This is described in <a href="#invariants">Node + Invariants</a>.</li> + + <li><tt>Allocator</tt> is an allocator + type.</li> + </ol> + + <p>The <tt>Tag</tt> parameter specifies which underlying + data structure to use. Instantiating it by <a href= + "pat_trie_tag.html">pat_trie_tag</a>, specifies an + underlying PATRICIA trie (explained shortly); any other tag is + currently illegal.</p> + <hr /> + + <p>Following is a description of a (PATRICIA) trie + (<tt>pb_ds</tt> follows specifically [<a href= + "references.html#okasaki98mereable">okasaki98mereable</a>] and + [<a href= + "references.html#filliatre2000ptset">filliatre2000ptset</a>]).</p> + + <p>A (PATRICIA) trie is similar to a tree, but with the + following differences:</p> + + <ol> + <li>It explicitly views keys as a sequence of elements. + <i>E.g.</i>, a trie can view a string as a sequence of + characters; a trie can view a number as a sequence of + bits.</li> + + <li>It is not (necessarily) binary. Each node has fan-out <i>n + + 1</i>, where <i>n</i> is the number of distinct + elements.</li> + + <li>It stores values only at leaf nodes.</li> + + <li>Internal nodes have the properties that A) each has at + least two children, and B) each shares the same prefix with + any of its descendant.</li> + </ol> + + <p><a href="#e_access_traits">Element-Access Traits</a> shows + an example of such a trie.</p> + + <p>A (PATRICIA) trie has some useful properties:</p> + + <ol> + <li>It can be configured to use large node fan-out, giving it + very efficient find performance (albeit at insertion + complexity and size).</li> + + <li>It works well for common-prefix keys.</li> + + <li>It can support efficiently queries such as which keys + match a certain prefix. This is sometimes useful in + file systems and routers.</li> + </ol> + + <p>(We would like to thank Matt Austern for the suggestion to + include tries.)</p> + + <h2><a name="e_access_traits" id= + "e_access_traits">Element-Access Traits</a></h2> + + <p>A trie inherently views its keys as sequences of elements. + For example, a trie can view a string as a sequence of + characters. A trie needs to map each of <i>n</i> elements to a + number in <i>{0, n - 1}</i>. For example, a trie can map a + character <tt>c</tt> to + <tt>static_cast<size_t>(c)</tt>.</p> + + <p>Seemingly, then, a trie can assume that its keys support + (const) iterators, and that the <tt>value_type</tt> of this + iterator can be cast to a <tt>size_t</tt>. There are several + reasons, though, to decouple the mechanism by which the trie + accesses its keys' elements from the trie:</p> + + <ol> + <li>In some cases, the numerical value of an element is + inappropriate. Consider a trie storing DNA strings. It is + logical to use a trie with a fan-out of <i>5 = 1 + |{'A', 'C', + 'G', 'T'}|</i>. This requires mapping 'T' to 3, though.</li> + + <li>In some cases the keys' iterators are different than what + is needed. For example, a trie can be used to search for + common <u>suffixes</u>, by using strings' + <tt>reverse_iterator</tt>. As another example, a trie mapping + UNICODE strings would have a huge fan-out if each node would + branch on a UNICODE character; instead, one can define an + iterator iterating over 8-bit (or less) groups.</li> + </ol> + + <p><a href= + "trie.html">trie</a> is, + consequently, parametrized by <tt>E_Access_Traits</tt> - + traits which instruct how to access sequences' elements. + <a href= + "string_trie_e_access_traits.html"><tt>string_trie_e_access_traits</tt></a> + is a traits class for strings. Each such traits define some + types, <i>e.g.</i>,</p> + <pre> +<b>typename</b> E_Access_Traits::const_iterator +</pre> + + <p>is a const iterator iterating over a key's elements. The + traits class must also define methods for obtaining an iterator + to the first and last element of a key.</p> + + <p>Figure <a href="#pat_trie">A PATRICIA trie</a> shows a + (PATRICIA) trie resulting from inserting the words: "I wish + that I could ever see a poem lovely as a trie" (which, + unfortunately, does not rhyme).</p> + + <p>The leaf nodes contain values; each internal node contains + two <tt><b>typename</b> E_Access_Traits::const_iterator</tt> + objects, indicating the maximal common prefix of all keys in + the sub-tree. For example, the shaded internal node roots a + sub-tree with leafs "a" and "as". The maximal common prefix is + "a". The internal node contains, consequently, to const + iterators, one pointing to <tt>'a'</tt>, and the other to + <tt>'s'</tt>.</p> + + <h6 class="c1"><a name="pat_trie" id="pat_trie"><img src= + "pat_trie.png" alt="no image" /></a></h6> + + <h6 class="c1">A PATRICIA trie.</h6> + + <h2><a name="invariants" id="invariants">Node + Invariants</a></h2> + + <p>Trie-based containers support node invariants, as do + tree-based containers (see <a href= + "tree_based_containers.html#invariants">Tree-Based + Containers::Node Invariants</a>). There are two minor + differences, though, which, unfortunately, thwart sharing them + sharing the same node-updating policies:</p> + + <ol> + <li>A trie's <tt>Node_Update</tt> template-template + parameter is parametrized by <tt>E_Access_Traits</tt>, while + a tree's <tt>Node_Update</tt> template-template parameter is + parametrized by <tt>Cmp_Fn</tt>.</li> + + <li>Tree-based containers store values in all nodes, while + trie-based containers (at least in this implementation) store + values in leafs.</li> + </ol> + + <p>Figure <a href="#trie_node_update_cd">A trie and its update + policy</a> shows the scheme, as well as some predefined + policies (which are explained below).</p> + + <h6 class="c1"><a name="trie_node_update_cd" id= + "trie_node_update_cd"><img src= + "trie_node_update_policy_cd.png" alt="no image" /></a></h6> + + <h6 class="c1">A trie and its update policy.</h6> + + <p><tt>pb_ds</tt> offers the following pre-defined trie node + updating policies:</p> + + <ol> + <li><a href= + "trie_order_statistics_node_update.html"><tt>trie_order_statistics_node_update</tt></a> + supports order statistics.</li> + + <li><a href= + "trie_prefix_search_node_update.html"><tt>trie_prefix_search_node_update</tt></a> + supports searching for ranges that match a given prefix. See + <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/trie_prefix_search.cc"><tt>trie_prefix_search.cc</tt></a>.</li> + + <li><a href= + "null_trie_node_update.html"><tt>null_trie_node_update</tt></a> + is the null node updater.</li> + </ol> + + <h2><a name="add_methods" id="add_methods">Additional + Methods</a></h2> + + <p>Trie-based containers support split and join methods; the + rationale is equal to that of tree-based containers supporting + these methods (see <a href= + "tree_based_containers.html#add_methods">Tree-Based + Containers::Additional Methods</a>).</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_const_node_iterator.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_const_node_iterator.html new file mode 100644 index 000000000..0869a7c2f --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_const_node_iterator.html @@ -0,0 +1,478 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>trie::const_node_iterator + Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt><span class= + "c2"><tt>trie</tt></span>::const_node_iterator</tt> + Interface</h1> + + <p>Const node iterator.</p> + + <p>This is an "iterator to an iterator" - it iterates over + nodes, and de-referencing it returns one of the tree's const + iterators</p> + + <h2><a name="link1" id="link1">Public Types and + Constants</a></h2> + + <h3><a name="link2" id="link2">General Container + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<a href="container_base.html#size_type55424436"><span class= +"c2"><tt>container_base</tt></span>::size_type</a> +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h3><a name="link3" id="link3">Iterator Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="iterator_category2821876439" id= +"iterator_category2821876439">iterator_category</a> +</pre> + </td> + + <td> + <pre> +trivial_iterator_tag +</pre> + </td> + + <td> + <p>Category.</p> + + <p>This tag identifies that the iterator has none of the + STL's iterators' movement abilities.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="difference_type868028452" id= +"difference_type868028452">difference_type</a> +</pre> + </td> + + <td> + <pre class="c2"> +void +</pre> + </td> + + <td> + <p>Difference type.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">Value-Type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="value_type279018186" id= +"value_type279018186">value_type</a> +</pre> + </td> + + <td> + <pre> +<a href= +"container_base.html#const_iterator98626788"><span class="c2"><tt>container_base</tt></span>::const_iterator</a> +</pre> + </td> + + <td> + <p>Iterator's value type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="reference54418471" id="reference54418471">reference</a> +</pre> + </td> + + <td> + <pre> +<a href="#value_type279018186"><tt>value_type</tt></a> +</pre> + </td> + + <td> + <p>Iterator's reference type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_reference495461441" id= +"const_reference495461441">const_reference</a> +</pre> + </td> + + <td> + <pre> +<a href="#value_type279018186"><tt>value_type</tt></a> +</pre> + </td> + + <td> + <p>Iterator's const <a href= + "#reference54418471"><tt>reference</tt></a> type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="e_access_traits1948190928" id= +"e_access_traits1948190928">e_access_traits</a> +</pre> + </td> + + <td> + <pre> +<a href= +"trie.html#e_access_traits1948190928"><span class="c2"><tt>trie</tt></span>::e_access_traits</a> +</pre> + </td> + + <td> + <p>Element access traits.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_e_iterator2450008044" id= +"const_e_iterator2450008044">const_e_iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#e_access_traits1948190928"><tt>e_access_traits</tt></a>::const_iterator +</pre> + </td> + + <td> + <p>A key's element const iterator.</p> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Metadata Definitions</a></h3> + + <p>These are only defined if <a href= + "basic_tree.html#Node_Update841554648"><span class="c2"> + <tt>basic_tree</tt></span>::Node_Update</a> + is not <a href="null_trie_node_update.html"><span class= + "c2"><tt>null_trie_node_update</tt></span></a></p> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_type2849297114" id= +"metadata_type2849297114">metadata_type</a> +</pre> + </td> + + <td> + <pre> +<tt><b>typename</b></tt> <a href= +"basic_tree.html#Node_Update841554648"><span class="c2"><tt>basic_tree</tt></span>::Node_Update</a><tt>::metadata_type</tt> +</pre> + </td> + + <td> + <p>Metadata type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_metadata_reference1108857465" id= +"const_metadata_reference1108857465">const_metadata_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> Allocator::<b>template</b> rebind< + <a href= +"#metadata_type2849297114"><tt>metadata_type</tt></a>>::other::<a href="#const_reference495461441"><tt>const_reference</tt></a> +</pre> + </td> + + <td> + <p>Const metadata <a href= + "#reference54418471"><tt>reference</tt></a> type.</p> + </td> + </tr> + </table> + + <h2><a name="link6" id="link6">Public Methods</a></h2> + + <h3><a name="link7" id="link7">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> + const_node_iterator + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + </table> + + <h3><a name="link8" id="link8">Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> std::pair< + <a href= +"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a>, + <a href= +"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a>> + valid_prefix + () <b>const</b> +</pre> + </td> + + <td> + <p>Subtree valid prefix.</p> + + <p>Returns the common prefix range of all nodes in this + node's subtree.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"#const_reference495461441"><tt>const_reference</tt></a> + <b>operator</b>* + () <b>const</b> +</pre> + </td> + + <td> + <p>Const access; returns the const iterator associated + with the current leaf.</p> + + <p>Should be called only for leaf nodes.</p> + </td> + </tr> + </table> + + <h3><a name="link9" id="link9">Metadata Access Methods</a></h3> + + <p>These are only defined if <a href= + "basic_tree.html#Node_Update841554648"><span class="c2"> + <tt>basic_tree</tt></span>::Node_Update</a> + is not <a href="null_trie_node_update.html"><span class= + "c2"><tt>null_trie_node_update</tt></span></a></p> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"#const_metadata_reference1108857465"><tt>const_metadata_reference</tt></a> + get_metadata + () <b>const</b> +</pre> + </td> + + <td> + <p>Metadata access.</p> + </td> + </tr> + </table> + + <h3><a name="link10" id="link10">Movement Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + num_children + () <b>const</b> +</pre> + </td> + + <td> + <p>Returns the number of children in the corresponding + node.</p> + + <p>If the number of children is 0, then the corresponding + node is a leaf; otherwise, it is not a leaf.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<span class="c2"><tt>const_node_iterator</tt></span> + get_child + (<a href= +"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b> +</pre> + </td> + + <td> + <p>Returns a const node iterator to the corresponding + node's <span class="c1"><tt>i</tt></span>-th child.</p> + </td> + </tr> + </table> + + <h3><a name="link11" id="link11">Comparison Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + <b>operator</b>== + (<b>const</b> <span class= +"c2"><tt>const_node_iterator</tt></span> &other) <b>const</b> +</pre> + </td> + + <td> + <p>Compares content to a different iterator object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>bool</b> + <b>operator</b>!= + (<b>const</b> <span class= +"c2"><tt>const_node_iterator</tt></span> &other) <b>const</b> +</pre> + </td> + + <td> + <p>Compares content (negatively) to a different iterator + object.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_iterator.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_iterator.html new file mode 100644 index 000000000..55029c4cb --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_iterator.html @@ -0,0 +1,235 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>trie::node_iterator Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt><span class= + "c2"><tt>trie</tt></span>::node_iterator</tt> + Interface</h1> + + <p>Node iterator.</p> + + <p>This is an "iterator to an iterator" - it iterates over + nodes, and de-referencing it returns one of the tree's + iterators</p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href= +"trie.html#const_node_iterator4205924553"><span class="c2"><tt>trie</tt></span>::const_node_iterator</a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">General Container + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"trie.html#const_node_iterator4205924553"><span class="c2"><tt>trie</tt></span>::const_node_iterator</a>::size_type +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">Value-Type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="value_type279018186" id= +"value_type279018186">value_type</a> +</pre> + </td> + + <td> + <pre> +<a href="container_base.html#iterator10418194"><span class= +"c2"><tt>container_base</tt></span>::iterator</a> +</pre> + </td> + + <td> + <p>Iterator's value type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="reference54418471" id="reference54418471">reference</a> +</pre> + </td> + + <td> + <pre> +<a href="#value_type279018186"><tt>value_type</tt></a> +</pre> + </td> + + <td> + <p>Iterator's reference type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_reference495461441" id= +"const_reference495461441">const_reference</a> +</pre> + </td> + + <td> + <pre> +<a href="#value_type279018186"><tt>value_type</tt></a> +</pre> + </td> + + <td> + <p>Iterator's const <a href= + "#reference54418471"><tt>reference</tt></a> type.</p> + </td> + </tr> + </table> + + <h2><a name="link5" id="link5">Public Methods</a></h2> + + <h3><a name="link6" id="link6">Constructors, Destructor, and + Related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> + pat_trie_node_it_ + () +</pre> + </td> + + <td> + <p>Default constructor.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Access Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#reference54418471"><tt>reference</tt></a> + <b>operator</b>* + () <b>const</b> +</pre> + </td> + + <td> + <p>Access; returns the iterator associated with the + current leaf.</p> + + <p>Should be called only for leaf nodes.</p> + </td> + </tr> + </table> + + <h3><a name="link8" id="link8">Movement Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<span class="c2"><tt>node_iterator</tt></span> + get_child + (<a href= +"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b> +</pre> + </td> + + <td> + <p>Returns a node iterator to the corresponding node's + <span class="c1"><tt>i</tt></span>-th child.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_updator_policy_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_updator_policy_cd.png Binary files differnew file mode 100644 index 000000000..4376929ec --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_updator_policy_cd.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_order_statistics_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_order_statistics_node_update.html new file mode 100644 index 000000000..66aab26d7 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_order_statistics_node_update.html @@ -0,0 +1,770 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>trie_order_statistics_node_update Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>trie_order_statistics_node_update</tt> Interface</h1> + + <p>Functor updating ranks of entrees.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/trie_policy.hpp"><tt>trie_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Const_Node_Iterator1933878761" id= +"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a> +</pre> + </td> + + <td> + <p>Const node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Node_Iterator4206909839" id= +"Node_Iterator4206909839"><b>class</b> Node_Iterator</a> +</pre> + </td> + + <td> + <p>Node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="E_Access_Traits686553840" id= +"E_Access_Traits686553840"><b>class</b> E_Access_Traits</a> +</pre> + </td> + + <td> + <p>Comparison functor.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator</a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td>-</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="e_access_traits1948190928" id= +"e_access_traits1948190928">e_access_traits</a> +</pre> + </td> + + <td> + <pre> +<a href="#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a> +</pre> + </td> + + <td> + <p>Element access traits.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_e_iterator2450008044" id= +"const_e_iterator2450008044">const_e_iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#e_access_traits1948190928"><tt>e_access_traits</tt></a>::const_iterator +</pre> + </td> + + <td> + <p>Const element iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="allocator48440069" id="allocator48440069">allocator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Allocator35940069"><tt>Allocator</tt></a> +</pre> + </td> + + <td> + <p><a href="#Allocator35940069"><tt>Allocator</tt></a> + type.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::size_type +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">Key-Type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="key_type10393186" id="key_type10393186">key_type</a> +</pre> + </td> + + <td> + <pre> +The instantiating container's key type. +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_key_reference3185471705" id= +"const_key_reference3185471705">const_key_reference</a> +</pre> + </td> + + <td> + <pre> +The instantiating container's const key reference type. +</pre> + </td> + + <td> + <p>Const key reference.</p> + </td> + </tr> + </table> + + <h3><a name="link6" id="link6">Metadata-Type + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_type2849297114" id= +"metadata_type2849297114">metadata_type</a> +</pre> + </td> + + <td> + <pre> +<a href="#size_type55424436"><tt>size_type</tt></a> +</pre> + </td> + + <td> + <p>Metadata type.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Iterator Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_node_iterator4205924553" id= +"const_node_iterator4205924553">const_node_iterator</a> +</pre> + </td> + + <td> + <pre> +<a href= +"#Const_Node_Iterator1933878761"><tt>Const_Node_Iterator</tt></a> +</pre> + </td> + + <td> + <p>Const node iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="node_iterator3431975247" id= +"node_iterator3431975247">node_iterator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Node_Iterator4206909839"><tt>Node_Iterator</tt></a> +</pre> + </td> + + <td> + <p>Node iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_iterator98626788" id= +"const_iterator98626788">const_iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>::value_type +</pre> + </td> + + <td> + <p>Const iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="iterator10418194" id="iterator10418194">iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a>::value_type +</pre> + </td> + + <td> + <p>Iterator type.</p> + </td> + </tr> + </table> + + <h2><a name="link8" id="link8">Public Methods</a></h2> + + <h3><a name="link9" id="link9">Find-Type Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a> + find_by_order + (<a href= +"#size_type55424436"><tt>size_type</tt></a> order) <b>const</b> +</pre> + </td> + + <td> + <p>Finds an entry by order. Returns a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> to + the entry with the order <span class= + "c1"><tt>order</tt></span>, or a <a href= + "#const_iterator98626788"><tt>const_iterator</tt></a> to + the container object's end if <span class= + "c1"><tt>order</tt></span> is at least the size of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#iterator10418194"><tt>iterator</tt></a> + find_by_order + (<a href="#size_type55424436"><tt>size_type</tt></a> order) +</pre> + </td> + + <td> + <p>Finds an entry by order. Returns an <a href= + "#iterator10418194"><tt>iterator</tt></a> to the entry + with the order <span class="c1"><tt>order</tt></span>, or + an <a href="#iterator10418194"><tt>iterator</tt></a> to + the container object's end if <span class= + "c1"><tt>order</tt></span> is at least the size of the + container object.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + order_of_key + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b> +</pre> + </td> + + <td> + <p>Returns the order of a key within a sequence. For + example, if <span class="c1"><tt>r_key</tt></span> is the + smallest key, this method will return 0; if <span class= + "c1"><tt>r_key</tt></span> is a key between the smallest + and next key, this method will return 1; if <span class= + "c1"><tt>r_key</tt></span> is a key larger than the + largest key, this method will return the size of r_c.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a> + order_of_prefix + (<a href= +"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> b, + <a href= +"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> e) <b>const</b> +</pre> + </td> + + <td> + <p>Returns the order of a prefix within a sequence. For + <span class="c1"><tt>e</tt></span>example, if [b, + <span class="c1"><tt>e</tt></span>] is the smallest + prefix, this method will return 0; if r_key is a key + <span class="c1"><tt>b</tt></span>between the smallest and + next key, this method will return 1; if r_key is a key + larger than the largest key, this method will return the + size of r_c.</p> + </td> + </tr> + </table> + + <h2><a name="link10" id="link10">Protected Types and + Constants</a></h2> + + <h3><a name="link11" id="link11">Value-Type + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_reference495461441" id= +"const_reference495461441">const_reference</a> +</pre> + </td> + + <td> + <pre> +The instantiating container's const reference type. +</pre> + </td> + + <td> + <p>Const reference to the container's value-type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_pointer878814947" id= +"const_pointer878814947">const_pointer</a> +</pre> + </td> + + <td> + <pre> +The instantiating container's const pointer type. +</pre> + </td> + + <td> + <p>Const pointer to the container's value-type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_metadata_reference1108857465" id= +"const_metadata_reference1108857465">const_metadata_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind< + <a href= +"#metadata_type2849297114"><tt>metadata_type</tt></a>>::other::<a href="#const_reference495461441"><tt>const_reference</tt></a> +</pre> + </td> + + <td> + <p>Const metadata reference.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_reference583863863" id= +"metadata_reference583863863">metadata_reference</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind< + <a href= +"#metadata_type2849297114"><tt>metadata_type</tt></a>>::other::reference +</pre> + </td> + + <td> + <p>Metadata reference.</p> + </td> + </tr> + </table> + + <h2><a name="link12" id="link12">Protected Methods</a></h2> + + <h3><a name="link13" id="link13">Operators</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + <b>operator</b>() + (<a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a> node_it, + <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> end_nd_it) <b>const</b> +</pre> + </td> + + <td> + <p>Updates the rank of a node through a <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + <span class="c1"><tt>node_it</tt></span>; <span class= + "c1"><tt>end_nd_it</tt></span> is the end node <a href= + "#iterator10418194"><tt>iterator</tt></a>.</p> + </td> + </tr> + </table> + + <h3><a name="link14" id="link14">Constructors, destructor, and + related</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> + ~trie_order_statistics_node_update + () +</pre> + </td> + + <td> + <p>Destructor.</p> + </td> + </tr> + </table> + + <h2><a name="link15" id="link15">Private Methods</a></h2> + + <h3><a name="link16" id="link16">Overrides</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <b>bool</b> + empty + () <b>const</b> = 0 +</pre> + </td> + + <td> + <p>Returns <tt><b>true</b></tt> if the container is + empty.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href="#iterator10418194"><tt>iterator</tt></a> + begin + () = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#iterator10418194"><tt>iterator</tt></a> associated with + the trie's first element.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href="#iterator10418194"><tt>iterator</tt></a> + end + () = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#iterator10418194"><tt>iterator</tt></a> associated with + the trie's just-after-last element.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + node_begin + () <b>const</b> = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + associated with the trie's root node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a> + node_begin + () = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + associated with the trie's root node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + node_end + () <b>const</b> = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + associated with a just-after leaf node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a> + node_end + () = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + associated with a just-after leaf node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#e_access_traits1948190928"><tt>e_access_traits</tt></a> & + get_e_access_traits + () = 0 +</pre> + </td> + + <td> + <p>Access to the cmp_fn object.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_prefix_search_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_prefix_search_node_update.html new file mode 100644 index 000000000..e136495c5 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_prefix_search_node_update.html @@ -0,0 +1,628 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>trie_prefix_search_node_update Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>trie_prefix_search_node_update</tt> Interface</h1> + + <p>A node updater that allows tries to be searched for the + range of values that match a certain prefix.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/trie_policy.hpp"><tt>trie_policy.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Template Parameters</a></h2> + + <table class="c1" width="100%" border="1" summary= + "Template Parameters"> + <tr> + <td width="20%" align="left"><b>Parameter</b></td> + + <td width="50%" align="left"><b>Description</b></td> + + <td width="30%" align="left"><b>Default Value</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="Const_Node_Iterator1933878761" id= +"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a> +</pre> + </td> + + <td> + <p>Const node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Node_Iterator4206909839" id= +"Node_Iterator4206909839"><b>class</b> Node_Iterator</a> +</pre> + </td> + + <td> + <p>Node iterator type.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="E_Access_Traits686553840" id= +"E_Access_Traits686553840"><b>class</b> E_Access_Traits</a> +</pre> + </td> + + <td> + <p>Comparison functor.</p> + </td> + + <td>-</td> + </tr> + + <tr> + <td> + <pre> +<a name="Allocator35940069" id= +"Allocator35940069"><b>class</b> Allocator</a> +</pre> + </td> + + <td> + <p>Allocator type.</p> + </td> + + <td>-</td> + </tr> + </table> + + <h2><a name="link2" id="link2">Public Types and + Constants</a></h2> + + <h3><a name="link3" id="link3">Key-Type Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="key_type10393186" id="key_type10393186">key_type</a> +</pre> + </td> + + <td> + <pre> +The instantiating container's key type. +</pre> + </td> + + <td> + <p>Key type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_key_reference3185471705" id= +"const_key_reference3185471705">const_key_reference</a> +</pre> + </td> + + <td> + <pre> +The instantiating container's const key reference type. +</pre> + </td> + + <td> + <p>Const key reference.</p> + </td> + </tr> + </table> + + <h3><a name="link4" id="link4">Policy Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="e_access_traits1948190928" id= +"e_access_traits1948190928">e_access_traits</a> +</pre> + </td> + + <td> + <pre> +<a href="#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a> +</pre> + </td> + + <td> + <p>Element access traits.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_e_iterator2450008044" id= +"const_e_iterator2450008044">const_e_iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#e_access_traits1948190928"><tt>e_access_traits</tt></a>::const_iterator +</pre> + </td> + + <td> + <p>Const element iterator.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="allocator48440069" id="allocator48440069">allocator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Allocator35940069"><tt>Allocator</tt></a> +</pre> + </td> + + <td> + <p><a href="#Allocator35940069"><tt>Allocator</tt></a> + type.</p> + </td> + </tr> + </table> + + <h3><a name="link5" id="link5">General Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="size_type55424436" id="size_type55424436">size_type</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#allocator48440069"><tt>allocator</tt></a>::size_type +</pre> + </td> + + <td> + <p>Size type.</p> + </td> + </tr> + </table> + + <h3><a name="link6" id="link6">Metadata-Type + Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="metadata_type2849297114" id= +"metadata_type2849297114">metadata_type</a> +</pre> + </td> + + <td> + <pre> +__gnu_pbds::detail::null_node_metadata +</pre> + </td> + + <td> + <p>Metadata type.</p> + </td> + </tr> + </table> + + <h3><a name="link7" id="link7">Iterator Definitions</a></h3> + + <table class="c1" width="100%" border="1" summary="Types"> + <tr> + <td width="30%" align="left"><b>Type</b></td> + + <td width="55%" align="left"><b>Definition</b></td> + + <td width="15%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<a name="const_node_iterator4205924553" id= +"const_node_iterator4205924553">const_node_iterator</a> +</pre> + </td> + + <td> + <pre> +<a href= +"#Const_Node_Iterator1933878761"><tt>Const_Node_Iterator</tt></a> +</pre> + </td> + + <td> + <p>Const node iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="node_iterator3431975247" id= +"node_iterator3431975247">node_iterator</a> +</pre> + </td> + + <td> + <pre> +<a href="#Node_Iterator4206909839"><tt>Node_Iterator</tt></a> +</pre> + </td> + + <td> + <p>Node iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="const_iterator98626788" id= +"const_iterator98626788">const_iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>::value_type +</pre> + </td> + + <td> + <p>Const iterator type.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<a name="iterator10418194" id="iterator10418194">iterator</a> +</pre> + </td> + + <td> + <pre> +<b>typename</b> <a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a>::value_type +</pre> + </td> + + <td> + <p>Iterator type.</p> + </td> + </tr> + </table> + + <h2><a name="link8" id="link8">Public Methods</a></h2> + + <h3><a name="link9" id="link9">Find Methods</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +std::pair< + <a href="#const_iterator98626788"><tt>const_iterator</tt></a>, + <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a>> + prefix_range + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b> +</pre> + </td> + + <td> + <p>Finds the <tt><b>const</b></tt> <a href= + "#iterator10418194"><tt>iterator</tt></a> range + corresponding to all values whose prefixes match + <span class="c1"><tt>r_key</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +std::pair< + <a href="#iterator10418194"><tt>iterator</tt></a>, + <a href="#iterator10418194"><tt>iterator</tt></a>> + prefix_range + (<a href= +"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) +</pre> + </td> + + <td> + <p>Finds the <a href= + "#iterator10418194"><tt>iterator</tt></a> range + corresponding to all values whose prefixes match + <span class="c1"><tt>r_key</tt></span>.</p> + </td> + </tr> + + <tr> + <td> + <pre> +std::pair< + <a href="#const_iterator98626788"><tt>const_iterator</tt></a>, + <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a>> + prefix_range + (<a href= +"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> b, + <a href= +"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> e) <b>const</b> +</pre> + </td> + + <td> + <p>Finds the <tt><b>const</b></tt> <a href= + "#iterator10418194"><tt>iterator</tt></a> range + corresponding to all values whose prefixes match [b, + <span class="c1"><tt>e</tt></span>).</p> + </td> + </tr> + + <tr> + <td> + <pre> +std::pair< + <a href="#iterator10418194"><tt>iterator</tt></a>, + <a href="#iterator10418194"><tt>iterator</tt></a>> + prefix_range + (<a href= +"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> b, + <a href= +"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> e) +</pre> + </td> + + <td> + <p>Finds the <a href= + "#iterator10418194"><tt>iterator</tt></a> range + corresponding to all values whose prefixes match [b, + <span class="c1"><tt>e</tt></span>).</p> + </td> + </tr> + </table> + + <h2><a name="link10" id="link10">Protected Methods</a></h2> + + <h3><a name="link11" id="link11">Operators</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>inline</b> <b>void</b> + <b>operator</b>() + (<a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a> node_it, + <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> end_nd_it) <b>const</b> +</pre> + </td> + + <td> + <p>Called to update a node's metadata.</p> + </td> + </tr> + </table> + + <h2><a name="link12" id="link12">Private Methods</a></h2> + + <h3><a name="link13" id="link13">Overrides</a></h3> + + <table class="c1" width="100%" border="1" summary="Methods"> + <tr> + <td width="45%" align="left"><b>Method</b></td> + + <td width="55%" align="left"><b>Description</b></td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#const_iterator98626788"><tt>const_iterator</tt></a> + end + () <b>const</b> = 0 +</pre> + </td> + + <td> + <p>Returns the <tt><b>const</b></tt> <a href= + "#iterator10418194"><tt>iterator</tt></a> associated with + the just-after last element.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href="#iterator10418194"><tt>iterator</tt></a> + end + () = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#iterator10418194"><tt>iterator</tt></a> associated with + the just-after last element.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + node_begin + () <b>const</b> = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + associated with the trie's root node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a> + node_begin + () = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + associated with the trie's root node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + node_end + () <b>const</b> = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> + associated with a just-after leaf node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <a href= +"#node_iterator3431975247"><tt>node_iterator</tt></a> + node_end + () = 0 +</pre> + </td> + + <td> + <p>Returns the <a href= + "#node_iterator3431975247"><tt>node_iterator</tt></a> + associated with a just-after leaf node.</p> + </td> + </tr> + + <tr> + <td> + <pre> +<b>virtual</b> <b>const</b> <a href= +"#e_access_traits1948190928"><tt>e_access_traits</tt></a> & + get_e_access_traits + () <b>const</b> = 0 +</pre> + </td> + + <td> + <p>Access to the cmp_fn object.</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_tag.html new file mode 100644 index 000000000..62bf12454 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_tag.html @@ -0,0 +1,47 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>trie_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>trie_tag</tt> Interface</h1> + + <p>Basic trie data structure tag.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + + <h2><a name="link1" id="link1">Base Classes</a></h2> + + <table class="c1" width="100%" border="1" summary="Bases"> + <tr> + <td width="80%" align="left"><b>Class</b></td> + + <td width="20%" align="left"><b>Derivation Type</b></td> + </tr> + + <tr> + <td> + <pre> +<a href="basic_tree_tag.html"><span class= +"c2"><tt>basic_tree_tag</tt></span></a> +</pre> + </td> + + <td> + <p>public</p> + </td> + </tr> + </table> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trivial_iterator_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trivial_iterator_tag.html new file mode 100644 index 000000000..1f59c5102 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trivial_iterator_tag.html @@ -0,0 +1,25 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>trivial_iterator_tag Interface</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1><tt>trivial_iterator_tag</tt> Interface</h1> + + <p>A \quot;trivial\quot; iterator tag. Signifies that the + iterators has none of the STL's movement abilities.</p> + + <p>Defined in: <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tutorial.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tutorial.html new file mode 100644 index 000000000..152cd57b1 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tutorial.html @@ -0,0 +1,670 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + +<html xmlns="http://www.w3.org/1999/xhtml"> +<head> + <meta name="generator" content= + "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" /> + + <title>Tutorial</title> + <meta http-equiv="Content-Type" content= + "text/html; charset=us-ascii" /> + </head> + +<body> + <div id="page"> + <h1>Short Tutorial</h1> + + <p>Following is a short tutorial illustrating the main points + of <tt>pb_ds</tt>. <a href="concepts.html">Concepts</a> + describes and summarizes some concepts.</p> + + <h2><a name="assoc_main" id="assoc_main">Associative + Containers</a></h2> + + <h3><a name="assoc_basic" id="assoc_basic">Basic Use</a></h3> + + <p>For the most part, <tt>pb_ds</tt>'s containers have the same + interface as the STL's, except for the names used for the + container classes themselves. For example, this shows basic + operations on a collision-chaining hash-based container:</p> + + <pre> +<a href= +"cc_hash_table.html">cc_hash_table</a><<b>int</b>, <b>char</b>> c; + +c[2] = 'b'; + +assert(c.find(1) == c.end()); +</pre> + + <p>The container is called <a href= + "cc_hash_table.html"><tt>cc_hash_table</tt></a> as + opposed to <tt>unordered_map</tt>, since "unordered map" does + not necessarily mean a hash-based map (as the STL implicitly + implies). For example, list-based associative containers, which + are very useful for the construction of "multimaps" (see + <a href= + "assoc_performance_tests.html#msc">Associative-Container + Performance Tests::Observations::Mapping-Semantics + Considerations</a>), are also unordered. It is also not called + <tt>hash_map</tt> since there are more ways than one to + implement hash tables.</p> + + <p>This snippet shows a red-black tree based container:</p> + <pre> +<a href= +"tree.html">tree</a><<b>int</b>, <b>char</b>> c; + +c[2] = 'b'; + +assert(c.find(2) != c.end()); +</pre> + + <p>The container is called <a href= + "tree.html"><tt>tree</tt></a> + as opposed to <tt>map</tt>, since "map" doesn't say that + much.</p> + + <p>Most of the STL's familiar methods are unchanged. + <i>E.g.</i>, <tt>being</tt>, <tt>end</tt>, <tt>size</tt>, + <tt>empty</tt>, and <tt>clear</tt>, do just the same as is + customary. <a href= + "assoc_examples.html#basic_usage">Associative-Container + Examples::Basic use</a>, and especially <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_map.cc"><tt>basic_map.cc</tt></a>, + show examples of this.</p> + +<p>This isn't to say that things are exactly as one would expect, +given the container requirments and interfaces in the C++ +standard.</p> + + + <p>The names of containers' policies and policy accessors are + different than those of the STL. For example, if <tt>C</tt> is + some type of hash-based container, then</p> + <pre> +C::hash_fn +</pre>gives the type of its hash functor, and if <tt>c</tt> is some +hash-based container object, then + <pre> +c.get_hash_fn() +</pre> + + <p>will return a reference to its hash-functor object.</p> + + <p>Similarly, if <tt>C</tt> is some type of tree-based + container, then</p> + <pre> +C::cmp_fn +</pre>gives the type of its comparison functor, and if <tt>c</tt> +is some tree-based container object, then + <pre> +c.get_cmp_fn() +</pre> + + <p>will return a reference to its comparison-functor + object.</p> + + <p>It would be nice to give names consistent with those in the + existing C++ standard (inclusive of TR1). Unfortunately, these + standard containers don't consistently name types and + methods. For example, <tt>std::tr1::unordered_map</tt> uses + <tt>hasher</tt> for the hash functor, but <tt>std::map</tt> uses + <tt>key_compare</tt> for the comparison functor. Also, we could + not find an accessor for <tt>std::tr1::unordered_map</tt>'s hash + functor, but <tt>std::map</tt> uses <tt>compare</tt> for accessing + the comparison functor.</p> + +<p>Instead, <tt>pb_ds</tt> attempts to be internally consistent, and +uses standard-derived terminology if possible. +</p> + + <p>Another source of difference is in scope: <tt>pb_ds</tt> + contains more types of associative containers than the STL, and + more opportunities to configure these new containers, since + different types of associative containers are useful in different + settings (see <a href= + "assoc_performance_tests.html#dss_family_choice">Associative-Container + Performance Tests::Observations::Underlying Data-Structure + Families</a>).</p> + + <p><tt>pb_ds</tt> contains different classes for hash-based containers, + tree-based containers, trie-based containers, and list-based + containers. <a href= + "interface.html#containers_assoc">Inteface::Containers::Associative + Containers</a> lists the containers. <a href= + "hash_based_containers.html">Design::Associative + Containers::Hash-Based Containers</a>, <a href= + "tree_based_containers.html">Design::Associative + Containers::Tree-Based Containers</a>, <a href= + "trie_based_containers.html">Design::Associative + Containers::Trie-Based Containers</a>, and <a href= + "lu_based_containers.html">Design::Associative + Containers::List-Based Containers</a>, explain some more about + these types of containers, respectively.</p> + + <p>Since associative containers share parts of their interface, + they are organized as a class hierarchy; it is shown in Figure + <a href="#cd">Class hierarchy</a>.</p> + + <h6 class="c1"><a name="cd" id="cd"><img src="container_cd.png" alt= + "no image" /></a></h6> + + <h6 class="c1">Class hierarchy.</h6> + + <p>Each type or method is defined in the most-common ancestor + in which it makes sense: + <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_map.cc"><tt>basic_map.cc</tt></a> + shows an example of most of the associative-container + types.</p> + + + <p>For example, all associative containers support iteration. + Consequently, <a href= + "container_base.html"><tt>container_base</tt></a> has the + interface:</p> + <pre> +<b>template</b><...> +<b>class</b> <a href="container_base.html">container_base</a> +{ + ... + +<b>public</b>: + ... + + const_iterator + begin() <b>const</b>; + + iterator + begin(); + + const_iterator + end() <b>const</b>; + + iterator + end(); + + ... +}; +</pre> + + <p>and so all associative containers inherent this method. + Conversely, both collision-chaining and (general) probing + hash-based associative containers have a hash functor, so + <a href= + "basic_hash_table.html"><tt>basic_hash_table</tt></a> + has the interface:</p> + <pre> +<b>template</b><...> +<b>class</b> <a href="basic_hash_table.html">basic_hash_table</a> : <b>public</b> <a href="container_base.html">container_base</a> +{ + ... + +<b>public</b>: + ... + + const hash_fn& + get_hash_fn() const; + + hash_fn& + get_hash_fn(); + ... +}; +</pre> + + <p>and so all hash-based associative containers inherit the + same hash-functor accessor methods.</p> + + <p>This is discussed further in <a href= + "ds_gen.html">Design::Associative Containers::Data-Structure + Genericity</a>.</p> + + <h3><a name="assoc_policies" id="assoc_policies">Configuring + Associative Containers</a></h3> + + <p>In general, each of <tt>pb_ds</tt>'s containers is + parametrized by more policies than those of the STL's. For + example, the STL's hash-based container is parametrized as + follows:</p> + <pre> +<b>template</b>< + <b>typename</b> Key, + <b>typename</b> Mapped, + <b>typename</b> Hash, + <b>typename</b> Pred, + <b>typename</b> Allocator, + <b>bool</b> Cache_Hashe_Code> +<b>class</b> unordered_map; +</pre> + + <p>and so can be configured by key type, mapped type, a functor + that translates keys to unsigned integral types, an equivalence + predicate, an allocator, and an indicator whether to store hash + values with each entry. <tt>pb_ds</tt>'s collision-chaining + hash-based container is parametrized as</p> + <pre> +<b>template</b>< + <b>typename</b> Key, + <b>typename</b> Mapped, + <b>typename</b> Hash_Fn, + <b>typename</b> Eq_Fn, + <b>typename</b> Comb_Hash_Fn, + <b>typename</b> Resize_Policy + <b>bool</b> Store_Hash + <b>typename</b> Allocator> +<b>class</b> <a href= +"cc_hash_table.html">cc_hash_table</a>; +</pre> + + <p>and so can be configured by the first four types of + <tt>std::tr1::unordered_map</tt>, then a policy for translating + the key-hash result into a position within the table, then a + policy by which the table resizes, an indicator whether to + store hash values with each entry, and an allocator (which is + typically the last template parameter in STL containers).</p> + + <p>Nearly all policy parameters have default values, so this + need not be considered for casual use. It is important to note, + however, that hash-based containers' policies can dramatically + alter their performance in different settings, and that + tree-based containers' policies can make them useful for other + purposes than just look-up.</p> + + <p><a href="hash_based_containers.html">Design::Associative + Containers::Hash-Based Containers</a>, <a href= + "tree_based_containers.html">Design::Associative + Containers::Tree-Based Containers</a>, <a href= + "trie_based_containers.html">Design::Associative + Containers::Trie-Based Containers</a>, and <a href= + "lu_based_containers.html">Design::Associative + Containers::List-Based Containers</a>, explain some more about + configuring hash based, tree based, trie based, and list base + containers, respectively. <a href= + "interface.html#ds_policy_classes">Interface::Container Policy + Classes</a> shows the different policy classes for configuring + associative containers. <a href= + "assoc_examples.html#hash_based">Examples::Hash-Based + Containers</a>, <a href= + "assoc_examples.html#tree_like_based">Examples::Tree-Like-Based + Containers</a>, and <a href= + "assoc_examples.html#trie_based">Examples::Trie-Based + Containers</a> show examples for this.</p> + + <h3><a name="assoc_ds_gen" id="assoc_ds_gen">Determining + Containers' Attributes</a></h3> + + <p>Associative-containers' underlying data structures obviously + affect their performance; Unfortunately, they can also affect + their interface. When manipulating generically associative + containers, it is often useful to be able to statically + determine what they can support and what the cannot. (This was + discussed in <a href= + "motivation.html#assoc_ds_genericity">Motivation::Associative + Containers::Data-Structure Genericity</a>.)</p> + + <p>Happily, the STL provides a good solution to a similar + problem - that of the different behavior of iterators. If + <tt>It</tt> is an iterator, then</p> + <pre> +<b>typename</b> std::iterator_traits<It>::iterator_category +</pre> + + <p>is one of a small number of pre-defined + <tt><b>struct</b></tt>s, and,</p> + <pre> +<b>typename</b> std::iterator_traits<It>::value_type +</pre> + + <p>is the value type to which the iterator "points".</p> + + <p>Similarly, in <tt>pb_ds</tt>, if <tt>C</tt> is an + associative container, then</p> + <pre> +<b>typename</b> <a href= +"assoc_container_traits.html"><tt>container_traits</tt></a><C>::container_category +</pre>is one of a small number of pre-defined +<tt><b>struct</b></tt>s, each one corresponding to a class in +Figure <a href="#cd">Class hierarchy</a>. These tags are listed in +<a href="interface.html#ds_ts_assoc">Interface::Associative +Containers::Data-Structure Tags and Traits::Data-Structure +Tags::Associative-Containers</a>; <a href="ds_gen.html#container_traits"> + Design::Associative Containers::Data-Structure Tags and + Traits</a> explains this further; <a href= + "ds_gen.html#tag_cd">Design::Associative + Containers::Data-Structure Tags and Traits::Data-structure tag + class hierarchy</a> shows a class diagram. + + <p>In most cases, however, the exact underlying data structure + is not really important, but only one of its attributes: + whether it guarantees storing elements by key order, for + example. For this one can use</p> + <pre> +<b>typename</b> <a href= +"assoc_container_traits.html"><tt>container_traits</tt></a><C>::order_preserving +</pre> + + <p>This is described further in <a href= + "ds_gen.html">Design::Data-Structure Genericity</a>; <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/assoc_container_traits.cc"><tt>assoc_container_traits.cc</tt></a> + shows an example of querying containers' attributes.</p> + + <h3><a name="assoc_find_range" id="assoc_find_range">Point-Type + and Range-Type Methods and Iterators</a></h3>(This subsection + addresses points from <a href= + "motivation.html#assoc_diff_it">Motivation::Associative + Containers::Differentiating between Iterator Types</a>.) + + <p><tt>pb_ds</tt> differentiates between two types of methods + and iterators: point-type, and range-type. For example, + <tt>find</tt> and <tt>insert</tt> are point-type methods, since + they each deal with a specific element; their returned + iterators are point-type iterators. <tt>begin</tt> and + <tt>end</tt> are range-type methods, since they are not used to + find a specific element, but rather to go over all elements in + a container object; their returned iterators are range-type + iterators.</p> + + <p>Most containers store elements in an order that is + determined by their interface. Correspondingly, it is fine that + their point-type iterators are synonymous with their range-type + iterators. For example, in the following snippet</p> + <pre> +std::for_each(c.find(1), c.find(5), foo); +</pre>two point-type iterators (returned by <tt>find</tt>) are used +for a range-type purpose - going over all elements whose key is +between 1 and 5. + + <p>Conversely, the above snippet makes no sense for + self-organizing containers - ones that order (and reorder) + their elements by implementation. It would be nice to have a + uniform iterator system that would allow the above snippet to + compile only if it made sense.</p> + + <p>This could trivially be done by specializing + <tt>std::for_each</tt> for the case of iterators returned by + <tt>std::tr1::unordered_map</tt>, but this would only solve the + problem for one algorithm and one container. Fundamentally, the + problem is that one can loop using a self-organizing + container's point-type iterators.</p> + + <p><tt>pb_ds</tt>'s containers define two families of + iterators: <tt>const_point_iterator</tt> and + <tt>point_iterator</tt> are the iterator types returned by + point-type methods; <tt>const_iterator</tt> and + <tt>iterator</tt> are the iterator types returned by range-type + methods.</p> + <pre> +<b>class</b> <i><- some container -></i> +{ +<b>public</b>: + ... + + <b>typedef</b> <i><- something -></i> const_iterator; + + <b>typedef</b> <i><- something -></i> iterator; + + <b>typedef</b> <i><- something -></i> const_point_iterator; + + <b>typedef</b> <i><- something -></i> point_iterator; + + ... + +<b>public</b>: + ... + + const_iterator begin () <b>const</b>; + + iterator begin(); + + const_point_iterator find(...) <b>const</b>; + + point_iterator find(...); +}; +</pre> + + <p><a href="ds_gen.html#find_range">Design::Associative + Containers::Data-Structure Genericity::Point-Type and + Range-Type Methods and Iterators</a> discusses the relationship + between point-type and range-type iterators in general; for + containers whose interface defines sequence order, however, it + is very simple: point-type and range-type iterators are exactly + the same, which means that the above snippet will compile if it + is used for an order-preserving associative container.</p> + + <p>For self-organizing containers, however, (hash-based + containers as a special example), the preceding snippet will + not compile, because their point-type iterators do not support + <tt><b>operator</b>++</tt>.</p> + + <p>In any case, both for order-preserving and self-organizing + containers, the following snippet will compile:</p> + <pre> +<b>typename</b> Cntnr::point_iterator it = c.find(2); +</pre> + + <p>because a range-type iterator can always be converted to a + point-type iterator.</p> + + <p><a href="ds_gen.html#find_range">Design::Associative + Containers::Data-Structure Genericity::Point-Type and + Range-Type Methods and Iterators</a> discusses this + further.</p> + + <p><a href= + "motivation.html#assoc_diff_it">Motivation::Associative + Containers::Differentiating between Iterator Types</a> also + raised the point that a container's iterators might have + different invalidation rules concerning their de-referencing + abilities and movement abilities. This now corresponds exactly + to the question of whether point-type and range-type iterators + are valid. As explained in <a href="#assoc_ds_gen">Determining + Containers' Attributes</a>, <a href= + "assoc_container_traits.html"><tt>container_traits</tt></a> allows + querying a container for its data structure attributes. The + iterator-invalidation guarantees are certainly a property of + the underlying data structure, and so</p> + <pre> +<a href= +"assoc_container_traits.html">container_traits</a><C>::invalidation_guarantee +</pre> + + <p>gives one of three pre-determined types that answer this + query. This is explained further in <a href= + "ds_gen.html#find_range">Design::Associative + Containers::Data-Structure Genericity::Point-Type and + Range-Type Methods and Iterators</a>.</p> + + <h3><a name="assoc_ms" id="assoc_ms">Distinguishing between Maps and Sets</a></h3> + + <p>Anyone familiar with the STL knows that there are four kinds + of associative containers: maps, sets, multimaps, and + multisets. <a href="#assoc_basic">Basic Use</a> discussed how + to use maps, <i>i.e.</i> containers that associate each key to + some data.</p> + + <p>Sets are associative containers that simply store keys - + they do not map them to anything. In the STL, each map class + has a corresponding set class. <i>E.g.</i>, + <tt>std::map<<b>int</b>, <b>char</b>></tt> maps each + <tt><b>int</b></tt> to a <tt><b>char</b></tt>, but + <tt>std::set<<b>int</b>, <b>char</b>></tt> simply stores + <tt><b>int</b></tt>s. In <tt>pb_ds</tt>, however, there are no + distinct classes for maps and sets. Instead, an associative + container's <tt>Mapped</tt> template parameter is a policy: if + it is instantiated by <a href= + "null_mapped_type.html"><tt>null_mapped_type</tt></a>, then it + is a "set"; otherwise, it is a "map". <i>E.g.</i>,</p> + <pre> +<a href="cc_hash_table.html">cc_hash_table</a><<b>int</b>, <b>char</b>> +</pre>is a "map" mapping each <tt><b>int</b></tt> value to a <tt> + <b>char</b></tt>, but + <pre> +<a href="cc_hash_table.html">cc_hash_table</a><<b>int</b>, <a href="null_mapped_type.html">null_mapped_type</a>> +</pre>is a type that uniquely stores <tt><b>int</b></tt> values. + + <p>Once the <tt>Mapped</tt> template parameter is instantiated + by <a href="null_mapped_type.html">null_mapped_type</a>, then + the "set" acts very similarly to the STL's sets - it does not + map each key to a distinct <a href= + "null_mapped_type.html">null_mapped_type</a> object. Also, + , the container's <tt>value_type</tt> is essentially + its <tt>key_type</tt> - just as with the STL's sets. For a simple example, see <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_set.cc"><tt>basic_set.cc</tt></a> + .</p> + + <p>The STL's multimaps and multisets allow, respectively, + non-uniquely mapping keys and non-uniquely storing keys. As + discussed in <a href= + "motivation.html#assoc_mapping_semantics">Motivation::Associative + Containers::Alternative to Multiple Equivalent Keys</a>, the + reasons why this might be necessary are 1) that a key might be + decomposed into a primary key and a secondary key, 2) that a + key might appear more than once, or 3) any arbitrary + combination of 1)s and 2)s. Correspondingly, + one should use 1) "maps" mapping primary keys to secondary + keys, 2) "maps" mapping keys to size types, or 3) any arbitrary + combination of 1)s and 2)s. Thus, for example, an + <tt>std::multiset<<b>int</b>></tt> might be used to store + multiple instances of integers, but using <tt>pb_ds</tt>'s + containers, one might use</p> + <pre> +<a href= +"tree.html">tree</a><<b>int</b>, size_t> +</pre><i>i.e.</i>, a "map" of <tt><b>int</b></tt>s to +<tt>size_t</tt>s. + + <p><a href="assoc_examples.html#mmaps">Associative-Container + Examples::"Multimaps" and "Multisets"</a> shows some simple + examples.</p> + + <p>These "multimaps" and "multisets" might be confusing to + anyone familiar with the STL's <tt>std::multimap</tt> and + <tt>std::multiset</tt>, because there is no clear + correspondence between the two. For example, in some cases + where one uses <tt>std::multiset</tt> in the STL, one might use + in <tt>pb_ds</tt> a "multimap" of "multisets" - <i>i.e.</i>, a + container that maps primary keys each to an associative + container that maps each secondary key to the number of times + it occurs.</p> + + <p>When one uses a "multimap," one should choose with care the + type of container used for secondary keys. This is further + explained in <a href= + "assoc_performance_tests.html#msc">Associative-Container + Performance Tests::Observations::Mapping-Semantics + Considerations</a>.</p> + +<hr> + <h2><a name="pq" id="pq">Priority Queues</a></h2> + + <h3><a name="pq_basic" id="pq_basic">Basic Use</a></h3> + + <p><tt>pb_ds</tt>'s priority_queue container is + similar to the STL's in interface. For example:</p> + <pre> +<a href= +"priority_queue.html">priority_queue</a><<b>int</b>> p; + +p.push(2); +p.push(4); +p.push(1); + +assert(p.top() == 4); + +p.pop(); + +assert(p.top() == 2); + +assert(p.size() == 2); +assert(!p.empty()); +</pre> + + <h3><a name="pq_policies" id="pq_policies">Configuring Priority + Queues</a></h3> + + <p>As opposed to associative containers, priority queues have + relatively few configuration options. The priority queue is + parametrized as follows:</p> + <pre> +<b>template</b>< + <b>typename</b> Value_Type, + <b>typename</b> Cmp_Fn, + <b>typename</b> Tag, + <b>typename</b> Allocator> +<b>class</b> <a href="priority_queue.html">priority_queue</a>; +</pre> + + <p>The <tt>Value_Type</tt>, <tt>Cmp_Fn</tt>, and + <tt>Allocator</tt> parameters are the container's value type, + comparison-functor type, and allocator type, respectively; + these are very similar to the STL's priority queue. The + <tt>Tag</tt> parameter is different: there are a number of + pre-defined tag types corresponding to binary heaps, binomial + heaps, <i>etc.</i>, and <tt>Tag</tt> should be instantiated + by one of them. <a href= + "interface.html#ds_ts_pq">Interface::Data-Structure Tags and + Traits::Data Structure Tags::Priority-Queues</a> lists the + possible types, <a href="pq_design.html">Priority-Queue + Design</a> explains this further, and <a href= + "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_priority_queue.cc"><tt>basic_priority_queue.cc</tt></a> + shows an example.</p> + + <p>Note that as opposed to the STL's priority queue, <a href= + "priority_queue.html"><tt>priority_queue</tt></a> is not a + sequence-adapter; it is a regular container.</p> + + <h3><a name="pq_ds_more_ops" id="pq_ds_more_ops">Supporting + More Operations</a></h3> + + <p><a href="priority_queue.html"><tt>priority_queue</tt></a>'s + <tt>push</tt> method returns a point-type iterator, which can + be used for modifying or erasing arbitrary values. For + example:</p> + <pre> +<a href= +"priority_queue.html">priority_queue</a><<b>int</b>> p; + +<a href= +"priority_queue.html">priority_queue</a><<b>int</b>>::point_iterator it = p.push(3); + +p.modify(it, 4); +</pre> + + <p>These types of operations are necessary for making priority + queues useful for different applications, especially graph + applications. <a href="pq_examples.html#xref">Priority-Queue + Examples::Cross-Referencing</a> gives some examples.</p> + + <h3><a name="pq_ds_gen" id="pq_ds_gen">Determining Container + Attributes</a></h3> + + <p>Similarly to <a href= + "assoc_container_traits.html"><tt>container_traits</tt></a> (described + in <a href="#assoc_ds_gen">Associative Containers::Determining + Containers' Attributes</a>), <a href= + "pq_container_traits.html"><tt>container_traits</tt></a> can be used to + statically determine priority-queues' attributes:</p> + <pre> +<a href= +"pq_container_traits.html">container_traits</a><C>::container_category +</pre>is one of a small number of predefined tag structures that +identifies the underlying data structure, and + <pre> +<a href= +"pq_container_traits.html">container_traits</a><C>::invalidation_guarantee +</pre> + + <p>is its invalidation guarantee. Invalidation guarantees are + especially important regarding priority queues, since in + <tt>pb_ds</tt>'s design, iterators are practically the only way + to manipulate them.</p> + + <p><a href="pq_design.html#pq_traits">Design::Priority + Queues::Traits</a> discusses this further. <a href= + "pq_examples.html#generics">Priority-Queue + Examples::Generics</a> shows an example.</p> + </div> +</body> +</html> diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_policy_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_policy_cd.png Binary files differnew file mode 100644 index 000000000..115a751c3 --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_policy_cd.png diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_seq_diagram.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_seq_diagram.png Binary files differnew file mode 100644 index 000000000..880a50edf --- /dev/null +++ b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_seq_diagram.png |
